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