On 11-01-24 11:55 PM, Dmitry Torokhov wrote:

On Mon, Jan 24, 2011 at 11:37:06PM -0500, Mark Lord wrote:

..

quoted

This results in (map->size==10) for 2.6.36+ (wrong),
and a much larger map->size for 2.6.35 and earlier.

So perhaps EVIOCGKEYCODE has changed?

So the utility expects that all devices have flat scancode space and
driver might have changed so it does not recognize scancode 10 as valid
scancode anymore.

The options are:

1. Convert to EVIOCGKEYCODE2
2. Ignore errors from EVIOCGKEYCODE and go through all 65536 iterations.

or 3. Revert/fix the in-kernel regression.

The EVIOCGKEYCODE ioctl is supposed to return KEY_RESERVED for unmapped
(but value) keycodes, and only return -EINVAL when the keycode itself
is out of range.

That's how it worked in all kernels prior to 2.6.36,
and now it is broken.  It now returns -EINVAL for any unmapped keycode,
even though keycodes higher than that still have mappings.

This is a bug, a regression, and breaks userspace.
I haven't identified *where* in the kernel the breakage happened,
though.. that code confuses me.  :)

Thanks.