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

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Mon, Dec 07, 2009 at 01:34:10PM -0200, Mauro Carvalho Chehab wrote:
>  
> > Scancodes in input system never been real scancodes. Even if you look
> > into atkbd it uses some synthetic data composed out of real scancodes
> > sent to the keyboard, and noone cares. If you are unsatisfied with
> > mapping you fire up evtest, press the key, take whatever the driver
> > [mis]represents as a scancode and use it to load the new definition. And
> > you don't care at all whether the thing that driver calls cancode makes
> > any sense to the hardware device.
> 
> We used a mis-represented scancode, but this proofed to be a broken design
> along the time.
> 
> For users, whatever the scancode "cookie" means, the same IR device should
> provide the same "cookie" no matter what IR receiver is used, since the same
> IR may be found on different devices, or the user can simply buy a new card
> and opt to use their old IR (there are very good reasons for that, since
> several new devices are now coming with small IR's that has half of the
> keys of the ones available at the older models).

OK, this is a fair point. We need to keep the "scancodes" stable across
receivers.

However I am not sure if the "index" approach is the best - it will not
work well if driver decides to implement the keymap using data structure
different from array, let's say linked list or a hash table. Lists by
their nature do not have a stable index and even if we were to generate
one "on fly" we could not rely on it for subsequent EVIOSKEYCODE: some
other program may cause insertion or deletion of an element making the
artificial index refer to another entry in the map.

While extending scancode size is pretty straightforward (well, almost
;) ) I am not sure what is the best way to enumerate keymap for a given
device.

-- 
Dmitry