Em 26-01-2011 13:05, Mark Lord escreveu: > On 11-01-25 09:00 PM, Dmitry Torokhov wrote: >> On Tue, Jan 25, 2011 at 03:29:14PM -0800, Dmitry Torokhov wrote: >>> On Tue, Jan 25, 2011 at 05:22:09PM -0500, Mark Lord wrote: >>>> On 11-01-25 05:00 PM, Mauro Carvalho Chehab wrote: >>>>> Em 25-01-2011 18:54, Dmitry Torokhov escreveu: > .. >>>>>> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
