Message-ID: <9e4733910912150543m31938bddv384bd3195bbffcbe@mail.gmail.com>
Date:	Tue, 15 Dec 2009 08:43:07 -0500
From:	Jon Smirl <jonsmirl@...il.com>
To:	Mauro Carvalho Chehab <mchehab@...hat.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?

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.

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.


>        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;
>
>
> 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.
>



-- 
Jon Smirl
jonsmirl@...il.com
--
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