commit 0c01893774031d8429f0a138048fda7957f15706
Author: Matt Turner <mattst88@gmail.com>
Date:   Tue Apr 25 14:40:08 2023 -0400

    Bump version for 22.0.0 release
    
    Signed-off-by: Matt Turner <mattst88@gmail.com>

commit 7a6a34af026f0bef8080b91baf97a729380bca01
Author: Matthieu Herrb <matthieu.herrb@laas.fr>
Date:   Sun Nov 14 17:38:24 2021 +0100

    Don't set SourceValidate pointer to NULL
    
    inspired from similar code in amdgpu, fixes a crash when xrandr(1)
    is invoqued with X server 21.1.1
    
    Signed-off-by: Matthieu Herrb <matthieu.herrb@laas.fr>

commit 983a779b7a5b2153d995727a0ed3da09732e15d5
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sat Jul 23 18:39:20 2022 -0700

    radeon_glamor_wrappers.c: Convert from ISO-8859-1 to UTF-8
    
    Allows Flawfinder to analyze source instead of erroring out on encoding
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

commit a25ca015e6b46bcf6560abe273cfb529c4bdd287
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sat Jul 23 18:35:08 2022 -0700

    gitlab CI: enable gitlab's builtin static analysis
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

commit 7b940097545ea60e5089ae67f593311f136ae271
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sat Jul 23 18:29:13 2022 -0700

    gitlab CI: enable commit & merge request checks
    
    Uses ci-fairy from freedesktop/ci-templates
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

commit 8fc442d6a67a35b031be7e725a0999a7e0403b4f
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sat Jan 22 09:36:23 2022 -0800

    Fix spelling/wording issues
    
    Found by using:
        codespell --builtin clear,rare,usage,informal,code,names
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

commit 11d549d591c7a6f19d2b39d069e99febbd3113da
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sat Jan 22 09:24:46 2022 -0800

    Build xz tarballs instead of bzip2
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

commit 5eba006e4129e8015b822f9e1d2f1e613e252cda
Author: Michel Dänzer <mdaenzer@redhat.com>
Date:   Tue Feb 2 12:45:54 2021 +0100

    Only include dri.h with older versions of xserver
    
    Not needed anymore with current versions.

commit ecced3b3c6af501c4c90265f8404b6898f3cf037
Author: Michel Dänzer <mdaenzer@redhat.com>
Date:   Fri Mar 26 17:16:32 2021 +0100

    Add GitLab CI pipeline
    
    Based on xf86-video-amdgpu, but applying experience gained in the
    meantime in other projects and taking advantage of new features
    available with current versions of GitLab.

commit 77d9ab03ca20e683be4c40ccc879e201b538f7e5
Author: Michel Dänzer <mdaenzer@redhat.com>
Date:   Fri Mar 26 17:37:53 2021 +0100

    Guard local variable info only used with glamor
    
    Fixes compiler warning with glamor disabled:
    
    radeon_dri2.c: In function 'radeon_dri2_exchange_buffers':
    radeon_dri2.c:732:19: error: unused variable 'info' [-Werror=unused-variable]
         RADEONInfoPtr info = RADEONPTR(xf86ScreenToScrn(screen));
                       ^~~~

commit 3c7c84ed49564907a148ae99b03200e0be350060
Author: Michel Dänzer <mdaenzer@redhat.com>
Date:   Fri Mar 26 17:42:10 2021 +0100

    Guard local variable priv only used with glamor
    
    Fixes compile errors with glamor disabled:
    
    ../../src/radeon_present.c: In function ‘radeon_present_check_flip’:
    ../../src/radeon_present.c:281:21: error: invalid use of undefined type ‘struct radeon_pixmap’
      281 |     if (priv && priv->fb_failed)
          |                     ^~
    ../../src/radeon_present.c:288:19: error: invalid use of undefined type ‘struct radeon_pixmap’
      288 |  if (priv && !priv->fb_failed) {
          |                   ^~
    ../../src/radeon_present.c:292:10: error: invalid use of undefined type ‘struct radeon_pixmap’
      292 |      priv->fb_failed = TRUE;
          |          ^~

commit 8da3e4561ef82bb78c9a17b8cd8bf139b9cfd680
Author: Dave Airlie <airlied@redhat.com>
Date:   Mon Jul 13 09:11:28 2020 +1000

    ati: cleanup terminology to use primary/secondary
    
    The X server changed some API/ABIs here.
    
    Based on amdgpu patch by Michel

commit 3845392426e9798c1fb2a6fc5e97bf5dfd5c443d
Author: Niclas Zeising <zeising@daemonic.se>
Date:   Tue Apr 14 17:01:57 2020 +0200

    Fix return value check of drmIoctl()
    
    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
    testing.
    
    This fixes #190
    
    Signed-off-by: Niclas Zeising <zeising@daemonic.se>
    Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

commit c0eb5dbd9c1db6b6d5b1574bcd8c584170d7ab54
Author: Alexey Sheplyakov <asheplyakov@altlinux.org>
Date:   Wed Nov 27 20:50:58 2019 +0400

    Don't crash X server if GPU acceleration is not available
    
    Commit d1d8e3c8d0a0a0394d395eba171460501745209b 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: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/188
    Closes: https://bugzilla.altlinux.org/show_bug.cgi?id=37539

commit 4d84cf438e7f1bebf0053035ef0292e9fed257d1
Author: Michel Dänzer <mdaenzer@redhat.com>
Date:   Fri Nov 29 16:37:32 2019 +0100

    Handle NULL fb_ptr in pixmap_get_fb
    
    This can happen when HW acceleration is disabled.
    
    Fixes https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/188

commit f223035f4ffcff2a9296d1e907a5193f8e8845a3
Author: Adam Jackson <ajax@redhat.com>
Date:   Tue Feb 4 16:38:06 2020 -0500

    Fix link failure with gcc 10
    
    Without the 'extern' this looks like a definition not just a
    declaration, in every file that includes the header. gcc 10 is stricter
    about this kind of multiple definition.
    
    Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

commit b9bd8097e1d2c088b081f1b81799ea3892406214
Author: Michel Dänzer <mdaenzer@redhat.com>
Date:   Tue Oct 15 17:54:12 2019 +0200

    Bump version for 19.1.0 release

commit 2faaecc69b127248718e759c6c98c84d56dd1b6b
Author: Michel Dänzer <mdaenzer@redhat.com>
Date:   Fri Sep 20 17:24:19 2019 +0200

    Don't unreference FBs of pixmaps from different screens in LeaveVT
    
    FindClientResourcesByType finds pixmaps from all screens, but trying to
    process ones from other screens here makes no sense and likely results
    in a crash or memory corruption.
    
    Fixes: 06a465484101 ("Make all active CRTCs scan out an all-black
                          framebuffer in LeaveVT")

commit 2cbbd8648cdd27db8076565943b932ef81337053
Author: Michel Dänzer <mdaenzer@redhat.com>
Date:   Fri Sep 20 18:47:02 2019 +0200

    Don't set up black scanout buffer if LeaveVT is called from CloseScreen
    
    Avoids a crash described in
    https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/43#note_223718
    
    (Ported from amdgpu commit 5b8bc9fc505c551dcd9b0ed5ab835a49fa4f9fda)
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

commit c7ed12cb2ea76999351d7cb87877224bdc0664f0
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Jul 18 18:14:48 2019 +0200

    Don't disable page flipping completely with SW cursor
    
    Even with SW cursor, page flipping can be used while no X cursor is
    visible.
    
    Occurred to me in the context of xorg/xserver#828.
    (Ported from amdgpu commit 87f41ace4920fd2069794211683659eb25b025a6)

commit 33803c85f761d343aa7300311b8e9489b1a89495
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Tue Jun 25 17:46:23 2019 +0200

    present: Check that we can get a KMS FB for flipping
    
    This can legitimately fail if the pixmap's storage is shared from
    another device, e.g. when using PRIME render offloading.
    
    (Ported from amdgpu commit 7d3fef72e0c871e1677e9e544f4cae5e238b5c52)

commit fee737e82837dc8282a832fc9391ed959c4c3737
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Jun 14 11:23:34 2019 +0200

    Remove dri2_drawable_crtc parameter consider_disabled
    
    All callers were passing TRUE.
    
    (Ported from amdgpu commit ea19a5207054bb159fc7fb6d88e0ceb10c3da010)
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

commit 2a3f2d2089f603c99be54c98d7033155e771ce7b
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Jun 14 11:21:40 2019 +0200

    dri2: Re-use previous CRTC when possible if pick_best_crtc returns NULL
    
    This way, the MSC will continue ticking at the rate of (the last mode
    which was enabled for) that CRTC, instead of the client running
    unthrottled.
    
    (Ported from amdgpu commit 3109f088fdbd89c2ee8078625d4f073852492656)
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

commit d5f5bc5846ef06c3ecf9e5acf1ca357574f06f5a
Author: Flora Cui <flora.cui@amd.com>
Date:   Fri Jun 14 11:20:12 2019 +0200

    dri2: reply to client for WaitMSC request in any case
    
    otherwise client would wait for reply forever and desktop appears hang.
    
    Signed-off-by: Flora Cui <flora.cui@amd.com>
    (Ported from amdgpu commit fb06fb814700a47464abd756e1111dcc76d0d776)
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

commit f758908db4e71406e5d437d32e43aabd38a63504
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu May 9 12:35:37 2019 +0200

    dri3: Always flush glamor before sharing pixmap storage with clients
    
    Even if glamor_gbm_bo_from_pixmap / glamor_fd_from_pixmap themselves
    don't trigger any drawing, there could already be unflushed drawing to
    the pixmap whose storage we share with a client.
    
    (Ported from amdgpu commit 4b17533fcb30842caf0035ba593b7d986520cc85)
    Acked-by: Alex Deucher <alexander.deucher@amd.com>

commit d1d8e3c8d0a0a0394d395eba171460501745209b
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Apr 24 12:25:39 2019 +0200

    Retry get_fb_ptr in get_fb
    
    If get_fb_ptr returns NULL, try again after pixmap_get_handle, it should
    work then.
    
    Fixes spurious Present page flipping failures using "normal" pixmaps
    which aren't shared with direct rendering clients, e.g. with a
    compositor using the RENDER extension.
    
    Bugzilla: https://bugs.freedesktop.org/110417
    (Ported from amdgpu commit bf61e6d7ac1a5754b1026d7f80acf25ef622c491)
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

commit 36703f66c3b06875651606a6280d5dc9d9dad51e
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Tue Mar 19 18:01:02 2019 +0100

    Bump version for 19.0.1 release

commit 4407c78bd86da4460ee07a15a365e07d99e0dd27
Author: Dave Airlie <airlied@redhat.com>
Date:   Thu Mar 14 11:17:32 2019 +0100

    modesetting: add tile property support
    
    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
    property.
    
    (Ported from xserver commits 8fb8bbb3062f1a06621ab7030a9e89d5e8367b35
     and 6abdb54a11dac4e8854ff94ecdcb90a14321ab31)
    (Ported from amdgpu commit 6ee857726166f495abcd68e4ff60e3a09593d079)
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

commit 79bc0e054f37026377d54cac6cd8127d4aa9baca
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Mar 14 11:10:51 2019 +0100

    Use radeon_finish in drmmode_crtc_scanout_update
    
    radeon_glamor_finish only works if we're using glamor, otherwise it'll
    crash.
    
    Fixes: ce7db51020d3 "Cancel pending scanout update in drmmode_crtc_scanout_update"
    Bug: https://bugs.debian.org/924540
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

commit f6cd4a67d7de5d3ff1a6e58a8c83749fc8ffc310
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Mar 8 11:48:10 2019 +0100

    Revert "glamor: Avoid glamor_create_pixmap for pixmaps backing windows"
    
    This reverts commit 274703087f80342f51fa69c935bb9a1cb0c4ae47.
    
    Reports of visual corruption were bisected to this, e.g.
    https://bugs.archlinux.org/task/61941 . I can reproduce this with Turks,
    but not with Bonaire. I assume it's a Mesa/glamor bug, but let's revert
    for now.
    
    Acked-by: Alex Deucher <alexander.deucher@amd.com>

commit 0d132d99e0b750896a78f47d73a8639680495d8c
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Mar 6 17:48:03 2019 +0100

    Bump version for 19.0.0 release

commit c301b8af25d2c2cd49035a4395ebe6c3612df366
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Mar 1 18:28:11 2019 +0100

    dri2: Call drm_queue_handle_deferred in dri2_deferred_event
    
    drm_queue_handler just puts the event on the signalled list; without
    calling drm_queue_handle_deferred, actual processing of the event may be
    delayed indefinitely, e.g. until another event arrives from the kernel.
    
    This could result in DRI2 clients hanging during DPMS off.
    
    Fixes: ba83a866af5a "Add radeon_drm_handle_event wrapper for
                         drmHandleEvent"
    (Ported from amdgpu commit 09be74a3d1dd9604336d9a27f98d132b262dcbaf)
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

commit 705020b6247eaa062edc9c88e6ad52f8c5468051
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Mar 1 18:23:30 2019 +0100

    present: Check that flip and screen pixmap pitches match
    
    If they don't, flipping will result in corrupted display.
    
    Test case:
    
    * Run Xorg at 1920x1080 with no window manager
    * glxgears -geometry 2048x1080
    
    The Present extension code in xserver 1.21 will check for this.
    
    (Ported from amdgpu commit a636f42b496b0604ca00a144690ece61d1a88a27)
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

commit 15697ee242c30b9ea6775624e8282e0171a113a7
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Mon Jan 28 18:27:10 2019 +0100

    Keep waiting for a pending flip if drm_handle_event returns 0
    
    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)

commit 227123de3d862e691131708b7f55260bee17f2b7
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Mon Jan 28 18:24:41 2019 +0100

    Call drmHandleEvent again if it was interrupted by a signal
    
    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
       completed.
    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)

commit 1bfdccf7639ee2f655dc659cafa63830ba28be85
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Mon Jan 28 18:11:10 2019 +0100

    Only update drmmode_crtc->flip_pending after actually submitting a flip
    
    And only clear it if it matches the framebuffer of the completed flip
    being processed.
    
    Fixes
    
     (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)

commit dcd3527299c1f6d6faa401c565fa884f4d8f3287
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Mon Jan 28 18:08:35 2019 +0100

    Don't allow TearFree scanout flips to complete in the same vblank period
    
    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)

commit 274703087f80342f51fa69c935bb9a1cb0c4ae47
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Mon Jan 28 18:06:50 2019 +0100

    glamor: Avoid glamor_create_pixmap for pixmaps backing windows
    
    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)

commit 6d1dfe2523e900517bd1e8743c87d6990a82c800
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Mon Jan 28 18:04:41 2019 +0100

    dri2: Flush in dri2_create_buffer2 after calling glamor_set_pixmap_bo
    
    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)

commit 77d7abf46446522e686c6b6f1e4857458589ef37
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Mon Jan 28 18:00:20 2019 +0100

    dri3: Flush if necessary in dri3_fd_from_pixmap
    
    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)

commit b1c01698f577577e4a88bad0ae08fb5d998e7ebb
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Jan 9 11:26:14 2019 +0100

    Only call drmmode_validate_leases if RandR is enabled
    
    It would crash if RandR is disabled, e.g. because Xinerama is enabled.
    
    Bugzilla: https://bugs.freedesktop.org/109230
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

commit 38db1bbcfc019c92884c7819a6630c70e543f6b2
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Jan 9 11:33:18 2019 +0100

    Only call drmmode_uevent_init if RandR is enabled
    
    There's no point in listening for hotplug events if RandR is disabled,
    as there's no other mechanism for them to be propagated. We were already
    mostly ignoring them in that case.
    
    Inspired by
    https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/commit/1a489142c8e6a4828348cc9afbd0f430d3b1e2d8
    (via https://bugs.freedesktop.org/109230#c11).
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

commit 803f872f7d4b2d80be434bb42ce64dfd295b122c
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Dec 21 18:04:21 2018 +0100

    Use two HW cursor buffers per CRTC
    
    Switch to the other buffer when xf86_config->cursor changes. Avoids
    these issues possible when re-using the same buffer:
    
    * The HW may intermittently display a mix of the old and new cursor
      images.
    * If the hotspot changes, the HW may intermittently display the new
      cursor image at the location corresponding to the old image's hotspot.
    
    Bugzilla: https://bugs.freedesktop.org/108832
    (Ported from amdgpu commit 0d60233d26ec70d4e1faa343b438e33829c6d5e4)

commit 91e557f78ad261e76a1829f54722c2c0781742d2
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Dec 21 18:00:09 2018 +0100

    Update cursor position in drmmode_show_cursor if hotspot changed
    
    The cursor position is updated to be consistent with the new hotspot in
    the same ioctl call.
    
    (Ported from amdgpu commit b04697de5270e8e45744a7025c24df1f454a4cf0)

commit 92df709786830d4e30a106dd49d8e0355c50c8f0
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Dec 21 17:54:36 2018 +0100

    Use drmIoctl in drmmode_show_cursor
    
    This should be functionally equivalent to what drmModeSetCursor(2) do
    behind the scenes, but allows for new tricks in following changes.
    
    (Ported from amdgpu commit b344e1559e936046ef02c777fc4f6bcefa3830bc)

commit e14c3d2f86c7be2b5c3d06a47bf0abe954207d0b
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Dec 21 17:38:51 2018 +0100

    Drop RADEONInfoRec::cursor_bo array
    
    Not needed or even useful for anything.
    
    (Ported from amdgpu commit e95044e45350870fa7e237860e89ade91ac03550)

commit f66254c171f5a3b052a2a9e0339f17dfb5a60dc2
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Dec 21 12:49:27 2018 +0100

    Automatically try re-enabling TearFree after a flip failed
    
    Specifically, after both the page flip and vblank ioctls failed, but
    then the vblank ioctl started working again. This can happen
    intermittently e.g. when hotplugging a DP display. Previously, TearFree
    would stay disabled in that case until a modeset was triggered somehow.
    
    Bugzilla: https://bugs.freedesktop.org/103791
    (Ported from amdgpu commit bcfa6c258fdf41a9928f8a3c78fc528d0fafee25)

commit ce7db51020d32f17e442338bfd305220feb51630
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Dec 21 12:47:18 2018 +0100

    Cancel pending scanout update in drmmode_crtc_scanout_update
    
    drmmode_crtc_scanout_update does the equivalent of a scanout update,
    so no need to do it again. This might also avoid issues if there's a
    pending scanout update at this point.
    
    (Ported from amdgpu commit 4e7a24ac5a64e402146953ec5850d13c05742116)

commit 21d65e5b78c8889e363aee8596cd0b0f942fee46
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Dec 21 12:38:04 2018 +0100

    Perform scanout buffer update immediately if drmmode_wait_vblank fails
    
    Otherwise the damaged screen contents may never be displayed in that
    case.
    
    (Ported from amdgpu commit 500fadb16285146e91f62fce3a0ce1360ca684ba)

commit 64942d2c49f9fa1afcc42c07943d076a40963e51
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Dec 20 19:00:08 2018 +0100

    Move deferred vblank events to separate drm_vblank_deferred list
    
    It was still possible for nested xorg_list_for_each_entry_safe loops
    to occur over the drm_vblank_signalled list, which could mess up that
    list. Moving deferred events to a separate list allows processing the
    drm_vblank_signalled list without xorg_list_for_each_entry_safe.
    
    Bugzilla: https://bugs.freedesktop.org/108600
    (Ported from amdgpu commit 51ba6dddee40c3688d4c7b12eabeab516ed153b7)

commit f450632077843a95a6ef269febbfb64a605045ed
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Dec 20 18:48:19 2018 +0100

    Explicitly keep track of whether a DRM event is for a flip or not
    
    When an async flip is performed, and TearFree is enabled on the CRTC
    used for timing, we schedule a vblank event for completing the page
    flip. The DRM event queuing code treated this event like a vblank event,
    but it needs to be treated like a page flip event.
    
    (Ported from amdgpu commit e2c7369cae65069aa93eed1c0b678f975ce5c274)

commit 189b6facb3988c00c96d970f8c13ed8d58fa3998
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Dec 20 18:44:24 2018 +0100

    Use drm_abort_one in drm_queue_handler
    
    At this point, we've already established that e->handler is NULL, no
    need to check again in drm_queue_handle_one. This also makes it clearer
    what's happening.
    
    (Ported from amdgpu commit eda571222f5a6be47f8897e82d85199bb9d95251)

commit 06957e3067b9eb38d30b32d98a07895399f4cb36
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Dec 20 18:40:19 2018 +0100

    glamor: Can work at depth >= 15 with current xserver Git master
    
    (Ported from amdgpu commit 0734cdf544ffd3f2ac8749ad0e4bf43f8a5cea50)

commit 99ac121770da53196124d80375a5c8edbcf827fa
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Dec 20 18:38:33 2018 +0100

    Skip gamma correction of cursor data if premultiplied R/G/B > alpha
    
    The un-premultiplied R/G/B values would overflow the gamma LUT, so just
    pass through the data unchanged, and leave it up to the HW how to
    interpret such weird premultiplied alpha pixels.
    
    Bugzilla: https://bugs.freedesktop.org/108355
    (Ported from amdgpu commit 13c94a373b4858a2d2aa14c22b5f98d53c84c0d9)

commit 0c40a76d1c050d018e6d59bebb5efc9c62be308c
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Dec 20 18:25:21 2018 +0100

    Detect and fix up non-premultiplied cursor data
    
    X server >= 1.18 already has code for this, but handle it with older X
    servers as well.
    
    (Ported from amdgpu commits ad6dfb0124860cf67730bde85867f81d9258c84d &
     426f9a49655f01863cf4d898f525e5f95984e0c4)

commit 0058fd2ebf4c900b12f129984e98886a7ac84b2f
Author: Mario Kleiner <mario.kleiner.de@gmail.com>
Date:   Tue Dec 18 11:40:35 2018 +0100

    Fix crash when page flipping in multi-X-Screen/Zaphod mode
    
    radeon_do_pageflip() indexed the flipdata->fb[] array
    indexing over config->num_crtc, but the flip completion
    routines, e.g., drmmode_flip_handler(), index that array
    via the crtc hw id from drmmode_get_crtc_id(crtc).
    
    This is mismatched and causes indexing into the wrong
    array slot at flip completion -> Server crash.
    
    Always use drmmode_get_crtc_id(crtc) for indexing into
    the array to fix this.
    
    Tested on a dual-X-Screen setup with one video output
    assigned to each X-Screen, page-flipping an OpenGL app
    on either of both X-Screens. This used to crash when
    flipping on X-Screen 1, now it doesn't anymore.
    
    Fixes: 740f0850f1e4 "Store FB for each CRTC in drmmode_flipdata_rec"
    Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>

commit b559fd83b2b026b50fe39a2b69bdc0901fd3330c
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Mon Nov 19 11:38:22 2018 +0100

    Post-release version bump

commit 33cbd449b5305b8e8c0319af8becc1ab1832c101
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sun Nov 18 12:22:16 2018 -0800

    Update README for gitlab migration
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

commit 5e6fa5c17a810127f0049816f20db6b871ca77e0
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Oct 24 18:22:05 2018 +0200

    Allow up to six instances in Zaphod mode
    
    Corresponding to up to six CRTCs being available in the hardware.
    
    (Ported from amdgpu commit c9d43c1deb9a9cfc41a8d6439caf46d12d220853)

commit c480fd066fe129fa6561fca8c09f037613b753e8
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Oct 24 18:19:42 2018 +0200

    Make wait_pending_flip / handle_deferred symmetric in set_mode_major
    
    We were always calling the latter, but not always the former, which
    could result in handling deferred DRM events prematurely.
    
    (Ported from amdgpu commit 955373a3e69baa241a1f267e96d04ddb902f689f)

commit 86fe8d27b9a3f043e5288ce50eaf1f5fffd24516
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Oct 24 18:14:02 2018 +0200

    Handle pending scanout update in drmmode_crtc_scanout_free
    
    We have to wait for a pending scanout flip or abort a pending scanout
    update, otherwise the corresponding event handler will likely crash
    after drmmode_crtc_scanout_free cleaned up the data structures.
    
    Fixes crash after VT switch while dedicated scanout pixmaps are enabled
    for any CRTC.
    
    (Ported from amdgpu commit 0cd2c337d2c02b8ec2bd994d6124b4aaaad10741)

commit f892d3791219d1041e0cbb1b866e15774004aa18
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Mon Oct 15 17:14:41 2018 +0200

    dri3: Handle radeon_get_pixmap_bo returning NULL
    
    We were trying to already, but testing the wrong pointer.
    
    Fixes: b85b7b11f5b5 "Add struct radeon_buffer"
    Bug: https://bugs.debian.org/910846
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

commit 80514b7b1b88f46f3965ff023035dea83b57e652
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Sep 14 17:48:49 2018 +0200

    Bump version for 18.1.0 release

commit 2d58830c3feafc54dccc0b7bf761a466437d4a09
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Sep 5 18:23:29 2018 +0200

    Fix uninitialized use of local variable pitch in radeon_setup_kernel_mem
    
    Fixes server reset.
    
    Pointed out by clang:
    
    ../../src/radeon_kms.c:2721:9: warning: variable 'pitch' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
        if (!info->front_buffer) {
            ^~~~~~~~~~~~~~~~~~~
    ../../src/radeon_kms.c:2765:27: note: uninitialized use occurs here
        pScrn->displayWidth = pitch / cpp;
                              ^~~~~

commit 5d5d883496842da84d9418e91cb13454751da625
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Sep 7 18:16:22 2018 +0200

    Bail early from drm_wait_pending_flip if there's no pending flip
    
    No need to process any events in that case.
    
    (Ported from amdgpu commit ca5eb9894fff153c0a1df7bdc4a4745713309e27)

commit 4c7d5e50a5e469a541bc463cecb505fe850c0824
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Sep 5 11:29:43 2018 +0200

    Don't use xorg_list_for_each_entry_safe for signalled flips
    
    drm_wait_pending_flip can get called from drm_handle_event, in which
    case xorg_list_for_each_entry_safe can end up processing the same entry
    in both. To avoid this, just process the first list entry until the list
    is empty.
    
    (Ported from amdgpu commit 26770be44b89b83bf39c28f2fe284c8cb92ed0c0)

commit 87b9a3e516d19dd1b89a64f6cac990fae53fc1b3
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Sep 5 11:27:25 2018 +0200

    Always delete entry from list in drm_queue_handler
    
    We left entries without a handler hook in the list, so the list could
    keep taking longer to process and use up more memory.
    
    (Ported from amdgpu commit 7eea3e2cd74eed22e982319144e18ae5b1087b78)

commit de88ea2755611bdcb18d91d8234d2ab5be8ff2e9
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Aug 24 11:00:16 2018 +0200

    glamor: Handle ihandle == -1 in radeon_glamor_set_shared_pixmap_backing

commit 84bde2df5b453f8aab35aa18b0cf1f20b8d20488
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Aug 24 10:58:51 2018 +0200

    EXA: Handle ihandle == -1 in RADEONEXASharePixmapBacking

commit 1799680f7bd84e0618f34f4c7486799521ddaf83
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Aug 24 10:56:58 2018 +0200

    Handle ihandle == -1 in radeon_set_shared_pixmap_backing
    
    It means to stop using the shared pixmap backing.
    
    Fixes crash when changing PRIME slave output configuration.

commit 3c42bd04800211f64a17640c7ce7c4111ffd4978
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Aug 24 10:55:49 2018 +0200

    EXA: Handle NULL BO pointer in radeon_set_pixmap_bo

commit cba8fe4d64819aaa8ba516aa68dbe6d2aa153046
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Aug 23 18:59:18 2018 +0200

    Use AC_CONFIG_MACRO_DIR instead of AC_CONFIG_MACRO_DIRS
    
    Older versions of autoconf only supported the former.
    
    Acked-by: Alex Deucher <alexander.deucher@amd.com>

commit 7b01c10137aba24c8f61dd9b2a19ea257ad24371
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Aug 23 18:42:28 2018 +0200

    Add m4 directory
    
    Although normally it only warns about it, under some circumstances,
    aclocal can error out if this directory doesn't exist.
    
    Reported-by: John Lumby <johnlumby@hotmail.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>

commit 60cd28bbbe4f9db391b4f27c5ff9289d5c2bef40
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Aug 16 18:06:31 2018 +0200

    Remove drmmode_crtc_private_rec::present_vblank_* related code
    
    Not needed anymore with the more robust mechanisms for preventing nested
    drmHandleEvent calls introduced in the previous changes.
    
    (Ported from amdgpu commit 85cd8eef0cbed7b409b07f58d76dacd34aa3ddea)
    Acked-by: Alex Deucher <alexander.deucher@amd.com>

commit c42f6e2e61d166c8d3ef3fcad175d7050a00288b
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Jul 20 16:56:22 2018 +0200

    Defer vblank event handling while waiting for a pending flip
    
    This is to avoid submitting more flips while we are waiting for pending
    ones to complete.
    
    (Ported from amdgpu commit e52872da69ecc84dafb3355839e35b0383f0d228)
    Acked-by: Alex Deucher <alexander.deucher@amd.com>

commit ba83a866af5a3784fc4822614375cc081e93197c
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Aug 16 17:44:45 2018 +0200

    Add radeon_drm_handle_event wrapper for drmHandleEvent
    
    Instead of processing DRM events directly from drmHandleEvent's
    callbacks, there are three phases:
    
    1. drmHandleEvent is called, and signalled events are re-queued to
       _signalled lists from its callbacks.
    2. Signalled page flip completion events are processed.
    3. Signalled vblank events are processed.
    
    This should make sure that we never call drmHandleEvent from one of its
    callbacks, which would usually result in blocking forever.
    
    (Ported from amdgpu commit 739181c8d3334ff14b5a607895dfdeb29b0d9020)
    Acked-by: Alex Deucher <alexander.deucher@amd.com>

commit 93621e408c17dd9e082236c17f051c06558d7f4d
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Aug 16 17:27:06 2018 +0200

    Add radeon_drm_wait_pending_flip function
    
    Replacing the drmmode_crtc_wait_pending_event macro.
    
    (Ported from amdgpu commit 6029794e8a35417faf825491a89b85f713c77fc1)
    Acked-by: Alex Deucher <alexander.deucher@amd.com>

commit ecdf0b7ec9378bc386ce8276f16fb16d09f72812
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Aug 16 17:14:42 2018 +0200

    Move DRM event queue related initialization to radeon_drm_queue_init
    
    And make radeon_drm_queue_handler not directly accessible outside of
    radeon_drm_queue.c.
    
    (Ported from amdgpu commit 0148283984c77f7a6e97026edc3093497547e0a4)
    Acked-by: Alex Deucher <alexander.deucher@amd.com>

commit 824189b3da9edc33e1a4f5c6130a043da73c1a4c
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Aug 16 18:22:27 2018 +0200
[--snip--]
