Source-Changes-HG archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

[xsrc/trunk]: xsrc/external/mit/xf86-video-ati-kms/dist initial import of xf8...



details:   https://anonhg.NetBSD.org/xsrc/rev/13400d798181
branches:  trunk
changeset: 10294:13400d798181
user:      mrg <mrg%NetBSD.org@localhost>
date:      Sat Jun 01 07:24:16 2019 +0000

description:
initial import of xf86-video-ati-19.0.1

diffstat:

 external/mit/xf86-video-ati-kms/dist/ChangeLog              |  486 ++++++++++++
 external/mit/xf86-video-ati-kms/dist/Makefile.am            |    2 +-
 external/mit/xf86-video-ati-kms/dist/Makefile.in            |    6 +-
 external/mit/xf86-video-ati-kms/dist/README.md              |   19 +
 external/mit/xf86-video-ati-kms/dist/configure              |   20 +-
 external/mit/xf86-video-ati-kms/dist/configure.ac           |    2 +-
 external/mit/xf86-video-ati-kms/dist/src/drmmode_display.c  |  396 ++++++--
 external/mit/xf86-video-ati-kms/dist/src/drmmode_display.h  |   23 +-
 external/mit/xf86-video-ati-kms/dist/src/radeon.h           |    3 +-
 external/mit/xf86-video-ati-kms/dist/src/radeon_dri2.c      |   29 +-
 external/mit/xf86-video-ati-kms/dist/src/radeon_dri3.c      |   41 +-
 external/mit/xf86-video-ati-kms/dist/src/radeon_drm_queue.c |  129 ++-
 external/mit/xf86-video-ati-kms/dist/src/radeon_drm_queue.h |    3 +-
 external/mit/xf86-video-ati-kms/dist/src/radeon_glamor.c    |    7 +-
 external/mit/xf86-video-ati-kms/dist/src/radeon_present.c   |   11 +-
 external/mit/xf86-video-ati-kms/dist/src/radeon_probe.h     |    4 +-
 16 files changed, 972 insertions(+), 209 deletions(-)

diffs (truncated from 1918 to 300 lines):

diff -r 649971c40a5e -r 13400d798181 external/mit/xf86-video-ati-kms/dist/ChangeLog
--- a/external/mit/xf86-video-ati-kms/dist/ChangeLog    Sat Jun 01 07:11:53 2019 +0000
+++ b/external/mit/xf86-video-ati-kms/dist/ChangeLog    Sat Jun 01 07:24:16 2019 +0000
@@ -1,3 +1,489 @@
+commit 36703f66c3b06875651606a6280d5dc9d9dad51e
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date:   Tue Mar 19 18:01:02 2019 +0100
+
+    Bump version for 19.0.1 release
+
+commit 4407c78bd86da4460ee07a15a365e07d99e0dd27
+Author: Dave Airlie <airlied%redhat.com@localhost>
+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@localhost>
+
+commit 79bc0e054f37026377d54cac6cd8127d4aa9baca
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+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@localhost>
+
+commit f6cd4a67d7de5d3ff1a6e58a8c83749fc8ffc310
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+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@localhost>
+
+commit 0d132d99e0b750896a78f47d73a8639680495d8c
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+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@localhost>
+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@localhost>
+
+commit 705020b6247eaa062edc9c88e6ad52f8c5468051
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+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@localhost>
+
+commit 15697ee242c30b9ea6775624e8282e0171a113a7
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+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@localhost>
+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@localhost>
+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@localhost>
+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@localhost>
+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@localhost>
+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@localhost>
+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@localhost>
+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@localhost>
+
+commit 38db1bbcfc019c92884c7819a6630c70e543f6b2
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+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@localhost>
+
+commit 803f872f7d4b2d80be434bb42ce64dfd295b122c
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+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@localhost>
+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@localhost>
+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@localhost>
+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@localhost>
+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



Home | Main Index | Thread Index | Old Index