[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.241 / U:1.200 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site