1. 29 Aug, 2019 1 commit
    • Alex Goins's avatar
      modesetting: Fix ms_covering_crtc() segfault with non-modesetting slave · a31b5277
      Alex Goins authored
      ms_covering_crtc() uses RRFirstOutput() to determine a primary output to fall
      back to if a drawable is overlapping a slave output.
      If the primary output is a slave output, RRFirstOutput() will return a slave
      output even if passed a master ScreenPtr. ms_covering_crtc() dereferences the
      output's devPrivate, which is invalid for non-modesetting outputs, and can
      Changing RRFirstOutput() could have unintended side effects for other callers,
      so this change replaces the call to RRFirstOutput() with ms_first_output().
      ms_first_output() ignores the primary output if it doesn't match the given
      ScreenPtr, choosing the first connected output instead.
      Signed-off-by: Alex Goins's avatarAlex Goins <agoins@nvidia.com>
  2. 27 Aug, 2019 4 commits
  3. 26 Aug, 2019 1 commit
    • Adam Jackson's avatar
      glx: Disable GLX_EXT_import_context if !enableIndirectGLX · f8c85961
      Adam Jackson authored
      GLX_EXT_import_context allows multiple clients to share the same
      indirect context. If you can't create an indirect context, you're
      certainly not going to be able to share one. Hide the extension from the
      server string if we've disabled indirect contexts.
      This turns piglit's tests from fail to skip when indirect contexts are
      disabled. Since GLX_EXT_import_context has been supported in
      xfree86-derived servers since day 1 (it was included in the initial GLX
      code drop from SGI), this is now also a hint to the client that indirect
      contexts are unlikely to work at all.
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <michel@daenzer.net>
  4. 24 Aug, 2019 1 commit
    • Christopher Chavez's avatar
      XQuartz: translate additional mouse buttons · 4f27d1e0
      Christopher Chavez authored
      Old behavior was to translate the middle mouse button, as well as
      every other button that isn't the left or right mouse button,
      to act as the middle mouse button (2).
      New behavior is to translate only the middle mouse button to 2,
      and translate higher-numbered buttons to 8 and higher.
      This allows additional mouse buttons to behave under XQuartz
      more like they do by default under X11 on other platforms
      (e.g. Linux and BSD distributions).
      Signed-off-by: Christopher Chavez's avatarChristopher Chavez <chrischavez@gmx.us>
  5. 23 Aug, 2019 1 commit
    • Adam Jackson's avatar
      render: Break PICT_a4 · 436fd7e8
      Adam Jackson authored and Adam Jackson's avatar Adam Jackson committed
      The Render protocol requires this format, but it is wrong to do so. We
      are not aware of any hardware with a real 4bpp implementation of this
      format. Some GL hardware may have GL_LUMINANCE4_ALPHA4_EXT, and may also
      be able to wire L to 1, but that would win you none of memory, quality,
      or (likely) performance over A8. Any attempt to use this format is
      therefore likely a (painful) software fallback.
      Pleasantly (and given the above, unsurprisingly) it seems to be unused
      in the wild. None of the major toolkits will try to use it, and
      rendercheck does not in fact validate that all of the "standard" picture
      formats exist.
      Drop the explicit A4 setup from picture format initialization. Note that
      the DDXes are not changed and still expose a depth-4 pixmap format, but
      we only add picture formats for True/DirectColor-credible depths (i.e.
      depth >= 15).
      Implements: xorg/proto/xorgproto!1
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
  6. 22 Aug, 2019 1 commit
  7. 21 Aug, 2019 1 commit
    • Adam Jackson's avatar
      miext/sync: Fix needless ABI change · 194ba387
      Adam Jackson authored
      The initialized field was added in:
          commit 82f01ad7
          Author: Alex Goins <agoins@nvidia.com>
          Date:   Wed Apr 10 13:48:02 2019 -0500
              xsync: Add resource inside of SyncCreate, export SyncCreate
      But it added this field not at the end of SyncObject. It may not have
      been _usefully_ possible to create those from another extension prior to
      that commit, but that's still an ABI-incompatible change.
  8. 20 Aug, 2019 1 commit
    • Adam Jackson's avatar
      glx: Fix previous context validation in xorgGlxMakeCurrent · 95dcc81c
      Adam Jackson authored and Adam Jackson's avatar Adam Jackson committed
      vnd has already verified that the context tag is valid before this gets
      called, and we only set the context tag private data to non-null for
      indirect clients. Mesa happens to be buggy and doesn't send MakeCurrent
      requests nearly as much as it should for direct contexts, but if you fix
      that, then unbinding a direct context would fail here with
      Sadly Mesa will still need to carry a workaround here for broken
      servers, but we should still fix the server.
  9. 15 Aug, 2019 6 commits
    • Olivier Fourdan's avatar
      meson/xwayland: No libdrm nor epoxy without glamor · aed62f8f
      Olivier Fourdan authored and Adam Jackson's avatar Adam Jackson committed
      When building Xwayland with neither DRI nor GLamor support enabled with
      the Meson build system, the resulting binary would still link against
      libdrm and epoxy even though those are not used/needed.
      Make sure we require and link against libdrm and epoxy only if needed.
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
    • Olivier Fourdan's avatar
      meson: Build miext/sync for Xwayland · e8a85ba8
      Olivier Fourdan authored and Adam Jackson's avatar Adam Jackson committed
      When using the Meson build system, miext/sync would be build only for
      As a result, when building with Meson without DRI3 enabled, Xwayland
      would fail to link because `miSyncShmScreenInit()` is nowhere to be
      Make sure to build miext/sync for either DRI3 or Xwayland.
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
    • Olivier Fourdan's avatar
      meson: Move requirements in a single place · c0bbc29a
      Olivier Fourdan authored and Adam Jackson's avatar Adam Jackson committed
      Some modules are required in multiple places in the meson file.
      Move the actual requirements to the top of the file as a variable so
      that updating a version does not require changing the actual value in
      multiple places.
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
    • Olivier Fourdan's avatar
      configure/xwayland: No libdrm nor epoxy without glamor · bf758660
      Olivier Fourdan authored and Adam Jackson's avatar Adam Jackson committed
      When building Xwayland without neither DRI nor GLamor support enabled
      with the autotools build system, the resulting binary would still link
      against libdrm and epoxy even though those are not used/needed.
      Make sure we require and link against libdrm and epoxy only if needed.
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
    • Adam Jackson's avatar
      composite: Be more paranoid in compDestroyDamage · 5096fcd4
      Adam Jackson authored and Adam Jackson's avatar Adam Jackson committed
      Consider these two facts:
      - You can't rely on resource deletion order
      - damageDestroyWindow automatically destroys any damage listener
        connected to the doomed window
      Now consider a redirected window being destroyed. If the damage
      associated with the redirection is destroyed before the window, then
      when compFreeClientWindow tries to unredirect the window, the call to
      compSetParentPixmap may see that cw->damageRegistered is still true, and
      call DamageUnregister(NULL) (because compDestroyDamage already zeroed
      out cw->damage), and you get a backtrace that looks like:
          #6  <signal handler called>
          #7  DamageUnregister (pDamage=0x0) at damage.c:1773   <-----------------
          #8  0x000000000051f767 in compSetParentPixmap (pWin=pWin@entry=0x28489c0) at compalloc.c:646
          #9  0x000000000051fa01 in compFreeClientWindow (pWin=0x28489c0, id=<optimized out>) at compalloc.c:291
          #10 0x000000000051a499 in FreeCompositeClientWindow (value=<optimized out>, ccwid=<optimized out>) at compext.c:74
          #11 0x0000000000597932 in doFreeResource (res=0x28494c0, skip=0) at resource.c:880
          #12 0x000000000059850e in FreeResource (id=857, skipDeleteFuncType=skipDeleteFuncType@entry=0) at resource.c:910
          #13 0x000000000051ee01 in compUnredirectWindow (pClient=0x1f6b4e0, pWin=pWin@entry=0x28489c0, update=update@entry=0) at compalloc.c:336
          #14 0x000000000051b723 in compCheckBackingStore (pWin=0x28489c0) at compinit.c:131
          #15 compChangeWindowAttributes (pWin=0x28489c0, mask=<optimized out>) at compinit.c:152
          #16 0x000000000051d1f9 in compDestroyWindow (pWin=0x28489c0) at compwindow.c:664
          #17 0x00000000004d85be in damageDestroyWindow (pWindow=0x28489c0) at damage.c:1570
          #18 0x00000000004896f0 in DbeDestroyWindow (pWin=0x28489c0) at dbe.c:1326
          #19 0x00000000004d229e in present_destroy_window (window=0x28489c0) at present_screen.c:163
          #20 0x000000000059c4e4 in FreeWindowResources (pWin=pWin@entry=0x28489c0) at window.c:1032
          #21 0x000000000059f2c6 in DeleteWindow (value=0x28489c0, wid=<optimized out>) at window.c:1101
          #22 0x0000000000597932 in doFreeResource (res=0x2843bd0, skip=skip@entry=0) at resource.c:880
          #23 0x0000000000598b0c in FreeClientResources (client=client@entry=0x2848560) at resource.c:1146
          #24 0x0000000000572e2f in CloseDownClient (client=0x2848560) at dispatch.c:3473
      Fix this by zeroing out more of the CompWindowPtr when the damage is
      destroyed, so that any further calls into composite will avoid touching
    • Adam Jackson's avatar
      global: Remove BUILD_DATE and BUILD_TIME · 3c78d637
      Adam Jackson authored and Adam Jackson's avatar Adam Jackson committed
      All this does is make reproducible builds impossible.
  10. 10 Aug, 2019 1 commit
    • Matt Turner's avatar
      dix: Assert noPanoramiXExtension is false in PanoramiX code · 61aa40ae
      Matt Turner authored
      When compiling with link time optimization, GCC thinks it's discovered
      undefined behavior:
      events.c: In function 'XineramaConfineCursorToWindow':
      events.c:609:13: warning: iteration 2147483647 invokes undefined behavior [-Waggressive-loop-optimizations]
      events.c:609:11: note: within this loop
      events.c:605:49: warning: array subscript -1 is below array bounds of 'struct _Window *[16]' [-Warray-bounds]
      events.c:606:31: warning: array subscript -1 is below array bounds of 'struct _Screen *[16]' [-Warray-bounds]
      events.c:610:39: warning: array subscript -2 is below array bounds of 'struct _Screen *[16]' [-Warray-bounds]
      events.c:617:38: warning: array subscript -2 is below array bounds of 'struct _Window *[16]' [-Warray-bounds]
      events.c:619:35: warning: array subscript -2 is below array bounds of 'struct _Screen *[16]' [-Warray-bounds]
      This results from
          i = PanoramiXNumScreens - 1;
          RegionCopy(&pSprite->Reg1, &pSprite->windows[i]->borderSize);
          off_x = screenInfo.screens[i]->x;
          off_y = screenInfo.screens[i]->y;
      where GCC believes that PanoramiXNumScreens might be 0. Unfortunately
      GCC is just smart enough to be an annoyance because this case is not
      actually possible: XineramaConfineCursorToWindow() is only called when
      noPanoramiXExtension is false, and if noPanoramiXExtension is false then
      PanoramiXNumScreens must be >1 (see PanoramiXExtensionInit()).
      So, add an assert(!noPanoramiXExtension), which to my surprise provides
      GCC with information even in release builds and lets GCC understand that
      the code is not doing anything that is undefined behavior.
      I chose this solution instead of the proposed assert(i >= 0) because the
      same pattern occurs in CheckVirtualMotion() but is inside an
      'if (!noPanoramiXExtension)' and does not generate any warnings.
      Fixes: xorg/xserver#590
      Signed-off-by: Matt Turner's avatarMatt Turner <mattst88@gmail.com>
  11. 09 Aug, 2019 3 commits
  12. 07 Aug, 2019 1 commit
    • Dave Airlie's avatar
      xf86: autobind GPUs to the screen · 078277e4
      Dave Airlie authored
      This is a modified version of a patch we've been carry-ing in Fedora and
      RHEL for years now. This patch automatically adds secondary GPUs to the
      master as output sink / offload source making e.g. the use of
      slave-outputs just work, with requiring the user to manually run
      "xrandr --setprovideroutputsource" before he can hookup an external
      monitor to his hybrid graphics laptop.
      There is one problem with this patch, which is why it was not upstreamed
      before. What to do when a secondary GPU gets detected really is a policy
      decission (e.g. one may want to autobind PCI GPUs but not USB ones) and
      as such should be under control of the Desktop Environment.
      Unconditionally adding autobinding support to the xserver will result
      in races between the DE dealing with the hotplug of a secondary GPU
      and the server itself dealing with it.
      However we've waited for years for any Desktop Environments to actually
      start doing some sort of autoconfiguration of secondary GPUs and there
      is still not a single DE dealing with this, so I believe that it is
      time to upstream this now.
      To avoid potential future problems if any DEs get support for doing
      secondary GPU configuration themselves, the new autobind functionality
      is made optional. Since no DEs currently support doing this themselves it
      is enabled by default. When DEs grow support for doing this themselves
      they can disable the servers autobinding through the servers cmdline or a
      xorg.conf snippet.
      Signed-off-by: Dave Airlie's avatarDave Airlie <airlied@gmail.com>
      [hdegoede@redhat.com: Make configurable, fix with nvidia, submit upstream]
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Emil Velikov's avatarEmil Velikov <emil.velikov@collabora.com>
      Changes in v2:
      -Make the default enabled instead of installing a xorg.conf
       snippet which enables it unconditionally
      Changes in v3:
      -Handle GPUScreen autoconfig in randr/rrprovider.c, looking at
       rrScrPriv->provider, rather then in hw/xfree86/modes/xf86Crtc.c
       looking at xf86CrtcConfig->provider. This fixes the autoconfig not
       working with the nvidia binary driver
  13. 06 Aug, 2019 5 commits
  14. 05 Aug, 2019 1 commit
    • Ross Burton's avatar
      sdksyms.sh: don't embed the build path · 6f41bf31
      Ross Burton authored and Adam Jackson's avatar Adam Jackson committed
      This script generates a header that has a comment containing the build path for
      no real reason.  As this source can end up deployed on targets in debug packages
      this means there is both potentially sensitive information leakage about the
      build environment, and a source of change for reproducible builds.
  15. 04 Aug, 2019 1 commit
  16. 31 Jul, 2019 2 commits
    • Olivier Fourdan's avatar
      xwayland: Fix build warning without glamor · f107bde1
      Olivier Fourdan authored and Adam Jackson's avatar Adam Jackson committed
      Building Xwayland without glamor support would raise a warning at build
        xwayland.c: In function ‘xwl_screen_init’:
        xwayland.c:980:10: warning: unused variable ‘use_eglstreams’
          980 |     Bool use_eglstreams = FALSE;
              |          ^~~~~~~~~~~~~~
      When building without glamor support, we cannot have EGL Streams support
      either, the two being related. So we do not need to declare the variable
      `use_eglstreams` if glamor is not enabled.
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.com>
    • Olivier Fourdan's avatar
      xwayland: Fix build without glamor · 8587bbd8
      Olivier Fourdan authored
      When building Xwayland without glamor support enabled using automake,
      the build would fail at link time trying to find `glamor_block_handler`:
        /usr/bin/ld: xwayland-glx.o: in function `egl_drawable_wait_x':
        hw/xwayland/xwayland-glx.c:102: undefined reference to
      Make sure we don't try to build `xwayland-glx.c` without glamor in the
      Xwayland Makefile.
      Note: Meson build is fine because it's already build only with glamor
      Fixes: commit 84692415
       - "xwayland: Add EGL-backed GLX provider"
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
  17. 23 Jul, 2019 4 commits
  18. 22 Jul, 2019 1 commit
  19. 21 Jul, 2019 4 commits