1. 12 Jul, 2020 1 commit
  2. 14 Apr, 2020 1 commit
    • Niclas Zeising's avatar
      Fix return value check of drmIoctl() · 38453924
      Niclas Zeising authored
      When the drmModeSetCursor2() call was replaced with bare drmIoctl() call in
      92df7097, a bug was introduced.  With the use of drmModeSetCursor2(),
      the return value from drmIoctl() (which calls ioctl()) were mangled, if
      they were negative, they were replaced by -errno by a wrapper function
      in xf86drMode.c in libdrm.  After replacing drmModeSetCursor2() with the
      call to drmIoctl(), this mangling no longer happens, and we need to
      explicitly check if the call to drmIoctl() fails, which is indicated by
      returning -1, and then why it failed, by checking errno.
      If the error indicated by errno is EINVAL, then we can't use the
      DRM_IOCTL_MODE_CURSOR2 ioctl(), and need to fall back to the
      DRM_IOCTL_MODE_CURSOR ioctl().
      This bug can manifest itself by an invisible hw cursor on systems where the
      DRM_IOCTL_MODE_CURSOR2 is not implemented by the graphics driver.
      Credit also to Alexey Dokuchaev for help with developing the fix and
      This fixes #190Signed-off-by: Niclas Zeising's avatarNiclas Zeising <zeising@daemonic.se>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
  3. 10 Feb, 2020 2 commits
    • Alexey Sheplyakov's avatar
      Don't crash X server if GPU acceleration is not available · c0eb5dbd
      Alexey Sheplyakov authored
      Commit d1d8e3c8 causes X server
      to fail on startup when GPU acceleration is not working (or is
      disabled). The reason is that `radeon_get_pixmap_bo` function
      gets called too early (before EXA has been initialized) and
      fails with an assert:
       #0  __GI_raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:50
       #1  0x76ab1c6c in __GI_abort () at abort.c:79
       #2  0x76ac0b64 in __assert_fail_base (fmt=0x76bfbce4 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7658c80c "key->initialized", file=<optimized out>, line=121,
           function=0x7658d040 <__PRETTY_FUNCTION__.10607> "dixGetPrivateAddr") at assert.c:92
       #3  0x76ac0c0c in __GI___assert_fail (assertion=0x7658c80c "key->initialized", file=0x7658c9d0 "../include/privates.h", line=121,
           function=0x7658d040 <__PRETTY_FUNCTION__.10607> "dixGetPrivateAddr") at assert.c:101
       #4  0x76579e6c in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, privates=<optimized out>) at ../include/privates.h:121
       #5  0x7657a954 in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, privates=<optimized out>) at exa.c:70
       #6  dixGetPrivate (key=<optimized out>, privates=<optimized out>) at ../include/privates.h:136
       #7  exaGetPixmapDriverPrivate (pPix=<optimized out>) at exa.c:68
       #8  0x7623d460 in radeon_get_pixmap_bo (pPix=0x71c1b8) at radeon.h:804
       #9  radeon_get_pixmap_handle (pixmap=0x71c1b8, handle=0x7fa22328) at radeon_bo_helper.c:357
       #10 0x76244458 in radeon_pixmap_get_fb (pix=0x71c1b8) at radeon.h:886
       #11 drmmode_set_mode_major (crtc=0x691860, mode=0x69191c, rotation=<optimized out>, x=<optimized out>, y=<optimized out>) at drmmode_display.c:918
       #12 0x762467e8 in drmmode_set_desired_modes (pScrn=0x67c678, drmmode=<optimized out>, set_hw=1) at drmmode_display.c:3128
       #13 0x0047bfa4 in MapWindow (client=0x669ec8, pWin=0x7206c0) at window.c:2722
       #14 MapWindow (pWin=0x7206c0, client=0x669ec8) at window.c:2665
       #15 0x00449650 in dix_main (argc=3, argv=0x7fa22604, envp=<optimized out>) at main.c:247
       #16 0x76ab2198 in __libc_start_main (main=0x42db10 <main>, argc=3, argv=0x7fa22604, init=<optimized out>, fini=0x606434 <__libc_csu_fini>, rtld_fini=0x77229930 <_dl_fini>,
           stack_end=0x7fa225e0) at libc-start.c:308
       #17 0x0042db80 in __start () at ../sysdeps/mips/start.S:110
      Don't call `exaGetPixmapDriverPrivate` if the acceleration (EXA) is not
      enabled [yet] to avoid the problem.
      Closes: #188
      Closes: https://bugzilla.altlinux.org/show_bug.cgi?id=37539
    • Michel Dänzer's avatar
      Handle NULL fb_ptr in pixmap_get_fb · 4d84cf43
      Michel Dänzer authored
      This can happen when HW acceleration is disabled.
      Fixes #188
  4. 05 Feb, 2020 1 commit
  5. 15 Oct, 2019 1 commit
  6. 25 Sep, 2019 1 commit
  7. 20 Sep, 2019 1 commit
  8. 18 Jul, 2019 1 commit
  9. 25 Jun, 2019 1 commit
  10. 14 Jun, 2019 3 commits
  11. 09 May, 2019 1 commit
  12. 24 Apr, 2019 1 commit
  13. 19 Mar, 2019 1 commit
  14. 15 Mar, 2019 1 commit
    • Dave Airlie's avatar
      modesetting: add tile property support · 4407c78b
      Dave Airlie authored
      This adds tiling support to the driver, it retrieves the tile info from
      the kernel and translates it into the server format and exposes the
      (Ported from xserver commits 8fb8bbb3062f1a06621ab7030a9e89d5e8367b35
       and 6abdb54a11dac4e8854ff94ecdcb90a14321ab31)
      (Ported from amdgpu commit 6ee857726166f495abcd68e4ff60e3a09593d079)
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
  15. 14 Mar, 2019 1 commit
  16. 08 Mar, 2019 1 commit
  17. 06 Mar, 2019 1 commit
  18. 04 Mar, 2019 1 commit
  19. 01 Mar, 2019 1 commit
  20. 11 Feb, 2019 1 commit
    • Michel Dänzer's avatar
      Keep waiting for a pending flip if drm_handle_event returns 0 · 15697ee2
      Michel Dänzer authored
      drm_wait_pending_flip stopped waiting if drm_handle_event returned 0,
      but that might have processed only some unrelated DRM events. As long as
      the flip is pending, we have to keep waiting for its completion event.
      Noticed while working on the previous fix.
      (Ported from amdgpu commit 9045fb310f88780e250e60b80431ca153330e61b)
  21. 28 Jan, 2019 6 commits
    • Michel Dänzer's avatar
      Call drmHandleEvent again if it was interrupted by a signal · 227123de
      Michel Dänzer authored
      drmHandleEvent can be interrupted by a signal in read(), in which case
      it doesn't process any events but returns -1, which
      drm_handle_event propagated to its callers. This could cause the
      following failure cascade:
      1. drm_wait_pending_flip stopped waiting for a pending flip.
      2. Its caller cleared drmmode_crtc->flip_pending before the flip
      3. Another flip was attempted but got an unexpected EBUSY error because
         the previous flip was still pending.
      4. TearFree was disabled due to the error.
      The solution is to call drmHandleEvent if it was interrupted by a
      signal. We can do that in drm_handle_event, because when that is called,
      either it is known that there are events ready to be processed, or the
      caller has to wait for events to arrive anyway.
      Bugzilla: https://bugs.freedesktop.org/109364
      (Ported from amdgpu commit 3ff2cc225f6bc08364ee007fa54e9d0150adaf11)
    • Michel Dänzer's avatar
      Only update drmmode_crtc->flip_pending after actually submitting a flip · 1bfdccf7
      Michel Dänzer authored
      And only clear it if it matches the framebuffer of the completed flip
      being processed.
       (WW) RADEON(0): flip queue failed: Device or resource busy
       (WW) RADEON(0): Page flip failed: Device or resource busy
       (EE) RADEON(0): present flip failed
      due to clobbering drmmode_crtc->flip_pending.
      Reproducer: Enable TearFree, run warzone2100 fullscreen, toggle
      Vertical sync on/off under Video Options. Discovered while investigating
      https://bugs.freedesktop.org/109364 .
      (Ported from amdgpu commit e72a02ba1d35743fefd939458b9d8cddce86e7f5)
    • Michel Dänzer's avatar
      Don't allow TearFree scanout flips to complete in the same vblank period · dcd35272
      Michel Dänzer authored
      We were using a relative target of 0, meaning "complete the flip ASAP".
      This could result in the flip sometimes, but not always completing in
      the same vertical blank period where the corresponding drawing occurred,
      potentially causing judder artifacts with applications updating their
      window contents synchronized to the display refresh. A good way to test
      this is the vsynctester.com site in a windowed browser, where the judder
      results in the large "VSYNC" text intermittently appearing red or cyan
      instead of the expected gray.
      To avoid this, use a relative target MSC of 1, meaning that if a
      vertical blank period is in progress, the flip will only complete in the
      next one.
      Reported by Julian Tempel and Brandon Wright in
      https://bugs.freedesktop.org/106175 .
      (Ported from amdgpu commit a1b479c7d0066c481af920f297d6af9009dda11e)
    • Michel Dänzer's avatar
      glamor: Avoid glamor_create_pixmap for pixmaps backing windows · 27470308
      Michel Dänzer authored
      If the compositing manager uses direct rendering (as is usually the case
      these days), the storage of a pixmap allocated by glamor_create_pixmap
      needs to be reallocated for sharing it with the compositing manager.
      Instead, allocate pixmap storage which can be shared directly.
      (Ported from amdgpu commit bf326f2ea19daa6c8da23d6788ff301ae70b8e69)
    • Michel Dänzer's avatar
      dri2: Flush in dri2_create_buffer2 after calling glamor_set_pixmap_bo · 6d1dfe25
      Michel Dänzer authored
      To make sure the client can't use the shared pixmap storage for direct
      rendering first, which could produce garbage.
      Bugzilla: https://bugs.freedesktop.org/109235
      (Ported from amdgpu commit ebd32b1c07208f8dbe853e089f5e4b7c6a7a658a)
    • Michel Dänzer's avatar
      dri3: Flush if necessary in dri3_fd_from_pixmap · 77d7abf4
      Michel Dänzer authored
      To make sure the client can't use the shared pixmap storage for direct
      rendering first, which could produce garbage.
      Bugzilla: https://bugs.freedesktop.org/109235
      (Ported from amdgpu commit d168532ee739f7e33a2798051e64ba445dd3859f)
  22. 09 Jan, 2019 2 commits
  23. 28 Dec, 2018 9 commits