On Tue, Jan 25, 2011 at 12:54:53PM -0800, Dmitry Torokhov wrote:

On Wed, Jan 26, 2011 at 06:09:45AM +1000, Linus Torvalds wrote:

quoted

On Wed, Jan 26, 2011 at 2:48 AM, Dmitry Torokhov
[off-list ref] wrote:

quoted

We should be able to handle the case where scancode is valid even though
it might be unmapped yet. This is regardless of what version of
EVIOCGKEYCODE we use, 1 or 2, and whether it is sparse keymap or not.

Is it possible to validate the scancode by driver?

More appropriately, why not just revert the thing? The version change

Well, then we'll break Ubuntu again as they recompiled their input-utils
package (without fixing the check). And the rest of distros do not seem
to be using that package...

quoted

and the buggy EINVAL return both.

I believe that -EINVAL thing only affects RC devices that Mauro switched
to the new rc-core; input core in itself should be ABI compatible. Thus
I'll leave the decision to him whether he wants to revert or fix
compatibility issue.

quoted

As Mark said, breaking user space simply isn't acceptable. And since
breaking user space isn't acceptable, then incrementing the version is
stupid too.

It might not have been the best idea to increment, however I maintain
that if there exists version is can be changed. Otherwise there is no
point in having version at all.

As I said, reverting the version bump will cause yet another wave of
breakages so I propose leaving version as is.

quoted

The way we add new ioctl's is not by incrementing some "ABI version"
crap. It's by adding new ioctl's or system calls or whatever that
simply used to return -ENOSYS or other error before, while preserving
the old ABI. That way old binaries don't break (for _ANY_ reason), and
new binaries can see "oh, this doesn't support the new thing".

That has been done as well; we have 2 new ioctls and kept 2 old ioctls.

BTW, another issue is that evdev's ioctl returns -EINVAL for unknown
ioctls so applications would have hard time figuring out whether error
returned because of kernel being too old or because they are trying to
retrieve/establish invalid mapping if they had to go only by the error
code.

As far as I can see EINVAL is a proper error for unknown ioctls:

[dtor@hammer work]$ man 2 ioctl | grep EINVAL
       EINVAL Request or argp is not valid.
[dtor@hammer work]$

-- 
Dmitry