1. 28 Apr, 2015 2 commits
  2. 23 Apr, 2015 2 commits
  3. 17 Mar, 2015 4 commits
  4. 16 Mar, 2015 1 commit
  5. 06 Mar, 2015 2 commits
  6. 05 Mar, 2015 1 commit
  7. 02 Mar, 2015 2 commits
  8. 26 Feb, 2015 3 commits
  9. 25 Feb, 2015 1 commit
    • Olivier Fourdan's avatar
      Ignore property changes if the device is disabled · 98ae01b9
      Olivier Fourdan authored
      If the device is present but disabled, the server will still call into
      SetProperty. We don't have a libinput device to back it up in this case,
      causing a null-pointer dereference.
      
      This is a bug specific to this driver that cannot easily be fixed. All
      other drivers can handle property changes even if no device is present,
      here we rely on libinput to make the final call. But without a device
      path/fd we don't have a libinput reference.
      
      The protocol doesn't mention this case, so let's pick BadMatch as the
      least wrong error code. And put a warning in the log, this needs a
      workaround in the client.
      
      Also, if we get here and the device is on, then that's definitely a bug,
      warn about that.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=89296Signed-off-by: 's avatarOlivier Fourdan <ofourdan@redhat.com>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      98ae01b9
  10. 24 Feb, 2015 2 commits
  11. 04 Feb, 2015 1 commit
  12. 29 Jan, 2015 2 commits
  13. 27 Jan, 2015 1 commit
  14. 26 Jan, 2015 1 commit
  15. 21 Jan, 2015 2 commits
  16. 20 Jan, 2015 2 commits
  17. 19 Jan, 2015 2 commits
  18. 16 Jan, 2015 1 commit
  19. 15 Jan, 2015 1 commit
  20. 07 Dec, 2014 1 commit
    • Peter Hutterer's avatar
      Support server-side fds · 0c4eaf54
      Peter Hutterer authored
      libinput's device handling and server-side fd handling are a bit of a
      mismatch, so this is hackier than one would hope for.
      
      The server sets pInfo->fd and the options "fd" and "device".
      The server requires pInfo->fd to be the one triggering select(2) to call the
      correct pInfo->read_input. We can't pass an fd to use into libinput, all we
      have is the open_restricted callback. That callback gives us the context, but
      not the pInfo with the fd we want.
      
      The solution:
      1) In PreInit, store the patch + fd combination in a driver-wide list. Search
      that list for an fd in open_restricted, return the pre-openend fd.
      
      2) Overwrite all devices' pInfo->fd with the libinput epollfd. In this driver
      we don't care about which device read_input is called on, we get the correct
      pInfo to post events from through the struct libinput_device of the libinput
      events.
      
      3) When a device is closed, swap the real fd back in so systemd-logind closes the
      right fd.
      
      This saves us worrying about keeping the right refcount on who currently has
      the fd set to the libinput fd. We just set it for all devices, let the server
      figure out which device to call (the first in inputInfo.devices) and we only
      need to remember to swap it back during DEVICE_OFF.
      
      If the server calls close on a pInfo->fd without telling the driver, that's a
      bug anyway.
      
      This patch also drops the pInfo->fd = -1 calls, they've been unnecessary since
      at least 1.11, possibly earlier.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: 's avatarHans de Goede <hdegoede@redhat.com>
      0c4eaf54
  21. 05 Dec, 2014 3 commits
  22. 01 Dec, 2014 3 commits