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

Em 26-01-2011 13:05, Mark Lord escreveu:

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)

You need to relax the version test at the tree. As I said before, this is
a development tool from the early RC days, bound to work with one specific
version of the API, and programmed by purpose to fail if there would by any
updates at the Input layer.

Cheers,
Mauro.