Message-ID: <4B279AF9.8080302@redhat.com>
Date:	Tue, 15 Dec 2009 12:19:37 -0200
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Jon Smirl <jonsmirl@...il.com>
CC:	Pavel Machek <pavel@....cz>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Krzysztof Halasa <khc@...waw.pl>,
	hermann pitton <hermann-pitton@...or.de>,
	Christoph Bartelmus <lirc@...telmus.de>, awalls@...ix.net,
	j@...nau.net, jarod@...hat.com, jarod@...sonet.com,
	kraxel@...hat.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
 IR 	system?

Jon Smirl wrote:
> On Tue, Dec 15, 2009 at 8:33 AM, Mauro Carvalho Chehab
> <mchehab@...hat.com> wrote:
>> Pavel Machek wrote:
>>>>> That is why I think we should go the other way around - introduce the
>>>>> core which receivers could plug into and decoder framework and once it
>>>>> is ready register lirc-dev as one of the available decoders.
>>>>>
>>>> I've committed already some IR restruct code on my linux-next -git tree:
>>>>
>>>> http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git
>>>>
>>>> The code there basically moves the input/evdev registering code and
>>>> scancode/keycode management code into a separate ir-core module.
>>>>
>>>> To make my life easy, I've moved the code temporarily into drivers/media/IR.
>>>> This way, it helps me to move V4L specific code outside ir-core and to later
>>>> use it for DVB. After having it done, probably the better is to move it to
>>>> be under /drivers or /drivers/input.
>>> Well, -next is for stuff to be merged into 2.6.34. You are quite an
>>> optimist.
>>>                                                                       Pavel
>> Well, we need those changes anyway for the in-kernel drivers, and I'm not seeing
>> on the current patches any reason for not having them for 2.6.34.
>>
>> I've added all the ir-core patches I did so far at linux-next. This helps people
>> to review and contribute.
>>
>> The patches are already working with the in-kernel em28xx driver, allowing to
>> replace the keycode table and the protocol used by the hardware IR decoder.
>> I tested here by replacing an RC-5 based IR table (Hauppauge Grey) by a NEC
>> based IR table (Terratec Cinergy XS remote controller).
>>
>> The current Remote Controller core module (ir-core) is currently doing:
>>
>>        - Implementation of the existing EVIO[G|S]KEYCODE, expanding/feeing memory
>> dynamically, based on the needed size for scancode/keycode table;
>>
>>        - scancodes can be up to 16 bits currently;
>>
>>        - sysfs is registering /sys/class/irrcv and creating one branch for each
>> different RC receiver, numbering from irrcv0 to irrcv255;
>>
>>        - one irrcv note is created: current_protocol;
>>
>>        - reading /sys/class/irrcv/irrcv*/current_protocol returns the protocol
>> currently used by the driver;
>>
>>        - writing to /sys/class/irrcv/irrcv*/current_protocol changes the protocol
>> to a new one, by calling a callback, asking the driver to change the protocol. If
>> the protocol is not support, it returns -EINVAL;
>>
>>        - all V4L drivers are already using ir-core;
>>
>>        - em28xx driver is implementing current_protocol show/store support.
>>
>> TODO:
> 
> I'd add a pulse based receiver like a MSMCE to make sure the core API is right.
> MSME has transmit hardware too.

Makes sense. This can be done after having the lirc_dev integrated.

> What about creating multiple evdev devices with their own keymaps off
> from a single receiver? That's a key part of making multi-function
> remotes work.

I was sure I missed something at the TODO :)

 > 
> 
>>        1) Port DVB drivers to use ir-core, removing the duplicated (and incomplete
>>          - as table size can't change on DVB's implementation) code that exists there;
>>
>>        2) add current_protocol support on other drivers;
>>
>>        3) link the corresponding input/evdev interfaces with /sys/class/irrcv/irrcv*;
>>
>>        4) make the keytable.c application aware of the sysfs vars;
>>
>>        5) add an attribute to uniquely identify a remote controller;
>>
>>        6) write or convert an existing application to load IR tables at runtime;
>>
>>        7) get the complete 16-bit scancodes used by V4L drivers;
>>
>>        8) add decoder/lirc_dev glue to ir-core;
>>
>>        9) add lirc_dev module and in-kernel decoders;
>>
>>        10) extend keycode table replacement to support big/variable sized scancodes;
>>
>>        11) rename IR->RC;
>>
>>        12) redesign or remove ir-common module. It currently handles in-kernel
>>            keycode tables and a few helper routines for raw pulse/space decode;
>>
>>        13) move drivers/media/IR to a better place;
>>

So, we have also at the todo list:

	14) add pulse based drivers;

	15) make in-kernel pulse-based devices to use lirc_dev;

	16) add an API to dynamically create evdev interfaces for scancode filtering;

>>
>> comments:
>>
>>        Tasks (1) to (6) for sure can happen to 2.6.34, depending on people's spare
>> time for it;
>>
>>        (7) is probably the more complex task, since it requires to re-test all in-kernel
>> supported remote controlle scancode/keycode tables, to get the complete IR keycode
>> and rewrite the getkeycode functions that are currently masking the IR code into 7 bits.
>> We'll need users help on this task, but this can be done gradually, like I did with
>> two RC keytables on em28xx driver, while preserving the other keytables as-is.
>>
>>        (8) I suggest that this glue will be submitted together with lirc_dev patch
>> series, as the biggest client for it is lirc. In principle, kfifo seems the better
>> interface for lirc_dev -> decoders interface. For the decoders -> RC core interface,
>> there's an interface already used on V4L drivers, provided by ir-common, using evdev
>> kernel API. This may need some review.
>>
>>        (9) depends on lirc API discusions. My proposal is that people submit an RFC
>> with the lirc API reviewed to the ML's, for people to ack/nack/comment. After that,
>> re-submit the lirc_dev module integrating it into ir-core and with the reviewed API;
>>
>>        (10) depends on EVIO[G|S]KEYCODE discussions we've already started. I did a proposal
>> about it. I'll review, based on the comments and re-submit it;
>>
>>        (11) if none is against renaming IR as RC, I'll do it on a next patch;
>>
>>        (12) depends on having lirc_dev added, for the removal of ir-functions.c. With
>> respect to the keytables, maybe one interesting alternative is to use a logic close to
>> nls tables that exists at fs, allowing to individually insert or remove an IR keytable
>> in-kernel.
>>
>>        (13) has low priority. While not finishing the DVB integration with RC core
>> and reviewing the remaining bits of the ir-common module.
>>
>> Cheers,
>> Mauro.
>>
> 
> 
> 

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

Powered by blists - more mailing lists