[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4D06CE4C.3070003@redhat.com>
Date: Mon, 13 Dec 2010 23:54:20 -0200
From: Mauro Carvalho Chehab <mchehab@...hat.com>
To: Jarod Wilson <jarod@...hat.com>
CC: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Henrik Rydberg <rydberg@...omail.se>,
Linux Input <linux-input@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, linux-media@...r.kernel.org,
Jiri Kosina <jkosina@...e.cz>,
David Härdeman <david@...deman.nu>
Subject: Re: [RFC] Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2
Em 13-12-2010 16:31, Jarod Wilson escreveu:
> On Mon, Dec 13, 2010 at 01:06:00AM -0800, Dmitry Torokhov wrote:
>> On Thu, Dec 09, 2010 at 11:16:47AM -0800, Dmitry Torokhov wrote:
>>> On Thu, Dec 09, 2010 at 08:04:36PM +0100, Henrik Rydberg wrote:
>>>> On 12/09/2010 10:39 AM, Dmitry Torokhov wrote:
>>>>
>>>>> The desire to keep old names for the EVIOCGKEYCODE/EVIOCSKEYCODE while
>>>>> extending them to support large scancodes was a mistake. While we tried
>>>>> to keep ABI intact (and we succeeded in doing that, programs compiled
>>>>> on older kernels will work on newer ones) there is still a problem with
>>>>> recompiling existing software with newer kernel headers.
>>>>>
>>>>> New kernel headers will supply updated ioctl numbers and kernel will
>>>>> expect that userspace will use struct input_keymap_entry to set and
>>>>> retrieve keymap data. But since the names of ioctls are still the same
>>>>> userspace will happily compile even if not adjusted to make use of the
>>>>> new structure and will start miraculously fail in the field.
>>>>>
>>>>> To avoid this issue let's revert EVIOCGKEYCODE/EVIOCSKEYCODE definitions
>>>>> and add EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2 so that userspace can explicitly
>>>>> select the style of ioctls it wants to employ.
>>>>>
>>>>> Signed-off-by: Dmitry Torokhov <dtor@...l.ru>
>>>>> ---
>>>>
>>>>
>>>> Would the header change suffice in itself?
>>>
>>> We still need to change evdev to return -EINVAL on wrong sizes but yes,
>>> the amount of change there could be more limited. I just thought that
>>> splitting it up explicitly shows the differences in handling better. If
>>> people prefer the previos version we could leave it, I am 50/50 between
>>> them.
>>>
>>
>> *ping*
>>
>> Mauro, Jarod, do you have an opinion on this? I think we need to settle
>> on a solution before 2.6.37 is out.
>
> Sorry, been meaning to reply, just been quite tied up with other work...
> I'm of two minds on this as well, but probably leaning slightly in favor
> of going ahead with an explicit _V2 so as to not break existing userspace
> in new and unexpected ways. There presumably isn't much in the way of
> userspace already adapted to the new interface, and its simple to do
> another rev of those that have been. Okay, yeah, this is probably the best
> way to go about it.
>
> Acked-by: Jarod Wilson <jarod@...hat.com>
>
>
I'm with some email troubles here. Not sure if you got my answer. I'm OK with
those changes.
Acked-by: Mauro Carvalho Chehab <mchehab@...hat.com
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists