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

Mauro Carvalho Chehab
2009-12-07T23:16:03Z

Emmanuel Fusté wrote:
> Mauro Carvalho Chehab wrote:
>
>> In summary,
>>
>> While the current EVIO[G|S]KEYCODE works sub-optimally for scancodes
>> up to 16 bytes
>> (since a read loop for 2^16 is not that expensive), the current approach
>> won't scale with bigger scancode spaces. So, it is needed expand it
>> to work with bigger scancode spaces, used by more recent IR protocols.
>>
>> I'm afraid that any tricks we may try to go around the current limits
>> to still
>> keep using the same ioctl definition will sooner or later cause big
>> headaches.
>> The better is to redesign it to allow using different scancode spaces.
>>
>>
>>
> I second you: input layer events from drivers should be augmented with a
> protocol member,

Yeah, I added the protocol type info inside the internal representation of
the IR table. As I managed to do all the work inside one file (ir-keytable.c),
changing it to use arbitrary sized scancode lengths will be trivial (currently,
it is u16 just because just because it currently enough for the in-kernel drivers,
but this will be changed when integrating with lirc):

http://linuxtv.org/hg/v4l-dvb/rev/7b983cd30f0f

> allowing us to define new ioctl and new ways to
> efficiently store and manage sparse scancode spaces (tree, hashtable
> ....). It will allow us to abstract the scancode value and to use
> variable length scancode depending on the used protocol, and using the
> most appropriate scheme to store the scancode/keycode mapping per protocol.

True.

> The today scancode space will be the legacy one, the default if not
> specified "protocol". It will permit to progressively clean up the
> actual acceptable mess in the input layer and finally using real
> scancode -> keycode mappings everywhere if it is cleaner/convenient.

Yes. By purpose, I added IR_TYPE_UNKNOWN as 0. This way, all tables that don't
specify a protocol can be considered legacy.

Cheers,
Mauro.