On Thu, 28 May 2020 17:46:08 +0800
Chih-Wei Huang <cwhu...@linux.org.tw> wrote:

> The main problem we're trying to solve is to
> find the DRM device of the primary framebuffer (fb0).

Hi,

I would say that is a completely wrong starting point. Please, let
fbdev die in peace/pieces. Do not make any new code that relies on
fbdev existing.

Why do you think you want to follow the setup fbdev has? How do you
know fb0 is the device you want and not fb1? How do you guarantee that
fb0 is the device you want?

"It was right on where I tested it" is no guarantee if you do not
understand how it actually is chosen under the hood. If you know how it
is chosen under the hood, you can do the same yourself without relying
on deprecated stuff (fbdev).

It is fbdev that should follow the DRM setup, not pick a DRM device
based on fbdev.

People already mentioned looking at device properties via libudev API.
If you cannot have libudev (I believe it does not need udev daemon,
btw.), then you can look at the same information directly in sysfs. Use
the information about the DRM devices themselves from sysfs to decide
which one to pick, and never look at fbdev anything. Or polish the
patch Emil proposed if boot_vga indeed matches what you actually want
to find.

I think Daniel Vetter explained nicely what boot_vga means. Is your
problem that the device may not be a PCI device, but a platform device
for instance?

Display servers use heuristics, for example if no device has boot_vga,
then pick the platform device (since there usually is only one with KMS
capabilities). Here are couple of examples.

Weston wants a device with KMS capabilities, because it currently
doesn't support using more than one KMS device and it also doesn't
explicitly support a separate render device:
https://gitlab.freedesktop.org/wayland/weston/-/blob/8.0.0/libweston/backend-drm/drm.c#L2546-2631

Mutter is primarily looking for a hardware rendering capable device,
because it can use any number of KMS devices in addition to a rendering
device, separate or same device:
https://gitlab.gnome.org/GNOME/mutter/-/blob/3.37.1/src/backends/native/meta-renderer-native.c#L3904-3953

Neither is probably perfect, but they are totally better than picking
based on fb0.


Thanks,
pq

Attachment: pgpsjByRoAfK9.pgp
Description: OpenPGP digital signature

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Reply via email to