X11Libre
modesetting: Use don't skip planes that are not on the current crtc
This breaks on some nvidia cards.
Fixes: https://github.com/X11Libre/xserver/commit/ed49ae8fe7f919998a3f6db64899cf2294b9d145
My knowledge is not deep in libdrm/drm, shouldn't we rebuild plane->crtc->encoder graph ? As I understand, this problem manifest when plane has no configured crtc, but it allowed to use?
Or I totally wrong about this?
My knowledge is not deep in libdrm/drm, shouldn't we rebuild plane->crtc->encoder graph ?
Not sure what you mean by this?
As I understand, this problem manifest when plane has no configured crtc, but it allowed to use?
Not necessarily, it may be that some of the primary planes have no configured crtc, while others have a crtc configured, but not the one we are on.
This code makes it so that we try to use a plane that is already on the current crtc, but if there is none, we use the first primary plane we find as a fallback. This is so that we don't get a black screen in this sub-optimal case.
Unrelated, but looking at this, doing drmSetClientCap(drmmode->fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);
in drmmode_crtc_create_planes also looks wrong. We should only do that once, in driver.c, not for every crtc.
My knowledge is not deep in libdrm/drm, shouldn't we rebuild plane->crtc->encoder graph ?
Not sure what you mean by this?
I meant "...it may be that some of the primary planes have no configured crtc, ..."
On unrelated note, Looking at this I suspecting that we should start try to play with vkms (https://bootlin.com/pub/conferences/2025/elce/chauvet-vkms.pdf https://docs.kernel.org/gpu/vkms.html)
My knowledge is not deep in libdrm/drm, shouldn't we rebuild plane->crtc->encoder graph ?
Not sure what you mean by this?
I meant "...it may be that some of the primary planes have no configured crtc, ..."
I got that, I'm not sure what you meant by 'rebuild plane->crtc->encoder graph'?
The code walks the planes returned by the kernel and, for primary planes, picks one we deem "best".
For this "best" plane, we parse it's IN_FORMATS and IN_FORMATS_ASYNC blobs, and then free what resources we allocated.
Now that I write this, I wonder how was I able to get a black screen on nvidia without this? If we don't find a plane, we don't get any formats, which should mean 'driver chooses'. @metux @notbabaisyou Any ideas?
On unrelated note, Looking at this I suspecting that we should start try to play with vkms (https://bootlin.com/pub/conferences/2025/elce/chauvet-vkms.pdf https://docs.kernel.org/gpu/vkms.html)
Some runtime CI would really be nice.
Unrelated, but looking at this, doing
drmSetClientCap(drmmode->fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);indrmmode_crtc_create_planesalso looks wrong. We should only do that once, in driver.c, not for every crtc.
opened: https://github.com/X11Libre/xserver/pull/1512
@notbabaisyou Would it make any sense to add some criteria for a "best" cursor plane too, for probing SIZE_HINTS?
@notbabaisyou Would it make any sense to add some criteria for a "best" cursor plane too, for probing
SIZE_HINTS?
I'm not sure, but I don't believe that there is any hardware out there that will have different limitations on the cursor plane.
Will take a look at this, need to figure out if it makes sense to use planes from different CRTCs in the first place and if we need to add extra handling logic for drivers that only expose primary planes, so that we gracefully fallback to software cursors (or have a driver blacklist for universal planes on those drivers)
and if we need to add extra handling logic for drivers that only expose primary planes, so that we gracefully fallback to software cursors (or have a driver blacklist for universal planes on those drivers)
If the SIZE_HINTS probe fails, we fall back to the legacy probe. If that also fails, we fall back to what the kernel says is the largest possible cursor. If that also fails, we fall back to 64x64. If 64x64 also fails, we fall back to software cursors.