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