[Bug 271995] graphics/drm-{510,515,61}-kmod: VT switch disables hardware acceleration

[email protected]
Newsgroups gmane.os.freebsd.devel.x11
Message-ID <[email protected]/bugzilla/>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271995

Ali Abdallah <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]

--- Comment #10 from Ali Abdallah <[email protected]> ---
Created attachment 261402
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=261402&action=edit
drm: check if fpriv is the current master of the device

Short story, the attached patch should fix the problem. 

Long story, the issue is reproducible with the modesetting drivers in Xorg, not
with the outdated xf86-video-intel or xf86-video-amdgpu. So proposing to add a
section to Xorg to use "Intel" driver instead of the modesetting driver has
nothing to do with the bug itself. 

When switching to VT, modesetting_drv calls drmDropMaster and drmGetMaster when
switching back to X. 

Without the additional check proposed in the patch, the magic map of the real
master of the device (which is Xorg) is cleaned up, programs using DRI were
getting a different magic_map for a different master, and thus the magic_map of
authenticated clients of the real master Xorg remains free, and so all clients
get authentication error, loosing hardware acceleration. You can trace the
idr_alloc/idr_find in drm_getmagic/drm_authmagic to see the problem yourself. 

I've tested with drm-61-kmod on amd based system Thinkpad T495 and intel one
X270 (without the amdgpu or intel xorg drivers obviously, using only
modesetting_drv) On FreeBSD 14.3-RELEASE

PS: Linux upstream commit:

0aae5920a84469: drm: Clear up master tracking booleans

-- 
You are receiving this mail because:
You are the assignee for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.