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

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

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.

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.

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.

-- 
Dmitry