On Wed, Jan 26, 2011 at 10:05:57AM -0500, Mark Lord wrote:

On 11-01-25 09:00 PM, Dmitry Torokhov wrote:

quoted

On Tue, Jan 25, 2011 at 03:29:14PM -0800, Dmitry Torokhov wrote:

quoted

On Tue, Jan 25, 2011 at 05:22:09PM -0500, Mark Lord wrote:

quoted

On 11-01-25 05:00 PM, Mauro Carvalho Chehab wrote:

quoted

Em 25-01-2011 18:54, Dmitry Torokhov escreveu:

..

quoted

quoted

quoted

quoted

quoted

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

That's the problem: you did NOT keep the two old ioctls().
Those got changed too.. so now we have four NEW ioctls(),
none of which backward compatible with userspace.

Please calm down. This, in fact, is not new vs old ioctl problem but
rather particular driver (or rather set of drivers) implementation
issue. Even if we drop the new ioctls and convert the RC code to use the
old ones you'd be observing the same breakage as RC code responds with
-EINVAL to not-yet-established mappings.

I'll see what can be done for these drivers; I guess we could supply a
fake KEY_RESERVED entry for not mapped scancodes if there are mapped
scancodes "above" current one. That should result in the same behavior
for RCs as before.

I wonder if the patch below is all that is needed...

Nope. Does not work here:

$ lsinput
protocol version mismatch (expected 65536, got 65537)

It would be much more helpful if you tried to test what has been fixed
(hint: version change wasn't it).

-- 
Dmitry