1. 29 Sep, 2015 1 commit
    • Takashi Iwai's avatar
      Input: evdev - do not report errors form flush() · ed13441c
      Takashi Iwai authored
      commit eb38f3a4 upstream.
      
      We've got bug reports showing the old systemd-logind (at least
      system-210) aborting unexpectedly, and this turned out to be because
      of an invalid error code from close() call to evdev devices.  close()
      is supposed to return only either EINTR or EBADFD, while the device
      returned ENODEV.  logind was overreacting to it and decided to kill
      itself when an unexpected error code was received.  What a tragedy.
      
      The bad error code comes from flush fops, and actually evdev_flush()
      returns ENODEV when device is disconnected or client's access to it is
      revoked. But in these cases the fact that flush did not actually happen is
      not an error, but rather normal behavior. For non-disconnected devices
      result of flush is also not that interesting as there is no potential of
      data loss and even if it fails application has no way of handling the
      error. Because of that we are better off always returning success from
      evdev_flush().
      
      Also returning EINTR from flush()/close() is discouraged (as it is not
      clear how application should handle this error), so let's stop taking
      evdev->mutex interruptibly.
      
      Bugzilla: http://bugzilla.suse.com/show_bug.cgi?id=939834
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ed13441c
  2. 04 Feb, 2015 1 commit
  3. 10 Dec, 2014 1 commit
  4. 14 May, 2014 1 commit
  5. 29 Mar, 2014 1 commit
  6. 31 Oct, 2013 1 commit
    • Daniel Stone's avatar
      Input: evdev - fall back to vmalloc for client event buffer · 92eb77d0
      Daniel Stone authored
      
      evdev always tries to allocate the event buffer for clients using
      kzalloc rather than vmalloc, presumably to avoid mapping overhead where
      possible.  However, drivers like bcm5974, which claims support for
      reporting 16 fingers simultaneously, can have an extraordinarily large
      buffer.  The resultant contiguous order-4 allocation attempt fails due
      to fragmentation, and the device is thus unusable until reboot.
      
      Try kzalloc if we can to avoid the mapping overhead, but if that fails,
      fall back to vzalloc.
      Signed-off-by: default avatarDaniel Stone <daniels@collabora.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      92eb77d0
  7. 07 Sep, 2013 1 commit
    • David Herrmann's avatar
      Input: evdev - add EVIOCREVOKE ioctl · c7dc6573
      David Herrmann authored
      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.html
      
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      c7dc6573
  8. 10 Jun, 2013 1 commit
    • David Herrmann's avatar
      Input: evdev - flush queues during EVIOCGKEY-like ioctls · 48318028
      David Herrmann authored
      
      If userspace requests current KEY-state, they very likely assume that no
      such events are pending in the output queue of the evdev device.
      Otherwise, they will parse events which they already handled via
      EVIOCGKEY(). For XKB applications this can cause irreversible keyboard
      states if a modifier is locked multiple times because a CTRL-DOWN event is
      handled once via EVIOCGKEY() and once from the queue via read(), even
      though it should handle it only once.
      
      Therefore, lets do the only logical thing and flush the evdev queue
      atomically during this ioctl. We only flush events that are affected by
      the given ioctl.
      
      This only affects boolean events like KEY, SND, SW and LED. ABS, REL and
      others are not affected as duplicate events can be handled gracefully by
      user-space.
      
      Note: This actually breaks semantics of the evdev ABI. However,
      investigations showed that userspace already expects the new semantics and
      we end up fixing at least all XKB applications.
      All applications that are aware of this race-condition mirror the KEY
      state for each open-file and detect/drop duplicate events. Hence, they do
      not care whether duplicates are posted or not and work fine with this fix.
      
      Also note that we need proper locking to guarantee atomicity and avoid
      dead-locks. event_lock must be locked before queue_lock (see input-core).
      However, we can safely release event_lock while flushing the queue. This
      allows the input-core to proceed with pending events and only stop if it
      needs our queue_lock to post new events.
      This should guarantee that we don't block event-dispatching for too long
      while flushing a single event queue.
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      48318028
  9. 22 Oct, 2012 1 commit
  10. 08 Oct, 2012 1 commit
  11. 19 Sep, 2012 2 commits
  12. 02 May, 2012 2 commits
  13. 24 Feb, 2012 1 commit
  14. 09 Feb, 2012 1 commit
  15. 03 Feb, 2012 1 commit
    • John Stultz's avatar
      Input: add infrastructure for selecting clockid for event time stamps · a80b83b7
      John Stultz authored
      
      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: default avatarJohn Stultz <john.stultz@linaro.org>
      Reviewed-by: default avatarDaniel Kurtz <djkurtz@google.com>
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      a80b83b7
  16. 01 Feb, 2012 1 commit
  17. 30 Dec, 2011 3 commits
  18. 18 Jun, 2011 1 commit
  19. 12 May, 2011 1 commit
  20. 27 Apr, 2011 1 commit
    • Jeff Brown's avatar
      Input: evdev - only signal polls on full packets · cdda911c
      Jeff Brown authored
      
      This patch modifies evdev so that it only becomes readable when
      the buffer contains an EV_SYN/SYN_REPORT event.
      
      On SMP systems, it is possible for an evdev client blocked on poll()
      to wake up and read events from the evdev ring buffer at the same
      rate as they are enqueued.  This can result in high CPU usage,
      particularly for MT devices, because the client ends up reading
      events one at a time instead of reading complete packets.
      
      We eliminate this problem by making the device readable only when
      the buffer contains at least one complete packet.  This causes
      clients to block until the entire packet is available.
      Signed-off-by: default avatarJeff Brown <jeffbrown@android.com>
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      cdda911c
  21. 13 Apr, 2011 1 commit
  22. 27 Feb, 2011 1 commit
  23. 20 Dec, 2010 1 commit
    • Henrik Rydberg's avatar
      Input: introduce device properties · 85b77200
      Henrik Rydberg authored
      
      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: default avatarPing Cheng <pingc@wacom.com>
      Acked-by: default avatarChase Douglas <chase.douglas@canonical.com>
      Acked-by: default avatarDmitry Torokhov <dtor@mail.ru>
      Signed-off-by: default avatarHenrik Rydberg <rydberg@euromail.se>
      85b77200
  24. 15 Dec, 2010 1 commit
    • Dmitry Torokhov's avatar
      Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2 · ab4e0192
      Dmitry Torokhov authored
      
      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: default avatarHenrik Rydberg <rydberg@euromail.se>
      Acked-by: default avatarJarod Wilson <jarod@redhat.com>
      Acked-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      ab4e0192
  25. 01 Dec, 2010 1 commit
  26. 18 Oct, 2010 2 commits
    • Daniel Mack's avatar
      Input: evdev - fix EVIOCSABS regression · f9ce6eb5
      Daniel Mack authored
      448cd166
      
       ("Input: evdev - rearrange ioctl handling") broke EVIOCSABS by
      checking for the wrong direction bit.
      Signed-off-by: default avatarDaniel Mack <zonque@gmail.com>
      Reported-by: default avatarSven Neumann <s.neumann@raumfeld.com>
      Tested-by: default avatarSven Neumann <s.neumann@raumfeld.com>
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      f9ce6eb5
    • Daniel Mack's avatar
      Input: evdev - fix Ooops in EVIOCGABS/EVIOCSABS · 0a74a1df
      Daniel Mack authored
      
      This fixes a regression introduced by the dynamic allocation of absinfo
      for input devices. We need to bail out early for input devices which
      don't have absolute axis.
      
      [  929.664303] Pid: 2989, comm: input Not tainted 2.6.36-rc8+ #14 MS-7260/MS-7260
      [  929.664318] EIP: 0060:[<c12bdc01>] EFLAGS: 00010246 CPU: 0
      [  929.664331] EIP is at evdev_ioctl+0x4f8/0x59f
      [  929.664341] EAX: 00000040 EBX: 00000000 ECX: 00000006 EDX: f45a1efc
      [  929.664355] ESI: 00000000 EDI: f45a1efc EBP: f45a1f24 ESP: f45a1eb8
      [  929.664369]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      [  929.664402]  f470da74 f6a30e78 f462c240 00000018 bfe4a260 00000000 f45b06fc 00000000
      [  929.664429] <0> 000000c4 b769d000 c3544620 f470da74 f45b06fc f45b06fc f45a1f38 c107dd1f
      [  929.664458] <0> f4710b74 000000c4 00000000 00000000 00000000 0000029d 00000a74 f4710b74
      [  929.664500]  [<c107dd1f>] ? handle_mm_fault+0x2be/0x59a
      [  929.664513]  [<c12bd709>] ? evdev_ioctl+0x0/0x59f
      [  929.664524]  [<c1099d30>] ? do_vfs_ioctl+0x494/0x4d9
      [  929.664538]  [<c10432a1>] ? up_read+0x16/0x29
      [  929.664550]  [<c101c818>] ? do_page_fault+0x2ff/0x32d
      [  929.664564]  [<c108d048>] ? do_sys_open+0xc5/0xcf
      [  929.664575]  [<c1099db6>] ? sys_ioctl+0x41/0x61
      [  929.664587]  [<c1002710>] ? sysenter_do_call+0x12/0x36
      [  929.684570] ---[ end trace 11b83e923bd8f2bb ]---
      Signed-off-by: default avatarDaniel Mack <zonque@gmail.com>
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      0a74a1df
  27. 15 Oct, 2010 1 commit
    • Arnd Bergmann's avatar
      llseek: automatically add .llseek fop · 6038f373
      Arnd Bergmann authored
      All file_operations should get a .llseek operation so we can make
      nonseekable_open the default for future file operations without a
      .llseek pointer.
      
      The three cases that we can automatically detect are no_llseek, seq_lseek
      and default_llseek. For cases where we can we can automatically prove that
      the file offset is always ignored, we use noop_llseek, which maintains
      the current behavior of not returning an error from a seek.
      
      New drivers should normally not use noop_llseek but instead use no_llseek
      and call nonseekable_open at open time.  Existing drivers can be converted
      to do the same when the maintainer knows for certain that no user code
      relies on calling seek on the device file.
      
      The generated code is often incorrectly indented and right now contains
      comments that clarify for each added line why a specific variant was
      chosen. In the version that gets submitted upstream, the comments will
      be gone and I will manually fix the indentation, because there does not
      see...
      6038f373
  28. 10 Sep, 2010 1 commit
    • Mauro Carvalho Chehab's avatar
      Input: add support for large scancodes · 8613e4c2
      Mauro Carvalho Chehab authored
      
      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: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      Signed-off-by: default avatarDan Carpenter <error27@gmail.com>
      Signed-off-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      8613e4c2
  29. 20 Aug, 2010 1 commit
  30. 03 Aug, 2010 3 commits
  31. 16 Jul, 2010 3 commits