Am 06.09.23 um 11:08 schrieb suijingfeng:
Well, welcome to correct me if I'm wrong.
You seem to have some very basic misunderstandings here.
The term framebuffer describes some VRAM memory used for scanout.
This framebuffer is exposed to userspace through some framebuffer
driver, on UEFI platforms that is usually efifb but can be quite a bunch
of different drivers.
When the DRM drivers load they remove the previous drivers using
drm_aperture_remove_conflicting_pci_framebuffers() (or similar
function), but this does not mean that the framebuffer or scanout
parameters are modified in any way. It just means that the framebuffer
is just no longer exposed through this driver.
Take over is the perfectly right description here because that's exactly
what's happening. The framebuffer configuration including the VRAM
memory as well as the parameters for scanout are exposed by the newly
loaded DRM driver.
In other words userspace can query through the DRM interfaces which
monitors already driven by the hardware and so in your terminology
figure out which is the primary one.
It's just that as Thomas explained as well that this completely
irrelevant to any modern desktop. Both X and Wayland both iterate the
available devices and start rendering to them which one was used during
boot doesn't really matter to them.
Apart from that ranting like this and trying to explain stuff to people
who obviously have much better background in the topic is not going to
help your patches getting upstream.
Regards,
Christian.
