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>
Not used directly.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
(ported from radeon commit fcb32231a38f9461d12720cbf72f63502197a711)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The vblank / page flip ioctls don't work as expected for a disabled CRTC.
(ported from radeon commit acc11877423ecd81a6e0a7f38466f80e43efee20)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The former includes information about the position of the hotspot within
the cursor image.
Copied from xf86-video-modesetting.
(ported from radeon commit c9f8f642fd495937400618a4fc25ecae3f8888fc)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Removes the need for a double negation when forcing acceleration on.
Note that this change is backwards compatible, as the option parser
automagically handles the 'No' prefix.
(ported from radeon commit cc615d06db0332fc6e673b55632bcc7bf957b44b)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
I plan to delete the Weak functions from a future server.
Signed-off-by: Adam Jackson <ajax@redhat.com>
(ported from radeon commit 851b2cf8714618843725f6d067915375485ade9d)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Fixes warning when building with --disable-glamor:
../../src/amdgpu_dri3.c: In function 'amdgpu_dri3_fd_from_pixmap':
../../src/amdgpu_dri3.c:135:16: warning: unused variable 'info' [-Wunused-variable]
AMDGPUInfoPtr info = AMDGPUPTR(scrn);
^
Reported-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Increase pAMDGPUEnt->fd_ref in the probe code instead when we're reusing
the existing fd.
The previous reference counting was imbalanced, so pAMDGPUEnt->fd_ref
could never go to 0.
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
The crash is caused by the NULL value returned by AMDGPUPTR(pScrn),
because the driverPrivate is not allocated yet in PciProbe phase,
and it is usually done in the PreInit phase.
Use pAMDGPUEnt->fd instead of info->dri2.drm_fd to avoid AMDGPUInfoPtr
related code in amdgpu_open_drm_master, so that the crash can be fixed.
v4: (md) Remove unused parameter entity_num, split out logically
separate changes
v3: some more cleanup
v2: switch to pAMDGPUEnt->fd, and update the commit message
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v3)
amdgpu_get_scrninfo allocates the memory pointed to by pAMDGPUEnt just
before it calls amdgpu_open_drm_master, so pAMDGPUEnt->fd is always 0
in the latter.
Also, no need to clear pAMDGPUEnt->fd just before freeing the memory
it's stored in.
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
