If the memory for an entry was allocated at the same address as that for
a previously cancelled entry, the handler could theoretically be called
prematurely, triggered by the DRM event which was submitted for the
cancelled entry.
(Ported from radeon commit 4693b1bd5b5c381e8b7b68a6f7f0c6696d6a68df)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Fixes hangs when attempting to use DRI3 on display connections forwarded
via SSH.
Don't do this for Xorg > 1.18.99.1 since the corresponding xserver
change has landed in Git master.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93261
(Ported from radeon commit 0b3aac1de9db42bfca545fa331e4985836682ec7)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This reverts commit ea558e6457.
It broke VDPAU<->GL interop with DRI3 enabled, because the Gallium VDPAU
code doesn't support DRI3 yet. We can consider re-enabling this once
there is a Mesa release where the Gallium VDPAU code supports DRI3.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94675
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
1.9.0 was released in August 2010.
We were already unintentionally relying on things not available in 1.8
for at least a year, and nobody has complained.
(Ported from radeon commit e592f32f8b5f5873fcc18b10a69dd5e4ccf11073)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
If it's available, Xorg calls it on each mode configuration change. It
does what xf86_reload_cursors does (and more), so we don't need to call
the latter anymore.
(Ported from radeon commit d670c5c9851b4eff21c845d26c7d7e4eb5ee0fa9)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Flipping doesn't interact correctly with SW cursor: A flip makes the SW
cursor disappear. It will only appear again when the cursor is moved,
but it will be surrounded by corruption, because the SW cursor code
will restore stale screen contents at the old cursor location before
drawing the cursor at the new location.
(Ported from radeon commit 7f3d0780ca65a90117c2a61362dbc0899bd9c0b0)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
And add a check for RandR 1.4 multihead.
(Ported from radeon commit 3de480e83c0a1824838d662d6d67c9fe85277298)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Doing it the other way around meant that there was still a possibility
for the front buffer contents to be uninitialized when they start being
scanned out.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Sync-to-vblank works fine with rotation. We're still checking for
rotation in amdgpu_present_check_flip.
Returning NULL from here resulted in the xserver present code falling
back to the fake CRTC running at 1 fps.
(Ported from radeon commit a03271de5ecdaa7790d1316e993c4450b91fe936)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Without this, drmmode_set_mode_major may just re-set the FB for the
last flipped BO, in which case the display will probably freeze.
Reproduction recipe: Enable rotation while a fullscreen client is
flipping.
(Ported from radeon commit 40191d82370eb7e58bd34c44966cbf44c3703229)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Support varies by xserver version:
< 1.12: No support for the driver handling rotation/reflection
1.12-1.15: Support for driver handling rotation/reflection, but there's
a bug preventing the HW cursor from being visible everywhere
it should be on rotated outputs, so we can only support
TearFree for reflection.
>= 1.16: While the bug above is still there (fixes pending review),
the driver can force SW cursor for rotated outputs, so we
can support TearFree for rotation as well.
(Ported from radeon commit 798c4fd16d339b1ad5fd729cc884be084c60e38b)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
We were already relying on pScrn->pScreen being non-NULL in some cases,
which is supposedly always true ever since this function is no longer
getting called from ScreenInit.
(Ported from radeon commit eb611a2e4ecce7a1ab85fd72b9b78e3269311dd5)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
We require xserver >= 1.8, which was already at version 3.
(Ported from radeon commit 06602171386e538081c298645fb7ca1a70fe80cc)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
If we set a mode while a flip is pending, the kernel driver may program
the flip to the hardware after the modeset. If that happens, the hardware
will display the BO from the flip, whereas we will assume it displays the
BO from the modeset. In other words, the display will most likely freeze,
at least until another modeset.
Prevent this condition by waiting for a pending flip to finish before
setting a mode.
Fixes display freezing when setting rotation or a transform with
TearFree enabled.
(Ported from radeon commit a88985f5d1e39caca49ceb65678aaa9cb622a0d2)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This allows for a minor simplification of the code.
(Ported from radeon commit f5d968cbba3c9b7ec202161f2157d8d64778c817)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
No longer necessary now that amdgpu_drm_queue_handler can handle
e->handler == NULL.
(Ported from radeon commit d5dbb07db22d5420c81dfebc060f0dd86e7b8a20)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Fixes the following problem:
With DRI3 enabled, run glxgears with LIBGL_DRI3_DISABLE=1, make it
fullscreen and press Escape while it's still fullscreen. This could
result in dri2_flipping not getting cleared, spuriously preventing apps
using DRI3 from flipping.
(Ported from radeon commit e87365117acbd80b7d80fbb5eb30890ef7153291)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Keep them around until the DRM event arrives, but then call the abort
functions instead of the handler functions.
This is a prerequisite for the following fix.
(Ported from radeon commit 3989766edde85d1abe7024577b98fc9b007bc02a)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Currently, Xorg will only transform the cursor as of the first time the
cursor image changes after a transform is set.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80678
(Ported from radeon commit 9483a3d777919b224f70c3b4d01e4b320a57db31)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Instead of just "amdgpu", it's now e.g. "TONGA @ pci:0000:01:00.0".
(Ported from radeon commit c7cf00487cd6d4a5d0f39d5b92ff04f6420d6a32)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
We can't create our own struct amdgpu_buffer representation in this case
because destroying that would make the GEM handle inaccessible to glamor
as well. So just get the handle directly via dma-buf.
(ported from radeon commit 391900a670addec39515f924265bfa9f8bfa9ec0,
extended to cache BO handles in the private for non-DRI3 pixmaps as
well)
v2: Swap whole pixmap privates instead of just BOs in
amdgpu_dri2_exchange_buffers to avoid invalidating cached BO handles
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
(inspired by radeon commits dfad91fffb5bd013785223b42d78886df839eacf
and ccbda955ebae1d457d35293833f12791e0f9fb0b)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acceleration is required even for display offloading. Trying to enable
display offloading without acceleration resulted in a crash.
(ported from radeon commit b19417e2fddf4df725951aea5ad5e9558338f59e)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Otherwise the front buffer may not be accessible by the CPU, because Mesa
sets the AMDGPU_GEM_CREATE_NO_CPU_ACCESS flag for tiled buffers, because
accessing tiled buffers with the CPU makes little sense.
v2: Also handle Option "AccelMethod" "none"
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
If we were asked to create a shareable pixmap, it doesn't make sense
to return a pixmap which isn't shareable. Doing so caused trouble down
the line such as a crash with older versions of glamor when trying to
use GLX pixmaps of bpp < 32 via DRI2.
Signed-off-by: JimQu <jim.qu@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
The next commit will call the former from the latter. No functional
change.
Signed-off-by: JimQu <jim.qu@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Fixes xrandr (XRRGetOutputPrimary) not reporting any output as primary
after startup.
(Ported from radeon commit b16856b25086ffb27365ac2249b8da921066ce62)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Instead of up to twice as before.
v2: Remove free(busIdString) call from amdgpu_kernel_mode_enabled, the
bus ID string is now managed by its callers.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
It may be disabled in the Xorg build, either explicitly or because the
xshmfence library isn't available.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This situation happens whit start of usage of DRM DP MST framework,
when connectors created and destroyed dynamically.
Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
When it's not available, it's safe to call down to the glamor
DestroyPixmap hook instead.
(ported from radeon commit 10b7c3def58bb34acc38f076bc230e25b454ab79)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This fixes a bug where running the card out of PPLL's when hotplugging
another monitor would result in all of the displays going blank and
failing to work properly until X was restarted or the user switched to
another VT.
[Michel Dänzer: Pass errno instead of -ret to strerror()]
Signed-off-by: Stephen Chandler Paul <cpaul@redhat.com>
(ported from radeon commit 7186a8713ba004de4991f21c1a9fc4abc62aeff4)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
