Messages in this thread | | | Date | Mon, 7 Dec 2009 10:24:38 -0800 | From | Dmitry Torokhov <> | Subject | Re: [RFC] What are the goals for the architecture of an in-kernel IR system? |
| |
On Mon, Dec 07, 2009 at 06:54:39PM +0100, 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, allowing us to define new ioctl and new ways to > efficiently store and manage sparse scancode spaces (tree, hashtable > ....).
Userspace has no business knowing how driver maps hardware data stream into a keycode, only what is being mapped to what. The way is is done can change from driver-to-driver, from release to release. If I come up with an super-smart or super-stupid way of storing key mapping I won't want to modify userpsace tools to support it.
> 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. > 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. >
I am unable to parse this part, sorry.
-- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |