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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
