Jon Smirl wrote:
> On Tue, Dec 15, 2009 at 8:33 AM, Mauro Carvalho Chehab
> <mche...@redhat.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-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
