1. 16 Apr, 2019 1 commit
    • Alex Goins's avatar
      xsync: Add resource inside of SyncCreate, export SyncCreate · a330d80c
      Alex Goins authored
      As shown by DRI3 adding the SyncCreateFenceFromFD() function, extensions may
      want to create a fence, then initialize it in their own way. This currently
      can't be done without adding a function directly to Xext/sync.c due to the fact
      that the RTFence resource type is private and there is no external interface to
      add to it.
      To facilitate other X extensions creating fences and initializing them, this
      change exports SyncCreate() and adds the resource directly within it. Callers no
      longer need to call AddResource() after SyncCreate(), they only need to
      initialize the SyncObject.
      To prevent FreeFence() and FreeCounter() from segfaulting if the call to
      AddResource() fails before the sync object is initialized, this adds a new
      'initialized' parameter to SyncObject that, when FALSE, causes FreeFence() and
      FreeCounter() to skip de-initialization and simply free the object.
      Initialization after adding the resource shouldn't otherwise be a problem due to
      the single-threaded nature of X.
      Signed-off-by: Alex Goins's avatarAlex Goins <agoins@nvidia.com>
  2. 12 Apr, 2019 4 commits
    • Adam Jackson's avatar
      dix: Remove WindowRec::backStorage · 69758079
      Adam Jackson authored and Adam Jackson's avatar Adam Jackson committed
      This is only being set, never read.
    • Adam Jackson's avatar
      dix, composite: Optimize setting window backing store state · 0f477cc6
      Adam Jackson authored and Adam Jackson's avatar Adam Jackson committed
      We hide CWBackingStore from the screen hook if nothing's actually
      changing, which means compChangeWindowAttributes no longer needs to
      compare the requested state with the present one.
    • Adam Jackson's avatar
      mi: Simplify a conditional in miHandleExposures · 4e101e7e
      Adam Jackson authored and Adam Jackson's avatar Adam Jackson committed
      miHandleExposures does two things: computes the region for which to
      generate expose events, and (if the destination is a window) paints the
      exposed regions with the background. The bit of this conditional we're
      deleting here asserts that the source is either a pixmap or a window
      without backing store. The only other possibility is a window _with_
      backing store. In the old backing store implementation, this was where
      you would recover bits from backing store. Since our "backing store" is
      the redirected window pixmap, we know we've already copied all we could,
      because CopyArea had already seen the entire window pixmap. So now in
      that third case, we are still drawing to a pixmap (so there's no
      background to paint) and we are still not generating events, so we can
      exit early.
      The comment above the function about recovering bits from backing store
      is clearly misleading, so delete that too.
    • Aaron Plattner's avatar
      xfree86: Export xf86GPUScreens and xf86NumGPUScreens · 147ed28b
      Aaron Plattner authored and Adam Jackson's avatar Adam Jackson committed
      Drivers may need to loop over the allocated screens during PreInit, for example
      to consolidate xorg.conf options that apply to a GPU device as a whole.
      Currently, this works for protocol screens becuase x86Screens is exported, but
      does not work for GPU screens.
      Export xf86GPUScreens and xf86NumGPUScreens for consistency with xf86Screens and
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
  3. 04 Apr, 2019 1 commit
  4. 02 Apr, 2019 2 commits
  5. 01 Apr, 2019 3 commits
  6. 29 Mar, 2019 2 commits
    • Roman Gilg's avatar
      present: Call present_vblank_scrap in screen mode · 4adda1f6
      Roman Gilg authored and Michel Dänzer's avatar Michel Dänzer committed
      This cleans up some code duplication. No functional change.
      Signed-off-by: Roman Gilg's avatarRoman Gilg <subdiff@gmail.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.com>
    • Peter Hutterer's avatar
      dix: leave last.valuators alone on slave switch · d7b1753d
      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>
  7. 28 Mar, 2019 8 commits
  8. 27 Mar, 2019 6 commits
  9. 20 Mar, 2019 2 commits
  10. 15 Mar, 2019 1 commit
  11. 14 Mar, 2019 1 commit
  12. 13 Mar, 2019 2 commits
  13. 11 Mar, 2019 3 commits
  14. 08 Mar, 2019 4 commits