Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?

On Tue, Jan 25, 2011 at 12:04:10AM -0500, Mark Lord wrote:

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

quoted

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

..

quoted

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.

You are inventing rules.  You are requesting a scancode->keycode
mapping. If scancode is unknown/invalid for the device ioctl returns
-EINVAL.

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.

For unmapped - yes, either KEY_RESERVED or KEY_UNKNOWN should be
returned. For invalid scancodes -EINVAL shoudl be returned. Scancodes
are not guaranteed to be continuous (and never have been for all devices
although there are still plenty of devices with continuous scancodes,
like atkbd).

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.  :)

-- 
Dmitry