How to properly list number of monitors

Tue Dec 31 12:24:58 UTC 2019

On Sun, 29 Dec 2019 21:48:32 +0000
Jean Hertel <jean.hertel at hotmail.com> wrote:

> Hi Wayland developers,
> 
> My name is Jean Hertel and I'm the developer of adriconf[1], a
> small GUI utility to configure options of mesa drivers. I'm
> looking into improving our wayland support and would like to ask
> a few questions.
> 
> Under X11 I can count the number of screens with ScreenCount()
> macro. After knowing the number of screens I can then query mesa
> for the name of the driver and options of each of those screens
> with glXGetScreenDriver(screenNumber) and glXGetDriverConfig
> (driverName).
> 
> Under Wayland/EGL I can use the functions
> eglGetDisplayDriverName(display) and
> eglGetDisplayDriverConfig(display) [2]. Wayland provides us with
> the nice wl_display_connect() function. But for this function I
> need to known all the display names, the default being
> "wayland-0". How can I get the name and/or the number of the
> displays?

Hi,

Wayland does not have the concept of screens as it is with X11.
There is only one relevant Wayland socket to connect to, which
exposes everything there is to have about the display server. IOW,
the X11 screen number in DISPLAY variable has no Wayland
counterpart at all.

> Also, looking into the docs, It's not clear to me if we can have
> a different GPU backing each screen, can somebody please clarify
> to me?

Fundamentally Wayland connections do not map to any particular
device at all.

A Wayland display server usually (not guaranteed!) uses just one
render device for its compositing and clients need to make sure the
buffers they submit are usable by that device, but otherwise
clients are completely free to use any devices they find.

A Wayland display server may also attempt to avoid composite
rendering by using KMS planes with client buffers directly
(this is called composite bypass or direct scanout). This might
happen on any number of KMS devices the server might be using.

The almost deprecated Mesa-private Wayland interface wl_drm
advertises one DRM device that clients should usually pick by
default. It's not a hard requirement to use it though. Any buffer
the compositor can consume is good, regardless of what device was
used in rendering it.

wl_drm is being replaced with zwp_linux_dmabuf interface which is
a public interface and is in the process of gaining device
advertisement events[3], so that clients know which device the
compositor will be using with their dmabufs and so can take that
into account when choosing their own device and allocating buffers.
It will also allow clients to optimize for the direct scanout path.

> Finally, can we have a single display object backing all screens?
> Who defines this? The compositor implementation?
> My impression from reading the mesa source code is that the
> display server defines the screens and mesa just accepts it.

There are no "screens" on Wayland, so the question is hard to
answer.

It is no longer so, that you always render and display both on the
same DRM device. That does not even work at all on many embedded
systems, where the display device and the rendering device are
separate DRM devices. Mesa GBM and EGL implementations make the
connection between the two devices magically in some cases, but
users of Mesa (display servers or apps) are not quite forced to obey
that.

A "bare hardware" program (a Wayland display server, or anything
else) usually picks the KMS devices assigned to the seat, and then
somehow looks for render devices it can use. There can be any
number of KMS devices (from zero to multiple) and any number of
rendering devices (from zero to multiple) used by the program.

The same more or less applies to Wayland apps (clients). The
display server might say something about which KMS devices would be
nice to cooperate with, and which render device it must cooperate
with, but otherwise the clients are free to pick their rendering
devices.

Coming back to adriconf, I'm guessing you might do something like
enumerating the EGLDevice instances via EGL and then configuring
those? Or via the libdrm device API.

The only reason to poke a Wayland display server would be to find
out what rendering device it suggests by default.

So far I don't think applications have supported choosing the
render device themselves at all. If they initialize EGL Wayland
platform the default way, they probably just get the display
server's preferred rendering device. It does not necessarily have
to be so, though. Applications could choose any rendering device
and tell EGL to try to be compatible with the devices the display
server uses, but I have forgot which APIs and how that is supposed
to become possible. It had something to do with EGLDeviceEXT.

My point here is, it might be best to not assume that a Wayland
connection always defines which rendering device is being used. It
only defines which rendering device or devices might be preferred.

Maybe adriconf could be used to configure certain apps to use a
certain rendering device, overriding the display server
preference, somehow?

> 
> [1]: https://github.com/jlHertel/adriconf/
> [2]:
> https://www.khronos.org/registry/EGL/extensions/MESA/EGL_MESA_query_driver.txt

[3] https://gitlab.freedesktop.org/wayland/wayland-protocols/merge_requests/8

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20191231/af2cef95/attachment.sig>