Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 16 12月, 2013 1 次提交
  3. 06 12月, 2013 1 次提交
  5. 27 11月, 2013 1 次提交
  7. 08 9月, 2013 2 次提交
    • D
      Input: evdev - add EVIOCREVOKE ioctl · c7dc6573
      由 David Herrmann 提交于 
      If we have multiple sessions on a system, we normally don't want
background sessions to read input events. Otherwise, it could capture
passwords and more entered by the user on the foreground session. This is
a real world problem as the recent XMir development showed:
  http://mjg59.dreamwidth.org/27327.html

We currently rely on sessions to release input devices when being
deactivated. This relies on trust across sessions. But that's not given on
usual systems. We therefore need a way to control which processes have
access to input devices.

With VTs the kernel simply routed them through the active /dev/ttyX. This
is not possible with evdev devices, though. Moreover, we want to avoid
routing input-devices through some dispatcher-daemon in userspace (which
would add some latency).

This patch introduces EVIOCREVOKE. If called on an evdev fd, this revokes
device-access irrecoverably for that *single* open-file. Hence, once you
call EVIOCREVOKE on any dup()ed fd, all fds for that open-file will be
rather useless now (but still valid compared to close()!). This allows us
to pass fds directly to session-processes from a trusted source. The
source keeps a dup()ed fd and revokes access once the session-process is
no longer active.
Compared to the EVIOCMUTE proposal, we can avoid the CAP_SYS_ADMIN
restriction now as there is no way to revive the fd again. Hence, a user
is free to call EVIOCREVOKE themself to kill the fd.

Additionally, this ioctl allows multi-layer access-control (again compared
to EVIOCMUTE which was limited to one layer via CAP_SYS_ADMIN). A middle
layer can simply request a new open-file from the layer above and pass it
to the layer below. Now each layer can call EVIOCREVOKE on the fds to
revoke access for all layers below, at the expense of one fd per layer.

There's already ongoing experimental user-space work which demonstrates
how it can be used:
  http://lists.freedesktop.org/archives/systemd-devel/2013-August/012897.htmlSigned-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      c7dc6573
    • L
      Revert "Input: introduce BTN/ABS bits for drums and guitars" · b04c99e3
      由 Linus Torvalds 提交于 
      This reverts commits 61e00655, 73f8645d and 8e22ecb6:
  "Input: introduce BTN/ABS bits for drums and guitars"
  "HID: wiimote: add support for Guitar-Hero drums"
  "HID: wiimote: add support for Guitar-Hero guitars"

The extra new ABS_xx values resulted in ABS_MAX no longer being a
power-of-two, which broke the comparison logic.  It also caused the
ioctl numbers to overflow into the next byte, causing problems for that.

We'll try again for 3.13.
Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Acked-by: NDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b04c99e3
  9. 04 9月, 2013 1 次提交
  11. 30 8月, 2013 1 次提交
  13. 27 6月, 2013 2 次提交
  15. 12 3月, 2013 1 次提交
  17. 15 11月, 2012 1 次提交
  19. 13 10月, 2012 1 次提交
  21. 09 10月, 2012 1 次提交
  23. 20 9月, 2012 2 次提交
  25. 05 7月, 2012 1 次提交
    • H
      Input: MT - Include win8 support · cab7faca
      由 Henrik Rydberg 提交于 
      The newly released HID protocol for win8 multitouch devices is capable
of transmitting more information about each touch. In particular, it
includes details useful for touch alignment. This patch completes the
MT protocol with the ABS_MT_TOOL_X/Y events, and documents how to map
win8 devices.

Cc: Stephane Chatty <chatty@enac.fr>
Cc: Benjamin Tissoires <benjamin.tissoires@enac.fr>
Cc: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: NChase Douglas <chase.douglas@canonical.com>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
      cab7faca
  27. 12 6月, 2012 1 次提交
  29. 09 2月, 2012 1 次提交
  31. 03 2月, 2012 1 次提交
    • J
      Input: add infrastructure for selecting clockid for event time stamps · a80b83b7
      由 John Stultz 提交于 
      As noted by Arve and others, since wall time can jump backwards, it is
difficult to use for input because one cannot determine if one event
occurred before another or for how long a key was pressed.

However, the timestamp field is part of the kernel ABI, and cannot be
changed without possibly breaking existing users.

This patch adds a new IOCTL that allows a clockid to be set in the
evdev_client struct that will specify which time base to use for event
timestamps (ie: CLOCK_MONOTONIC instead of CLOCK_REALTIME).

For now we only support CLOCK_MONOTONIC and CLOCK_REALTIME, but
in the future we could support other clockids if appropriate.

The default remains CLOCK_REALTIME, so we don't change the ABI.
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Reviewed-by: NDaniel Kurtz <djkurtz@google.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      a80b83b7
  33. 13 10月, 2011 1 次提交
    • D
      Input: force feedback - potential integer wrap in input_ff_create() · 05be8b81
      由 Dan Carpenter 提交于 
      The problem here is that max_effects can wrap on 32 bits systems.
We'd allocate a smaller amount of data than sizeof(struct ff_device).
The call to kcalloc() on the next line would fail but it would write
the NULL return outside of the memory we just allocated causing data
corruption.

The call path is that uinput_setup_device() get ->ff_effects_max from
the user and sets the value in the ->private_data struct.  From there
it is:
-> uinput_ioctl_handler()
   -> uinput_create_device()
      -> input_ff_create(dev, udev->ff_effects_max);

I've also changed ff_effects_max so it's an unsigned int instead of
a signed int as a cleanup.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      05be8b81
  35. 05 10月, 2011 1 次提交
  37. 24 8月, 2011 1 次提交
  39. 06 8月, 2011 1 次提交
  41. 05 7月, 2011 1 次提交
  43. 13 4月, 2011 2 次提交
    • J
      Input: evdev - indicate buffer overrun with SYN_DROPPED · 9fb0f14e
      由 Jeff Brown 提交于 
      Add a new EV_SYN code, SYN_DROPPED, to inform the client when input
events have been dropped from the evdev input buffer due to a
buffer overrun.  The client should use this event as a hint to
reset its state or ignore all following events until the next
packet begins.
Signed-off-by: NJeff Brown <jeffbrown@android.com>
[dtor@mail.ru: Implement Henrik's suggestion and drop old events in
 case of overflow.]
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      9fb0f14e
    • J
      Input: add KEY_IMAGES specifically for AL Image Browser · ba6a078b
      由 Jarod Wilson 提交于 
      Many media center remotes have buttons intended for jumping straight to
one type of media browser or another -- commonly, images/photos/pictures,
audio/music, television, and movies. At present, remotes with an images
or photos or pictures button use any number of different keycodes which
sort of maybe fit. I've seen at least KEY_MEDIA, KEY_CAMERA,
KEY_GRAPHICSEDITOR and KEY_PRESENTATION. None of those seem quite right.
In my mind, KEY_MEDIA should be something more like a media center
application launcher (and I'd like to standardize on that for things
like the windows media center button on the mce remotes). KEY_CAMERA is
used in a lot of webcams, and typically means "take a picture now".
KEY_GRAPHICSEDITOR implies an editor, not a browser. KEY_PRESENTATION
might be the closest fit here, if you think "photo slide show", but it
may well be more intended for "run application in full-screen
presentation mode" or to launch something like magicpoint, I dunno.
And thus, I'd like to have a KEY_IMAGES, which matches the HID Usage AL
Image Browser, the meaning of which I think is crystal-clear. I believe
AL Audio Browser is already covered by KEY_AUDIO, and AL Movie Browser
by KEY_VIDEO, so I'm also adding appropriate comments next to those
keys.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      ba6a078b
  45. 28 3月, 2011 1 次提交
  47. 01 2月, 2011 1 次提交
  49. 12 1月, 2011 1 次提交
  51. 29 12月, 2010 1 次提交
  53. 20 12月, 2010 1 次提交
    • H
      Input: introduce device properties · 85b77200
      由 Henrik Rydberg 提交于 
      Today, userspace sets up an input device based on the data it emits.
This is not always enough; a tablet and a touchscreen may emit exactly
the same data, for instance, but the former should be set up with a
pointer whereas the latter does not need to. Recently, a new type of
touchpad has emerged where the buttons are under the pad, which
changes logic without changing the emitted data. This patch introduces
a new ioctl, EVIOCGPROP, which enables user access to a set of device
properties useful during setup. The properties are given as a bitmap
in the same fashion as the event types, and are also made available
via sysfs, uevent and /proc/bus/input/devices.
Acked-by: NPing Cheng <pingc@wacom.com>
Acked-by: NChase Douglas <chase.douglas@canonical.com>
Acked-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
      85b77200
  55. 16 12月, 2010 3 次提交
  57. 15 12月, 2010 1 次提交
    • D
      Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2 · ab4e0192
      由 Dmitry Torokhov 提交于 
      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: NHenrik Rydberg <rydberg@euromail.se>
Acked-by: NJarod Wilson <jarod@redhat.com>
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      ab4e0192
  59. 01 12月, 2010 2 次提交
  61. 04 11月, 2010 1 次提交
  63. 10 9月, 2010 1 次提交
    • M
      Input: add support for large scancodes · 8613e4c2
      由 Mauro Carvalho Chehab 提交于 
      Several devices use a high number of bits for scancodes. One important
group is the Remote Controllers. Some new protocols like RC-6 define a
scancode space of 64 bits.

The current EVIO[CS]GKEYCODE ioctls allow replace the scancode/keycode
translation tables, but it is limited to up to 32 bits for scancode.

Also, if userspace wants to clean the existing table, replacing it by
a new one, it needs to run a loop calling the ioctls over the entire
sparse scancode space.

To solve those problems, this patch extends the ioctls to allow drivers
handle scancodes up to 32 bytes long (the length could be extended in
the future should such need arise) and allow userspace to query and set
scancode to keycode mappings not only by scancode but also by index.

Compatibility code were also added to handle the old format of
EVIO[CS]GKEYCODE ioctls.

Folded fixes by:
- Dan Carpenter: locking fixes for the original implementation
- Jarod Wilson: fix crash when setting keycode and wiring up get/set
                handlers in original implementation.
- Dmitry Torokhov: rework to consolidate old and new scancode handling,
                   provide options to act either by index or scancode.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      8613e4c2
  65. 06 9月, 2010 1 次提交