[lkml]   [2009]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
    On Thu, Nov 26, 2009 at 9:45 AM, Mauro Carvalho Chehab
    <> wrote:
    > Gerd Hoffmann wrote:
    >> On 11/25/09 19:20, Devin Heitmueller wrote:
    >>> On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson<>
    >>> wrote:
    >>>> Took me a minute to figure out exactly what you were talking
    >>>> about. You're referring to the current in-kernel decoding done on
    >>>> an ad-hoc basis for assorted remotes bundled with capture devices,
    >>>> correct?
    >>>> Admittedly, unifying those and the lirc driven devices hasn't
    >>>> really been on my radar.
    >> I think at the end of the day we'll want to have all IR drivers use the
    >> same interface.  The way the current in-kernel input layer drivers work
    >> obviously isn't perfect too, so we *must* consider both worlds to get a
    >> good solution for long-term ...

    I made an attempt at implementing all of this a year ago.

    All of this kernel code is tiny, about 20K including a driver.

    Basic flow works like this:

    Add a new IR data type to the input framework

    Example mceusb IR input driver

    In-kernel decoding of core IR protocols - RC5, RC6, etc

    Decoded core protocols pass through a translation map based on configfs
    When core protocol matches an entry in configfs it is turned into a
    keycode event.

    You make a directory in /configfs/remotes for each remote you have.
    Making the directory creates a new evdev device. Under the directory
    make an entry for each command generated by the device. These entries
    cause the decoded IR data to be mapped into keycodes on the new evdev
    device. udev would load these configfs mappings at boot time...

    mkdir /config/remotes/sony
    -- this creates a new evdev device
    mkdir remotes/sony/one
    echo 7 >remotes/sony/one/protocol
    echo 264 >remotes/sony/one/command
    echo 2 >remotes/sony/one/keycode

    This transforms a button push of 1 on my remote into a key stroke for KEY_1

    * configfs root
    * --remotes
    * ----specific remote
    * ------keymap
    * --------protocol
    * --------device
    * --------command
    * --------keycode
    * ------repeat keymaps
    * --------....
    * ----another remote
    * ------more keymaps

    You can map the 1 button from multiple remotes to KEY_1 if you want. Or
    you can use a single remote to create multiple virtual keyboards.


    Raw IR pulse data is available in a FIFO via sysfs. You can use this
    to figure out new remote protocols.

    Two input events are generated
    1) an event for the decoded raw IR protocol
    2) a keycode event if thedecoded raw IR protocol matches an entry in
    the configfs

    You can also send pulses.


    If you want to script this, you would have a user space task that
    watches for either the decoded IR codes or the mapped keycodes.

    This system also works with user space device drivers. They can inject
    input events into the early event flow and they will get processed as
    if the event originated in the kernel.


    Sure you could push the protocol decoding code (RC5, etc) into user
    space. Seems like a lot of hassle to move about 3KB of code out of the

    Jon Smirl
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-11-26 16:51    [W:0.031 / U:9.932 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site