1. 30 May, 2019 1 commit
  2. 28 May, 2019 1 commit
    • Peter Hutterer's avatar
      dix: leave last.valuators alone on slave switch · 24086852
      Peter Hutterer authored
      dev->last.valuator[] is the last value given to us by the driver
      dev->valuator.axisVal[] is the last value sent to the client
      dev->last.scroll[] is the abs value of the scroll axis as given by the driver,
              used for button emulation calculation (and the remainder)
      This function updates the device's last.valuator state based on the current
      master axis state. This way, relative motion continues fluidly when switching
      between devices. Before mouse 2 comes into effect, it's valuator state is
      updated to wherever the pointer currently is so the relative event applies on
      top of that.
      This can only work for x/y axes, all other axes aren't guaranteed to have the
      same meaning and/or may not be present:
      - xtest device: no valuator 2
      - mouse: valuator 2 is horizontal scroll axis
      - tablet: valuator 2 is pressure
      Scaling the current value from the pressure range into the range for
      horizontal scrolling makes no sense. And it causes scroll jumps:
      - scroll down, last.valuator == axisVal == 20
      - xdotool click 1, the XTest device doesn't have that valuator
      - scroll up
        - updateSlaveDeviceCoords reset last.valuator to 0 (axisVal == 20)
        - DeviceClassesChangedEvent includes value 20 for the axis
        - event is processed, last.value changes from 0 to -1
        - axisVal is updated to -1, causing a jump of -21
      The same applies when we switch from tablet to mouse wheel if the pressure
      value is 0 on proximity out (basically guaranteed). So let's drop this code
      altogether and only leave the scaling for the relative x/y motion.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      (cherry picked from commit d7b1753d)
  3. 20 May, 2019 1 commit
    • Olivier Fourdan's avatar
      glamor: pixmap FBO may not be allocated · 5bc29a67
      Olivier Fourdan authored
      If `_glamor_create_tex()` fails to allocate the FBO because of
      GL_OUT_OF_MEMORY error, the `pixmap_priv->fbo` is NULL.
      However, `glamor_get_pixmap_texture()` doesn't actually check whether
      the `pixmap_priv->fbo` is NULL and will segfault with a NULL pointer
      dereference trying to access the `pixmap_priv->fbo->tex`.
      Signed-off-by: 's avatarOlivier Fourdan <ofourdan@redhat.com>
      Closes: #647
      (Cherry picked from commit 74479a99)
  4. 05 Apr, 2019 2 commits
  5. 25 Mar, 2019 3 commits
  6. 21 Mar, 2019 1 commit
    • Ray Strode's avatar
      dix: ensure work queues are cleared on reset · 34553f50
      Ray Strode authored
      If the server resets, most client workqueues are cleaned up as the
      clients are killed.
      The one exception is the server's client, which is exempt from
      the killing spree.
      If that client has a queued work procedure active, it won't get
      cleared on reset.
      This commit ensures it gets cleared too.
      (cherry picked from commit 8738ce85)
      Fixes: xorg/xserver#670
  7. 25 Feb, 2019 3 commits
  8. 22 Feb, 2019 13 commits
  9. 20 Feb, 2019 15 commits