Split render/display SoCs, Mesa's renderonly, and Wayland dmabuf hints
Hi all, I'm working on a Wayland extension [1] that, among other things, allows compositors to advertise the preferred device to be used by Wayland clients. In general, compositors will send a render node. However, in the case of split render/display SoCs, things get a little bit complicated. The Wayland compositor will find the display-only DRM device (usually at /dev/dri/card0). This DRM device will have a DRM primary node, but no DRM render node. The Wayland compositor will create a GBM device from this display-only device, then create an EGL display. Under the hood, Mesa's kmsro will kick in and magically open a render node from a different device. However the compositor has no knowledge of this, and has no way to discover the render node opened by kmsro. This is an issue because the compositor has no render node to send to Wayland clients. The compositor is forced to send a primary node to clients. Clients will need to open the primary node and rely on Mesa's renderonly to once again magically open the render node under the hood. In general clients cannot be expected to be able to open primary nodes. This happens to work on systemd distributions because udev sets a special uaccess tag on the primary node that makes logind grant permissions to users physically logged in on a VT. This will fall apart on non-logind systems and on systems where no user is physically logged in. Additionally, it may be desirable to deny access to primary nodes in sandboxes. So I believe the best way forward would be for the compositor to send the render node to clients. This could prevent clients to allocate buffers suitable for scan-out, but that can be fixed with some kind of buffer constraints negotiation, like we presented at XDC 2020 [2]. There are a few solutions: 1. Require compositors to discover the render device by trying to import a buffer. For each available render device, the compositor would allocate a buffer, export it as a DMA-BUF, import it to the display-only device, then try to drmModeAddFB. 2. Allow compositors to query the render device magically opened by kmsro. This could be done either via EGL_EXT_device_drm, or via a new EGL extension. 3. Allow compositors to query the kernel drivers to know which devices are compatible with each other. Some uAPI to query a compatible display device from a render-only device, or vice-versa, has been suggested in the past. (1) has a number of limitations and gotchas. It requires allocating real buffers, this has a rather big cost for something done at compositor initialization time. It requires to select a buffer format and modifier compatible with both devices, so it can't be isolated in a simple function (and e.g. shared between all compositors in libdrm). Some drivers will allow to drmModeAddFB buffers that can't be scanned out, and will only reject the buffer at atomic commit time. (2) wouldn't work with non-EGL APIs such as Vulkan. Eric Anholt seemed pretty opposed to this idea, but I didn't fully understood why. I don't know how feasible (3) is. The kernel drivers must be able to decide whether buffers coming from another driver can be scanned out, but how early can they give an answer? Can they give an answer solely based on a DRM node, and not a DMA-BUF? Feedback is welcome. Do you agree with the premise that compositors need access to the render node? Do you have any other potential solution in mind? Which solution would you prefer? Thanks, Simon [1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/8 [2]: https://xdc2020.x.org/event/9/contributions/634/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
AW: Re: Weston: DIfferent background image on each output
Hi Pekka,
> Or, you could explain what you are *actually* trying to achieve in the
> first place, and people might be able to recommend something.
The original requirement is quite simple: Display an application (the only
application that is supposed to be run) on all monitor outputs. Do not show
an empty ("extended") desktop anywhere. --
I'll have a look into sway. Thanks for the suggestion!
Best,
Holger
Von: Pekka Paalanen
Gesendet: Freitag, 16. April 2021 17:20:42
An: Sebert, Holger.ext
Cc: wayland-devel@lists.freedesktop.org
Betreff: [Ext] Re: Weston: DIfferent background image on each output
On Fri, 16 Apr 2021 13:29:59 +
"Sebert, Holger.ext" wrote:
> Hi,
>
> in another thread I asked if it is possible to selectively enable or
> disable different connectors (HDMI, DisplayPort, etc.) in Weston. Since
> this is not possible (thanks for the answers, though!), I am thinking of
> another solution. --
>
> Suppose there are multiple monitors connected and Weston configures an
> independent desktop for each. Note that it may also happen that the
> user connects one and the same monitor on multiple connectors (e.g.
> both HDMI and DisplayPort). I need to avoid showing an empty desktop to
> the user.
>
> So, my first question is: How do I decide or control on which desktop
> my application will pop up? (It's a Qt application that is started
> in /etc/init.d on boot).
Hi,
programmatically from the app? I do not recall there being any Wayland
protocol extension for that.
Weston (desktop-shell plugin, really) picks a position (random),
possibly on the output which contains the pointer (if you have a
pointer).
> I would like to show a message (for example in the form of a
> background-image) on all desktops on which my application is NOT shown
> telling the user to check or switch monitor inputs.
>
> I am thinking of scanning /sys/class/drm for connected outputs and
> creating a suitable weston.ini in a start-up script. For this, however,
> Weston needs to support different background images on different
> outputs.
Different backgrounds feature is not implemented at this time.
> Is this possible? Does it make sense?
It feels very much like you are trying to bend Weston into doing
something that was never implemented yet, then trying to work around
that by hitting more features that were never implemented.
Weston is a very unfriendly compositor for normal desktop use, lacking
almost all the configurability and UI that one could expect from a
desktop. Maybe a different Wayland compositor would suit you better?
The wlroots-based Sway perhaps?
Or, you could explain what you are *actually* trying to achieve in the
first place, and people might be able to recommend something.
If you need particular behaviour like you have asked for, with Weston
you would have to modify the code to implement them. For example, the
output enabling logic and configuration is in the frontend right now,
in compositor/main.c.
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: AW: Re: Weston: DIfferent background image on each output
On Monday, April 19th, 2021 at 3:44 PM, Sebert, Holger.ext
wrote:
> Hi Pekka,
>
> > Or, you could explain what you are actually trying to achieve in the
> >
> > first place, and people might be able to recommend something.
>
> The original requirement is quite simple: Display an application (the only
> application that is supposed to be run) on all monitor outputs. Do not show
> an empty ("extended") desktop anywhere. --
>
> I'll have a look into sway. Thanks for the suggestion!
Maybe look into cage [1]. Or in Weston, there is a Kiosk mode in recent
versions.
[1]: https://www.hjdskes.nl/projects/cage
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
