Source-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[xsrc/xorg]: xsrc/external/mit/xf86-video-ati-kms/dist initial import of xf86...
details: https://anonhg.NetBSD.org/xsrc/rev/7d503dc9eb54
branches: xorg
changeset: 10292:7d503dc9eb54
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_bo_helper.c | 2 +
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_kms.c | 284 ++++--
external/mit/xf86-video-ati-kms/dist/src/radeon_present.c | 11 +-
external/mit/xf86-video-ati-kms/dist/src/radeon_probe.h | 4 +-
18 files changed, 1149 insertions(+), 318 deletions(-)
diffs (truncated from 2431 to 300 lines):
diff -r 4611523e4d85 -r 7d503dc9eb54 external/mit/xf86-video-ati-kms/dist/ChangeLog
--- a/external/mit/xf86-video-ati-kms/dist/ChangeLog Sat Jun 01 07:11:05 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