1. 29 Apr, 2021 1 commit
    • Erik Kurzinger's avatar
      xwayland-eglstream: fix X11 rendering to flipping GL / VK window · 07f26e16
      Erik Kurzinger authored
      If a window is being used for direct rendering with OpenGL or Vulkan, and is
      using the flipping path for presentation, it's pixmap will be set to a dma-buf
      backed pixmap created by the client-side GL driver. However, this means that
      xwl_glamor_eglstream_post_damage won't work since it requires that the pixmap
      has an EGLSurface that it can render to, which dma-buf backed pixmaps do not.
      In this case, though, xwl_glamor_eglstream_post_damage is not necessary since
      glamor will have rendered directly to the pixmap, so we can simply pass it
      directly to the compositor. There's no need for the intermediate copy we
      normally do in that function.
      Therefore, this change adds an early-return case to post_damage for dma-buf
      backed pixmaps, and removes the corresponding asserts from that function and
      Signed-off-by: Erik Kurzinger's avatarErik Kurzinger <ekurzinger@nvidia.com>
      Acked-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
  2. 24 Apr, 2021 1 commit
  3. 16 Apr, 2021 6 commits
  4. 09 Apr, 2021 4 commits
  5. 07 Apr, 2021 2 commits
  6. 06 Apr, 2021 1 commit
  7. 05 Apr, 2021 1 commit
    • Aaron Plattner's avatar
      modesetting: Defer crtc gamma size upgrade to drmmode_setup_colormap · b75d0cca
      Aaron Plattner authored
      Rather than trying to create a gamma ramp array of the appropriate size in
      drmmode_crtc_init when the GAMMA_LUT property should be used, just flag the crtc
      as wanting to use the GAMMA_LUT property and then replace the gamma ramp later,
      right before calling xf86HandleColormaps. This avoids a problem during initial
      startup where xf86RandR12CreateObjects12 hard-codes a gamma ramp size of 256,
      causing xf86RandR12CrtcSetGamma to read past the end of the DIX layer's RandR
      gamma ramp array:
              crtc->gamma_size = 1024
                    randr_crtc->gammaSize = 0
                xf86RandR12InitGamma(pScrn, 256)
                    randr_crtc->gammaSize = 256
                        // crtc->gamma_size is 1024 here, while randr_crtc->gammaRed
                        // is a 256-element array.
                        memcpy(crtc->gamma_red, randr_crtc->gammaRed, crtc->gamma_size * sizeof(crtc->gamma_red[0]));
                  randr_crtc->gammaSize = 1024
      Fixes: 245b9db0 - modesetting: Use GAMMA_LUT when available
      Closes: xorg/xserver#1126
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: Robert Morell's avatarRobert Morell <rmorell@nvidia.com>
  8. 26 Mar, 2021 3 commits
  9. 24 Mar, 2021 1 commit
  10. 09 Mar, 2021 1 commit
  11. 06 Mar, 2021 2 commits
  12. 05 Mar, 2021 2 commits
  13. 03 Mar, 2021 2 commits
    • Jacob Cherry's avatar
      xfree86: Fix autoconfig secondary GPU devices · a5367fac
      Jacob Cherry authored and Aaron Plattner's avatar Aaron Plattner committed
      The code path added by commit 69e4b8e6
       (xfree86: attempt to autoconfig
      gpu slave devices (v3)) assumes that it will only be run if the primary
      device on the screen is the first device in xf86configptr->conf_device_lst.
      While this is true most of the time, there are two specific cases where
      this assumption fails.
      First, if the first device in conf_device_lst is assigned to a different
      seat than the running X server, it will be skipped by the previous
      FIND_SUITABLE macro usage. Second, if the primary device was explicitly
      assigned to the screen but auto_gpu_device is still set and no secondary
      devices were explicitly listed, that device may not be the first device
      in conf_device_lst.
      When the first device in conf_device_lst is not the primary device
      assigned to the screen, two problems emerge. First, the first device in
      conf_device_lst will never be assigned to the screen as a secondary
      device. Second, the primary device is additionally assigned to the
      screen as a secondary device. The combination of these problems causes
      certain otherwise valid configurations to be invalid. For example, if a
      primary device is assigned to a screen and a secondary device is listed
      in the config but not explicitly assigned to the screen, then one order
      of the device sections results in a usable PRIME or Reverse PRIME setup
      and the other order does not.
      This commit removes the assumption that the primary device is the first
      device in conf_device_lst by starting the loop from the start of
      conf_device_lst and skipping the primary device when it is encountered.
      Signed-off-by: Jacob Cherry's avatarJacob Cherry <jcherry@nvidia.com>
    • Olivier Fourdan's avatar
      xwayland: Delay cursor visibility update · 97ed0048
      Olivier Fourdan authored
      Xwayland won't emulate XWarpPointer requests if the cursor is visible,
      this is to avoid having the cursor jumping on screen and preventing
      random X11 clients from controlling the pointer in Wayland, while
      allowing games which use that mechanism with a hidden cursor to work in
      There are, however, games which tend to do it in the wrong order, i.e.
      show the cursor before moving the pointer, and because Xwayland will not
      allow an X11 client to move the pointer while the cursor is visible, the
      requests will fail.
      Add a workaround for such X11 clients, when the cursor is being shown,
      keep it invisible until the cursor is actually moved. This way, X11
      clients which show their cursor just before moving it would still have a
      chance to succeed.
      v2: Add a timeout to show the cursor for well behaved clients.
      v3: Some cleanup (Michel)
      v4: Do not cancel cursor delay when updating the cursor to avoid
          delaying cursor visibility indefinitely if the client keeps
          settings different cursors (Michel)
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Tested-by: Jaap Buurman jaapbuurman@gmail.com
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      Closes: xorg/xserver#734
  14. 22 Feb, 2021 3 commits
  15. 21 Feb, 2021 2 commits
    • Jeremy Huddleston Sequoia's avatar
    • Jeremy Huddleston Sequoia's avatar
      xquartz: Allocate each fbconfig separately · 487286d4
      Jeremy Huddleston Sequoia authored
      A change during the 1.20 development cycle resulted in fbconfigs being walked
      and deallocated individually during __glXScreenDestroy.  This change
      now avoids a use-after-free caused by that change.
      ==50859==ERROR: AddressSanitizer: heap-use-after-free on address 0x00010d3819c8 at pc 0x0001009d4230 bp 0x00016feca7a0 sp 0x00016feca798
      READ of size 8 at 0x00010d3819c8 thread T5
          #0 0x1009d422c in __glXScreenDestroy glxscreens.c:448
          #1 0x10091cc98 in __glXAquaScreenDestroy indirect.c:510
          #2 0x1009d2734 in glxCloseScreen glxscreens.c:169
          #3 0x100740a24 in dix_main main.c:325
          #4 0x10023ed50 in server_thread quartzStartup.c:65
          #5 0x199ae7fd0 in _pthread_start+0x13c (libsystem_pthread.dylib:arm64e+0x6fd0)
          #6 0x199ae2d38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d38)
      0x00010d3819c8 is located 200 bytes inside of 12800-byte region [0x00010d381900,0x00010d384b00)
      freed by thread T5 here:
          #0 0x101477ba8 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3fba8)
          #1 0x1009d4240 in __glXScreenDestroy glxscreens.c:449
          #2 0x10091cc98 in __glXAquaScreenDestroy indirect.c:510
          #3 0x1009d2734 in glxCloseScreen glxscreens.c:169
          #4 0x100740a24 in dix_main main.c:325
          #5 0x10023ed50 in server_thread quartzStartup.c:65
          #6 0x199ae7fd0 in _pthread_start+0x13c (libsystem_pthread.dylib:arm64e+0x6fd0)
          #7 0x199ae2d38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d38)
      previously allocated by thread T5 here:
          #0 0x101477e38 in wrap_calloc+0x9c (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3fe38)
          #1 0x100925a40 in __glXAquaCreateVisualConfigs visualConfigs.c:116
          #2 0x10091cb24 in __glXAquaScreenProbe+0x224 (X11.bin:arm64+0x100730b24)
          #3 0x1009cd840 in xorgGlxServerInit glxext.c:528
          #4 0x10074539c in _CallCallbacks dixutils.c:743
          #5 0x100932a70 in CallCallbacks callback.h:83
          #6 0x100932478 in GlxExtensionInit vndext.c:244
          #7 0x10020a364 in InitExtensions miinitext.c:267
          #8 0x10073fe7c in dix_main main.c:197
          #9 0x10023ed50 in server_thread quartzStartup.c:65
          #10 0x199ae7fd0 in _pthread_start+0x13c (libsystem_pthread.dylib:arm64e+0x6fd0)
          #11 0x199ae2d38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d38)
      Regressed-in: 4b0a3cba
      CC: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
      Signed-off-by: Jeremy Huddleston Sequoia's avatarJeremy Huddleston Sequoia <jeremyhu@apple.com>
  16. 20 Feb, 2021 1 commit
  17. 19 Feb, 2021 7 commits