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

[Mark Lord]

On 11-01-25 06:42 AM, Mauro Carvalho Chehab wrote:
>
> I lost part of the thread, but a quick search via the Internet showed that you're using
> the input tools to work with a Remote Controller, right? Are you using a vanilla
> kernel, or are you using the media_build backports? There are some distros that are
> using those backports also like Fedora 14.

I use kernel.org kernels exclusively.

> The issue is simple, and it is related on how the input.c used to handle EVIOSGKEYCODE.
> Basically, before allowing you to change a key, it used to call EVIOCGKEYCODE to check
> it that key exists. However, when you're creating a new association, the key didn't
> exist, and, to be strict with input rules, EVIOCGKEYCODE should return -EINVAL.

No, if the parameters are a valid key, then -EINVAL is never the correct
thing for a kernel to return.  -EINVAL means "bad parameters",
and that's not an accurate description of a valid yet unmapped key.

> To circumvent that behaviour, old versions were returning 0, and associating unmapped
> scancodes to KEY_RESERVED. We used this workaround for a few kernel versions, while
> we were discussing the improvements so support larger scancodes.

And now we're stuck with it.  If that is how it works,
and userspace depends upon it (it does), then consider
it cast in stone.  Immutable by Linus's Law: don't break userspace.

Create a new ioctl() number for the new behaviour,
but preserve the old behaviour in exact form for
a suitable (multi-year) overlap period.

Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/