On Wed, Jan 26, 2011 at 10:05:57AM -0500, Mark Lord wrote: > 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) > It would be much more helpful if you tried to test what has been fixed (hint: version change wasn't it). -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
