Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 19 6月, 2016 1 次提交
  3. 11 3月, 2016 1 次提交
  5. 27 10月, 2015 1 次提交
    • D
      Input: evdev - add event-mask API · 06a16293
      由 David Herrmann 提交于 
      Hardware manufacturers group keys in the weirdest way possible. This may
cause a power-key to be grouped together with normal keyboard keys and
thus be reported on the same kernel interface.

However, user-space is often only interested in specific sets of events.
For instance, daemons dealing with system-reboot (like systemd-logind)
listen for KEY_POWER, but are not interested in any main keyboard keys.
Usually, power keys are reported via separate interfaces, however,
some i8042 boards report it in the AT matrix. To avoid waking up those
system daemons on each key-press, we had two ideas:
 - split off KEY_POWER into a separate interface unconditionally
 - allow filtering a specific set of events on evdev FDs

Splitting of KEY_POWER is a rather weird way to deal with this and may
break backwards-compatibility. It is also specific to KEY_POWER and might
be required for other stuff, too. Moreover, we might end up with a huge
set of input-devices just to have them properly split.

Hence, this patchset implements the second idea: An event-mask to specify
which events you're interested in. Two ioctls allow setting this mask for
each event-type. If not set, all events are reported. The type==0 entry is
used same as in EVIOCGBIT to set the actual EV_* mask of filtered events.
This way, you have a two-level filter.

We are heavily forward-compatible to new event-types and event-codes. So
new user-space will be able to run on an old kernel which doesn't know the
given event-codes or event-types.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      06a16293
  7. 17 10月, 2015 3 次提交
  9. 21 3月, 2015 1 次提交
    • C
      Input: add MT_TOOL_PALM · a736775d
      由 Charlie Mooney 提交于 
      Currently there are only two "tools" that can be specified by a multi-touch
driver: MT_TOOL_FINGER and MT_TOOL_PEN. In working with Elan (The touch
vendor) and discussing their next-gen devices it seems that it will be
useful to have more tools so that their devices can give the upper layers
of the stack hints as to what is touching the sensor.

In particular they have new experimental firmware that can better
differentiate between palms vs fingertips and would like to plumb a patch
so that we can use their hints in higher-level gesture soft- ware.  The
firmware on the device can reasonably do a better job of palm detection
because it has access to all of the raw sensor readings as opposed to just
the width/pressure/etc that are exposed by the driver.  As such, the
firmware can characterize what a palm looks like in much finer-grained
detail and this change would allow such a device to share its findings with
the kernel.
Signed-off-by: NCharlie Mooney <charliemooney@chromium.org>
Acked-by: NPeter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      a736775d
  11. 07 3月, 2015 1 次提交
  13. 05 3月, 2015 1 次提交
    • D
      HID: map telephony usage page · f3dddf24
      由 Dmitry Torokhov 提交于 
      Currently HID code maps usages from telephony page into BTN_0, BTN_1, etc
keys which get interpreted by mousedev and userspace as left/right/middle
button clicks, which is not really helpful.

This change adds mappings for usages that have corresponding input event
definitions, and leaves the rest unmapped. This can be changed when
there are userspace consumers for more telephony usages.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      f3dddf24
  15. 29 1月, 2015 1 次提交
  17. 21 10月, 2014 1 次提交
  19. 09 9月, 2014 1 次提交
  21. 28 4月, 2014 1 次提交
  23. 20 4月, 2014 1 次提交
    • H
      Input: Add INPUT_PROP_TOPBUTTONPAD device property · f37c0134
      由 Hans de Goede 提交于 
      On some newer laptops with a trackpoint the physical buttons for the
trackpoint have been removed to allow for a larger touchpad. On these
laptops the buttonpad has clearly marked areas on the top which are to be
used as trackpad buttons.

Users of the event device-node need to know about this, so that they can
properly interpret BTN_LEFT events as being a left / right / middle click
depending on where on the button pad the clicking finger is.

This commits adds a INPUT_PROP_TOPBUTTONPAD device property which drivers
for such buttonpads will use to signal to the user that this buttonpad not
only has the normal bottom button area, but also a top button area.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      f37c0134
  25. 16 12月, 2013 1 次提交
  27. 06 12月, 2013 1 次提交
  29. 27 11月, 2013 1 次提交
  31. 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
  33. 04 9月, 2013 1 次提交
  35. 30 8月, 2013 1 次提交
  37. 27 6月, 2013 2 次提交
  39. 12 3月, 2013 1 次提交
  41. 15 11月, 2012 1 次提交
  43. 13 10月, 2012 1 次提交
  45. 09 10月, 2012 1 次提交
  47. 20 9月, 2012 2 次提交
  49. 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
  51. 12 6月, 2012 1 次提交
  53. 09 2月, 2012 1 次提交
  55. 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
  57. 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
  59. 05 10月, 2011 1 次提交
  61. 24 8月, 2011 1 次提交
  63. 06 8月, 2011 1 次提交
  65. 05 7月, 2011 1 次提交
  67. 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