Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

[Jon Smirl]

On Fri, Dec 4, 2009 at 9:12 AM, Mauro Carvalho Chehab
<mchehab@xxxxxxxxxx> wrote:
>> In-kernel decoding:
>>

[IR physical device] => [IR receiver driver] => [LIRC core] =>
[decoder] => [IR core] => [input core] => [evdev]
                                                  ||
                                                   => [Lirc API device]>>
>> Hardware decoder:
>> [IR physical device] => [IR receiver driver] => [IR core]
>>                                            => [input core] => [evdev]

My hope is that 90% of users can achieve "just works" via these two
models. There will need to be several default device/keymaps installed
to avoid the need to configure. For example, have udev install a
default map from Motorola DVR IR to Linux keycodes. Installing that
map creates a new evdev device.  Myth can then look for that device by
default and listen to it. Now the user just needs to set their
programmable remote to send Motorola DVR and everything should "just
work". Pick similar default maps/evdev device for music players and
home automation. Sophisticated users can change these default maps by
editing the udev scripts.

Long term the goal is to get IR profiles for Linux DVR, music player,
home automation, etc in to the IR database. Then we won't have to
override the profile for another company's device.

I believe it is a requirement to send the decoded IR events up to user
space (EV_IR). That would handle the case of the air conditioner
remote. It also allows construction of an app that automatically
searches the IR database for mapping tables. Normal apps would just
ignore these events.

Installing a map is what triggers the creation of another evdev
device. There should be one evdev device per map installed. The
current input API design does not provide for a way to do this.

The only solution I see to automatic device creation is to monitor
unmapped EV_IR events and search for them in the IR database. When a
match is found, install the map from the database - which then
triggers the creation of a new evdev device and the EV_IR event won't
be unmapped any more. Searching is not a simple process since the same
IR code often appears in more than one map. Some human intervention
will probably be required.

[IR physical device] => [IR receiver driver] => [LIRC core] =>
[decoder] => [IR core] => [input core] => [evdev]
                                                  ||
                                                            ||
                                                   => [Lirc API
device]                                               ==> [EV_IR
events]

The EV_IR events also allow a user space protocol decoder to inject
those events back into the input subsystem where they will flow
through the mapping tables.

The in-kernel protocol decoders should be designed as a set of modules
with the pulse data being simultaneously supplied to all modules. That
will make it easy to work on the protocol converters - just
insmod/rmmod as you make changes. These engines can be extracted from
the LIRC code and turned into modules.

Where are IR repeat bits going to be handled?

-- 
Jon Smirl
jonsmirl@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/