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

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Jon Smirl wrote:
> On Sun, Dec 6, 2009 at 12:48 PM, Krzysztof Halasa <khc@pm.waw.pl> wrote:
>> Once again: how about agreement about the LIRC interface
>> (kernel-userspace) and merging the actual LIRC code first? 

That's fine for me.

>> In-kernel
>> decoding can wait a bit, it doesn't change any kernel-user interface.

This may occur in parallel, but, as we've been discussing, there are
still some needs there that will require kernel-user interfaces.

> I'd like to see a semi-complete design for an in-kernel IR system
> before anything is merged from any source.

There are some tasks there that are independent of any API design.

For example, I'm currently doing some cleanups and improvements 
at the existing IR in-kernel code to create a common IR core that replaces
the already existing feature of handling 7-bits scancode/keycode table to
use the complete scancodes found at the current in-kernel drivers.

This approach works for the current drivers, as none of them currently support
any protocol that requires more than 16 bits for scancodes. However, the
current EVIOGKEYCODE implementation won't scale with bigger scancode spaces.

This code is written to be generic enough to be used by V4L, DVB and LIRC
drivers. So, after having this work done, it should be easy to connect the lirc_dev
to a decoder and to this core support. There are already some in-kernel decoders
that can be used for some protocols, but the better is to review the decoders in
the light of lirc. I expect that the lirc decoders will be in a better shape.

While I'm here, I intend also to create the sysfs bits to create sys/class/irrcv,
as already discussed and submit the patch here for discussions.

Of course, after writing different API's to control the IR tables, we'll
need to improve it, but this depends on the results of the architecture discussions.

Cheers,
Mauro