On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 4 Dec 2009 02:06:42 -0800
> Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> escreveu:
>
> > >
> >
> > evdev does not really care what you use as scancode. So nobody stops
> > your driver to report index as a scancode and accept index from the
> > ioctl. The true "scancode" will thus be competely hidden from userspace.
> > In fact a few drivers do just that.
>
> Let me better express here. It is all about how we'll expand the limits of those
> ioctls to fulfill the needs.
>
> The point is that we'll have, let's say something like to 50-500 scancode/keycode tuples
> sparsely spread into a 2^64 scancode universe (assuming 64 bits - Not sure if is there any
> IR protocol/code with a bigger scancode).
>
> On such universe if we want to get all keycodes with the current ioctls for a scancode in
> the range of 32 bits, we need to do something like:
>
> u32 code;
> int codes[2];
> for (code = 0; code <= (unsigned u32) - 1; code++) {
> codes[0] = (int)code;
> if (!ioctl(fd, EVIOCGKEYCODE, codes))
> printf("scancode 0x%08x = keycode 0x%08x\n", codes[0], codes[1]);
> }
>
> So, on the 32 bits case, we'll do about 4 billions calls to EVIOGKEYCODE ioctl to
> read the complete scancode space, to get those 50-500 useful codes.
>
Right, currently there is no need to query all scancodes defined by
device. Quite often drivers don't even know what scancodes device
actually generates (ex AT keyboard).
Could you describe in more detail how you are using this data?
>
> Due to the current API limit, we don't have any way to use the full 64bits space for scancodes.
>
Can we probably reduce the "scancode" space? ARe all 64 bits in
protocols used to represent keypresses or some are used for some kind of
addressing?
> if we use code[0] as an index, this means that we'll need to share the 32 bits on code[1]
> for scancode/keycode. Even using an 32 bits integer for keycode, it is currently limited to:
>
> #define KEY_MAX 0x2ff
> #define KEY_CNT (KEY_MAX+1)
>
> So, we have 10 bits already used for keycode. This gives only 22 bits for scancodes, if we share
> codes[1] for both keycode/scancode. By sharing the 32 bits, we'll need to be care to not extend
> KEY_MAX to be bigger than 0x3ff, otherwise the keytable won't be able to represent all keys of the
> key universe.
>
> What is need for this case is that the arguments for get key/set key to be something like:
>
> struct {
> u16 index;
> u64 scancode;
> u32 keycode;
> };
>
Hmm, so what is this index? I am confused...
Thanks.
--
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
