1. 01 May, 2019 2 commits
    • Adam Jackson's avatar
      glx: Fix GLX_CONTEXT_RELEASE_BEHAVIOR_ARB handling · 007d812a
      Adam Jackson authored
      None of this was getting compiled because we hadn't defined the macro
      (and aren't getting them from <GL/glxext.h> because reasons). Fix that.
      Fixes: xorg/xserver#684
    • Jon Turney's avatar
      hw/xwin: Remove mwextwm mode · a2302de6
      Jon Turney authored
      This has always been described as 'experimental'
      We don't think this has any users: This mode has been disabled in Cygwin
      packages since March 2016. We've never provided the xwinwm WM for x86_64
      Cygwin. No one has even asked where the option has gone.
      This leaves XQuartz as the only user of the rootless extension.
      Remove --enable-windowswm configure option
      Remove multiwindowextwm stuff from Makefiles
      Remove -mwextwm option
      Remove -mwextwm from man-page and help
      Remove rootless include paths
      Remove windowswmproto from meson.build
  2. 30 Apr, 2019 9 commits
  3. 29 Apr, 2019 1 commit
  4. 28 Apr, 2019 1 commit
  5. 23 Apr, 2019 1 commit
  6. 20 Apr, 2019 1 commit
  7. 18 Apr, 2019 5 commits
  8. 17 Apr, 2019 8 commits
    • Alex Goins's avatar
      xsync: Add resource inside of SyncCreate, export SyncCreate · 7f962c70
      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>
      Reviewed-by: James Jones's avatarJames Jones <jajones@nvidia.com>
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
    • Emma Anholt's avatar
      glamor: Introduce a central place for our pixmap format/type handling. · 8702c938
      Emma Anholt authored
      We had various helper functions trying to come up with the
      internalformat/format/type/render formats for pixmaps, and it's much
      nicer to just detect what those should be once at startup.  This gives
      us a chance to do the right thing for GLES.
      It also, notably, fixes our format/type for depth 15 and 16 setup for
      desktop GL, so that we actually allocate 16bpp (GL_RGB/565) on most
      drivers instead of 32bpp (GL_RGB/UBYTE).
      GLES still has regressions over desktop (2 regressions in llvmpipe
      XTS, many in rendercheck), but I think this is a good baseline.
      Signed-off-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
    • Emma Anholt's avatar
      glamor: Plumb the pixmap through fbo creation instead of a "format" · c94da112
      Emma Anholt authored
      For GLES, we're going to need a lot more logic for picking the
      iformat/format/type of texture setup, so we'll want the pixmap's depth
      and is_cbcr flag.
      Signed-off-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
    • Emma Anholt's avatar
      glamor: Stop trying to store the pixmap's "format" in glamor_pixmap_fbo. · 34485be2
      Emma Anholt authored
      "format" is a bit of a confused term (internalformat vs GL format),
      and all we really needed was "is this GL_RED?"
      Signed-off-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
    • Emma Anholt's avatar
      glamor: Switch the gl_flavor to a boolean is_gles. · 1b2e224d
      Emma Anholt authored
      There are only 2 flavors we are distinguishing -- GL versions are
      handled separately.
      Signed-off-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
    • Jon Turney's avatar
      Fix missing prototype warning for xf86_find_platform_device_by_devnum() · 2764128e
      Jon Turney authored
      ../hw/kdrive/src/kdrive.c:999:1: warning: no previous prototype for ‘xf86_find_platform_device_by_devnum’ [-Wmissing-prototypes]
      Place the same guards around this stub as are around including the
      hotplug.h header which declares the prototype.
    • Jon Turney's avatar
      Fix maybe-uninitialized warning in xf86NewInputDevice() · ba59427a
      Jon Turney authored
      If SYSTEMD_LOGIND is not defined, systemd_logind_take_fd is defined as a
      macro evaluating to -1 by systemd-logind.h, leaving paused
      ../hw/xfree86/common/xf86Xinput.c: In function ‘xf86NewInputDevice’:
      ../hw/xfree86/common/xf86Xinput.c:919:16: warning: ‘paused’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      ../hw/xfree86/common/xf86Xinput.c:877:10: note: ‘paused’ was declared here
    • Jon Turney's avatar
      Fix old-style definition warning for xf86OSInputThreadInit() · 7c266caf
      Jon Turney authored
      ../hw/xfree86/os-support/stub/stub_init.c: In function ‘xf86OSInputThreadInit’:
      ../hw/xfree86/os-support/stub/stub_init.c:29:1: warning: old-style function definition [-Wold-style-definition]
  9. 12 Apr, 2019 4 commits
    • Adam Jackson's avatar
      dix: Remove WindowRec::backStorage · 69758079
      Adam Jackson authored
      This is only being set, never read.
    • Adam Jackson's avatar
      dix, composite: Optimize setting window backing store state · 0f477cc6
      Adam Jackson authored
      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
      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
      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>
  10. 04 Apr, 2019 1 commit
  11. 02 Apr, 2019 2 commits
  12. 01 Apr, 2019 3 commits
  13. 29 Mar, 2019 2 commits
    • Roman Gilg's avatar
      present: Call present_vblank_scrap in screen mode · 4adda1f6
      Roman Gilg authored
      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>