1. 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>
      72fb6d30
  2. 03 Jan, 2017 1 commit
  3. 12 Aug, 2015 1 commit
    • Peter Hutterer's avatar
      Add drag lock support · e3a888c3
      Peter Hutterer authored
      First, why is this here and not in libinput: drag lock should be implemented
      in the compositor (not in libinput) so it can provide feedback when it
      activates and grouped in with other accessibility features. That will work for
      Wayland but in X the compositor cannot filter button events - only the server
      and the drivers can.
      
      This patch adds mostly the same functionality that evdev provides with two
      options on how it works:
      * a single button number configures the given button to lock the next button
        pressed in a logically down state until a press+ release of that same button
        again
      * a set of button number pairs configures each button with the to-be-locked
        logical button, i.e. a pair of "1 3" will hold 3 logically down after a
        button 1 press
      
      The property and the xorg.conf options take the same configuration as the
      evdev driver (though the property has a different prefix, libinput instead of
      Evdev).
      
      The behavior difference to evdev is in how releases are handled, evdev sends
      the release on the second button press event, this implementation sends the
      release on the second release event.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=85577Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: 's avatarHans de Goede <hdegoede@redhat.com>
      e3a888c3