On Thu, Nov 26, 2009 at 9:45 AM, Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote: > Gerd Hoffmann wrote: >> On 11/25/09 19:20, Devin Heitmueller wrote: >>> On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson<jarod@xxxxxxxxxxxx> >>> 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. http://lkml.org/lkml/2008/11/5/233 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 http://lkml.org/lkml/2008/11/5/234 Example mceusb IR input driver http://lkml.org/lkml/2008/11/5/238 In-kernel decoding of core IR protocols - RC5, RC6, etc http://lkml.org/lkml/2008/11/5/234 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. http://lkml.org/lkml/2008/11/5/235 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 kernel. -- Jon Smirl jonsmirl@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
