Re: [RFC] Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2

Re: [RFC] Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2

[Dmitry Torokhov]

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@mail.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.

Thanks.

-- 
Dmitry

Re: [RFC] Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2

[Jarod Wilson]

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@mail.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@redhat.com>


-- 
Jarod Wilson
jarod@redhat.com

Re: [RFC] Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2

[Mauro Carvalho Chehab]

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@mail.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@redhat.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@redhat.com

Cheers,
Mauro