diff options
author | Dmitry Torokhov <dmitry.torokhov@gmail.com> | 2010-12-14 23:53:21 -0800 |
---|---|---|
committer | Dmitry Torokhov <dmitry.torokhov@gmail.com> | 2010-12-14 23:55:21 -0800 |
commit | ab4e0192196b8d4e43a3945742d4996da934a86f (patch) | |
tree | 7aeeec6e5fe84dcb1b3026c7cc6c0f81807f0922 /fs/btrfs/extent_io.c | |
parent | 57a7872fa0f03e90be0fa224b9ea533f5b03ee4f (diff) |
Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2
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.
Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
Acked-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Diffstat (limited to 'fs/btrfs/extent_io.c')
0 files changed, 0 insertions, 0 deletions