V3 - Implementation of IR support using the input subsystem

From last post...

Received IR messages generate event in the input queue. IR messages are sent using an input IOCTL.

Quoted 2 lines · Jon Smirl

Received IR messages generate event in the input queue. IR messages are sent using an input IOCTL.

Another question.

So input device sends its events as a special event type? This would mean that none of current drivers will be able to pick these events.

I think that input device should have better configuration support, like generic way to set a keymap (raw->keycode) for a device, and the IR timing can be set too.
And send normal keypreses.

Regards,
       Maxim Levitsky

Third pass at implementing evdev support for IR. The goal of in-kernel IR is to integrate IR events into the evdev input event queue and maintain ordering of events from all input devices.

What should the IR API look like? How are IR events mapped into
keyboard events? Should they be mapped? Map them in the kernel or in user space? The maps are tiny, less than 1K per remote. Sysfs can be used to load maps into the kernel driver. Make maps only for the common buttons and don't map unusual ones?

How should multiple remotes be handled? Split them out into individual input devices, or group them onto a single IR device? I can implement either.

Hi!

Quoted 5 lines

What should the IR API look like? How are IR events mapped into
keyboard events? Should they be mapped? Map them in the kernel or in user space? The maps are tiny, less than 1K per remote. Sysfs can be used to load maps into the kernel driver. Make maps only for the common buttons and don't map unusual ones?

Map them in kernel, in analogy with normal keyboards.

Quoted 3 lines

How should multiple remotes be handled? Split them out into individual input devices, or group them onto a single IR device? I can implement either.

Individual input devices, I'd say... so that app can only listen for 'its' remote.

Quoted 9 lines · Pavel Machek

Hi!

Quoted 5 lines

What should the IR API look like? How are IR events mapped into
keyboard events? Should they be mapped? Map them in the kernel or in user space? The maps are tiny, less than 1K per remote. Sysfs can be used to load maps into the kernel driver. Make maps only for the common buttons and don't map unusual ones?

Map them in kernel, in analogy with normal keyboards.

My thought was to basically follow what the ati_remote{,2} driver does.

Quoted 4 lines

Quoted 3 lines

How should multiple remotes be handled? Split them out into individual input devices, or group them onto a single IR device? I can implement either.

Quoted 2 lines

Individual input devices, I'd say... so that app can only listen for 'its' remote.

I don't quite get it. How can we tell there are multiple remotes to set up multiple input devices when the system comes up? All we can know about at driver init time is the receiver(s), no? Or would this be keyed off a config file? Or ______ ?

--
Jarod Wilson
[email protected]

Quoted 1 line · Jarod Wilson

On Thu, 2008-10-09 at 14:03 +0200, Pavel Machek wrote:

Quoted 11 lines

Quoted 6 lines

Quoted 3 lines

How should multiple remotes be handled? Split them out into individual input devices, or group them onto a single IR device? I can implement either.

Individual input devices, I'd say... so that app can only listen for 'its' remote.

I don't quite get it. How can we tell there are multiple remotes to set up multiple input devices when the system comes up? All we can know about at driver init time is the receiver(s), no? Or would this be keyed off a config file? Or ______ ?

We could create a sysfs attribut named ir_config. For each config file you copy to it it creates a new input device. The config files have lists of map this protocol, device, command tuple to this key. When a remote button is pressed the raw codes are fed to the in-kernel protocol engine. That engine turns the raw codes into tuples. Tuples are matched against the configs that have been loaded until a hit is found. If no hit they get sent out the catch-all device.

Most remotes send out unique codes, they have to or they would turn on unintended devices.

Quoted 2 lines · Jon Smirl

Quoted 1 line · Jarod Wilson

On Thu, 2008-10-09 at 14:03 +0200, Pavel Machek wrote:

[...]

Quoted 13 lines

Quoted 11 lines

Quoted 6 lines

Quoted 3 lines

How should multiple remotes be handled? Split them out into individual input devices, or group them onto a single IR device? I can implement either.

Individual input devices, I'd say... so that app can only listen for 'its' remote.

I don't quite get it. How can we tell there are multiple remotes to set up multiple input devices when the system comes up? All we can know about at driver init time is the receiver(s), no? Or would this be keyed off a config file? Or ______ ?

Quoted 7 lines

We could create a sysfs attribut named ir_config. For each config file you copy to it it creates a new input device. The config files have lists of map this protocol, device, command tuple to this key. When a remote button is pressed the raw codes are fed to the in-kernel protocol engine. That engine turns the raw codes into tuples. Tuples are matched against the configs that have been loaded until a hit is found. If no hit they get sent out the catch-all device.

Okay. I presume the catch-all device would simply note that it saw something, and not actually take any action beyond that.

Also, a minor clarification: If its config file based, then its not so much one input device per remote, its one input device per config file, so one could set up two separate config files that are actually commands from the same remote, but have them listened to by different apps, or one could group together commands from multiple remotes in a single config so that multiple remotes would all control the same thing. Sounds good to me, provides for a reasonable amount of flexibility.

Of course, this suggests a receiver wouldn't be able to do anything until the user provided a key mapping table of some sort. Would it make sense to provide a default IR-to-key mapping for each receiver type? A bit difficult to provide a sane default for something like a home-brew serial IR receiver, but you could certainly provide sane defaults for things like mceusb and imon (i.e., mappings for the remotes typically bundled with those receivers).

Quoted 3 lines

Most remotes send out unique codes, they have to or they would turn on unintended devices.

Yep, that's actually where the root of my concern was. I have at least a half dozen different remote-controlled devices in my AV cabinet near my myth box, and I obviously don't want anything but the codes I've set up for my myth box acted upon on the myth box. :)

--
Jarod Wilson
[email protected]

Quoted 25 lines · Jarod Wilson

Quoted 2 lines · Jon Smirl

Quoted 1 line · Jarod Wilson

On Thu, 2008-10-09 at 14:03 +0200, Pavel Machek wrote:

[...]

Quoted 20 lines

Quoted 11 lines

Quoted 6 lines

Quoted 3 lines

How should multiple remotes be handled? Split them out into individual input devices, or group them onto a single IR device? I can implement either.

Individual input devices, I'd say... so that app can only listen for 'its' remote.

I don't quite get it. How can we tell there are multiple remotes to set up multiple input devices when the system comes up? All we can know about at driver init time is the receiver(s), no? Or would this be keyed off a config file? Or ______ ?

We could create a sysfs attribut named ir_config. For each config file you copy to it it creates a new input device. The config files have lists of map this protocol, device, command tuple to this key. When a remote button is pressed the raw codes are fed to the in-kernel protocol engine. That engine turns the raw codes into tuples. Tuples are matched against the configs that have been loaded until a hit is found. If no hit they get sent out the catch-all device.

Quoted 2 lines

Okay. I presume the catch-all device would simply note that it saw something, and not actually take any action beyond that.

The catch-all device is an device in /dev/input. It gets the input tuples in protocol/device/command form sent to it. I should probably send all IR input to this device, and flag the events that were translated and sent to another input device.

Quoted 7 lines

Also, a minor clarification: If its config file based, then its not so much one input device per remote, its one input device per config file, so one could set up two separate config files that are actually commands from the same remote, but have them listened to by different apps, or one could group together commands from multiple remotes in a single config so that multiple remotes would all control the same thing. Sounds good to me, provides for a reasonable amount of flexibility.

That is how it works.

Quoted 7 lines

Of course, this suggests a receiver wouldn't be able to do anything until the user provided a key mapping table of some sort. Would it make sense to provide a default IR-to-key mapping for each receiver type? A bit difficult to provide a sane default for something like a home-brew serial IR receiver, but you could certainly provide sane defaults for things like mceusb and imon (i.e., mappings for the remotes typically bundled with those receivers).

Receivers can process the raw tuples using the catch-all device.

You could write a little app like udev that listens to the catch-all device and then search the config files for untranslated tuples. When you match on an untranslated tuple, load that config file into the kernel.

I'm taking the kids on their first trip to Disneyworld next week so I won't be able to work on this for a while.

Third pass at implementing evdev support for IR. The goal of in-kernel IR is to integrate IR events into the evdev input event queue and maintain ordering of events from all input devices.

New feature, raw mode. There are three sysfs attributes - ir_raw, ir_carrier, ir_xmitter. Read from ir_raw to get the raw timing data from the IR device. Set carrier and active xmitters and then copy raw data to ir_raw to send. These attributes may be better on a debug switch. You would use raw mode when decoding a new protocol. After you figure out the new protocol, write an in-kernel encoder/decoder for it.

What should the IR API look like?

How are IR events mapped into keyboard events? Should they be mapped? Map them in the kernel or in user space? The maps are tiny, less than 1K per remote. Sysfs can be used to load maps into the kernel driver. Make maps only for the common buttons and don't map unusual ones?

How should multiple remotes be handled? Split them out into individual input devices, or group them onto a single IR device? I can implement either.

The in-kernel code is tiny, about 20K including a driver.

Quoted 1 line

From last post...

Note that user space IR device drivers can use the existing support in evdev to inject events into the input queue.

Send and receive are implemented. Received IR messages are decoded and sent to user space as input messages. Send is done via an IOCTL on the input device.

Two drivers are supplied. mceusb2 implements send and receive support for the Microsoft USB IR dongle.

The GPT driver implements receive only support for a GPT pin - GPT is a GPIO with a timer attached.

Code is only lightly tested. Encoders and decoders have not been written for all protocols. Repeat is not handled for any protocol.
I'm looking for help. There are 15 more existing LIRC drivers.

Quoted 17 lines · Jon Smirl

Third pass at implementing evdev support for IR. The goal of in-kernel IR is to integrate IR events into the evdev input event queue and maintain ordering of events from all input devices.

New feature, raw mode. There are three sysfs attributes - ir_raw, ir_carrier, ir_xmitter. Read from ir_raw to get the raw timing data from the IR device. Set carrier and active xmitters and then copy raw data to ir_raw to send. These attributes may be better on a debug switch. You would use raw mode when decoding a new protocol. After you figure out the new protocol, write an in-kernel encoder/decoder for it.

What should the IR API look like?

How are IR events mapped into keyboard events? Should they be mapped? Map them in the kernel or in user space? The maps are tiny, less than 1K per remote. Sysfs can be used to load maps into the kernel driver. Make maps only for the common buttons and don't map unusual ones?

How should multiple remotes be handled? Split them out into individual input devices, or group them onto a single IR device? I can implement either.

The in-kernel code is tiny, about 20K including a driver.

Quoted 1 line

From last post...

Note that user space IR device drivers can use the existing support in evdev to inject events into the input queue.

Send and receive are implemented. Received IR messages are decoded and sent to user space as input messages. Send is done via an IOCTL on the input device.

Quoted 7 lines

Two drivers are supplied. mceusb2 implements send and receive support for the Microsoft USB IR dongle.

The GPT driver implements receive only support for a GPT pin - GPT is a GPIO with a timer attached.

Code is only lightly tested. Encoders and decoders have not been written for all protocols. Repeat is not handled for any protocol.
I'm looking for help. There are 15 more existing LIRC drivers.

Any update on that?

I have a suggestion:

Instead of decoding protocols in kernel, why not to allow userspace to upload timing signatures as specified in lirc.conf ?

As a example, what protocol this is:

http://lirc.sourceforge.net/remotes/toshiba/CT-9922

Best regards,
Maxim Levitsky