1. 09 Mar, 2017 1 commit
  2. 28 Feb, 2017 1 commit
    • Peter Hutterer's avatar
      test: fix a test failure on ppc64(le) and aarch64 · 72fb6d30
      Peter Hutterer authored
      Caused by different results in -O0 vs -O2. The resulting array differs only
      slightly but the initial sequence has one extra zero. That triggers our
      assert, no other compiler flag seem to be affecting this.
      Compiled with -O0:
      Breakpoint 1, test_nonzero_x_linear () at test-bezier.c:157
      157			assert(bezier[x] > bezier[x-1]);
      (gdb) p bezier
      $6 = {0 <repeats 409 times>, 1, 2, 4, 5, 7, 9, 10, 12, 14, 15, 17, 19, 21, 22,
      Compiled with -O2:
      (gdb) p bezier
      $1 = {0 <repeats 410 times>, 1, 3, 5, 7, 9, 10, 12, 14, 15, 17, 19, 20, 22,
      Printing of the temporary numbers in the decasteljau function shows that a few
      of them are off by one, e.g.
          408.530612/0.836735 with O0, but
          409.510204/0.836735 with O2
      Note: these are not rounding errors caused by the code, the cast to int
      happens afterwards.
      Hack around this by allowing for one extra zero before we check that the rest
      of the curve is ascending again.
      https://bugs.freedesktop.org/show_bug.cgi?id=99992Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  3. 26 Feb, 2017 3 commits
  4. 09 Feb, 2017 1 commit
  5. 27 Jan, 2017 1 commit
  6. 26 Jan, 2017 2 commits
  7. 12 Jan, 2017 1 commit
    • Peter Hutterer's avatar
      Add tablet tool area ratio property · 974ab6b6
      Peter Hutterer authored
      By default, the X server maps the tablet axes to the available screen area.
      When a tablet is mapped to the screen but has a different aspect ratio than
      the screen, input data is skewed. Expose an area ratio property to map the
      a subsection of the available tablet area into the desired ratio.
      Differences to the wacom driver: there the x/y min/max values must be
      specified manually and in device coordinates. For this driver we merely
      provide the area ratio (e.g. 4:3) and let the driver work out the rest.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: Jason Gerecke's avatarJason Gerecke <jason.gerecke@wacom.com>
  8. 03 Jan, 2017 5 commits
  9. 20 Dec, 2016 1 commit
  10. 12 Dec, 2016 1 commit
  11. 05 Dec, 2016 1 commit
  12. 19 Nov, 2016 1 commit
    • Peter Hutterer's avatar
      If the parent libinput_device is unavailable, create a new one · 72bac84d
      Peter Hutterer authored
      The parent device ref's the libinput device during pre_init and unref's it
      during DEVICE_INIT, so the copy is lost. During DEVICE_ON, the libinput device
      is re-added and ref'd, this one stays around now. But the takeaway is: unless
      the device is enabled, no libinput device reference is available.
      If a device is a mixed pointer + keyboard device, a subdevice is created
      during a WorkProc. The subdevice relied on the parent's libinput_device being
      available and didn't even check for it. This WorkProc usually runs after
      the parent's DEVICE_ON, so in most cases all is well.
      But when running without logind and the server is vt-switched away, the parent
      device only runs PreInit and DEVICE_INIT but never DEVICE_ON, causing the
      subdevice to burn, crash, and generally fail horribly when it dereferences the
      parent's libinput device.
      Fix this because we have global warming already and don't need to burn more
      things and also because it's considered bad user experience to have the
      server crash. The simple fix is to check the parent device first and if it is
      unavailable, create a new one because it will end up disabled as well anyway,
      so the ref goes away as well. The use-case where the parent somehow gets
      disabled but the subdevice doesn't is a bit too niche to worry about.
      This doesn't happen with logind because in that case we don't get a usable fd
      while VT-switched away, so we can't even run PreInit and never get this far
      (see the paused fd handling in the xfree86 code for that). It can be
      reproduced by setting AutoEnableDevices off, but why would you do that,
      https://bugs.freedesktop.org/show_bug.cgi?id=97117Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
  13. 14 Nov, 2016 1 commit
  14. 01 Nov, 2016 2 commits
  15. 27 Oct, 2016 2 commits
  16. 20 Oct, 2016 1 commit
  17. 19 Oct, 2016 5 commits
  18. 18 Oct, 2016 2 commits
  19. 14 Oct, 2016 1 commit
  20. 30 Sep, 2016 1 commit
  21. 21 Sep, 2016 1 commit
  22. 18 Sep, 2016 1 commit
  23. 13 Sep, 2016 1 commit
  24. 09 Sep, 2016 1 commit
    • Peter Hutterer's avatar
      Always delay hotplugging subdevices · fa69bb1b
      Peter Hutterer authored
      Avoid creating new devices from within the input thread which was the case for
      tablet tools. It requires a lot more care about locking and has a potential to
      mess up things.
      Instead, schedule a WorkProc and buffer all events until we have the device
      created. Once that's done, replay the event sequence so far. If the device
      comes into proximity and out again before we manage to create the new device
      we just ditch the whole sequence and wait for the next proximity in.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  25. 07 Sep, 2016 1 commit
  26. 31 Aug, 2016 1 commit