Commits on Source (10)
-
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)
-
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 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 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 authored
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)
-
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 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)
-
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)
-
Michel Dänzer authored
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>
-
Michel Dänzer authored
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: ba83a866 "Add radeon_drm_handle_event wrapper for drmHandleEvent" (Ported from amdgpu commit 09be74a3d1dd9604336d9a27f98d132b262dcbaf) Reviewed-by:
Alex Deucher <alexander.deucher@amd.com>
-
Michel Dänzer authored