[PATCH v6] unstable/drm-lease: DRM lease protocol support

[Pekka Paalanen]

On Wed, 11 Sep 2019 14:48:20 -0400
"Drew DeVault" <sir at cmpwn.com> wrote:

> On Mon Sep 2, 2019 at 3:51 PM Pekka Paalanen wrote:
> > Hi Drew,
> > 
> > I seem to recall that you didn't want to add multi-DRM-device support
> > here just yet and go first with just one implied DRM device. That is
> > ok, but would be nice to have a TODO note somewhere near the top in the
> > XML file saying that this will be re-designed to support multiple DRM
> > devices at some point.  
> 
> This was resolved by choosing to have multiple drm_lease_manager
> globals, one for each DRM device. No reworking should be necessary.

Hi,

in that case, document it in the XML please.

I didn't see any identification of the DRM device in that case, meaning
that they would be all anonymous. It may be significant for VR
performance to have the rendering and KMS happen both on the same
device. If the user plugs a HMD to the wrong card, it would be good to
be able to tell.

> > Can you point to the discussion or elaborate here on when a zero
> > connector lease would be useful?
> > 
> > I checked the Xwayland discussion and didn't see it there. I remember
> > some old talk about giving out a no-resources lease first for
> > discovering DRM resources to lease, but that didn't work because
> > non-leased resources would not be visible either.  
> 
> https://gitlab.freedesktop.org/xorg/xserver/issues/864
> 
> The main issue is that we have no way to enumerate detailed mode
> information in Xwayland to populate RandR, which is used by X clients in
> the wild today to prep for a DRM lease (the corresponding X extension
> for Vulkan is an example of where this is a problem).

Oh yes, that.

If that is to be solved with Wayland protocol, you'd have to send
events with all the kernel video modes.

Some random thoughts:

Was it considered to give out full (as in, not leased) but non-master
DRM device fds for iterating possible resources? A compositor would get
one by opening the DRM device again. I'm assuming that logind would do
a new open() for it.

It has the drawback that the resources would be unfiltered by the
compositor.

About a possible attack vector, I don't think the client could gain DRM
master even if the compositor dropped it unless the client is already
root.

I'm starting to think that what you might need is a lease fd that
cannot be DRM-master. Then the compositor could create a "pre-lease"
with all the resources it could be willing to lease out. The client
would use KMS UAPI to query everything, and then decide what it wants to
actually lease. That would avoid sending EDID, modes and whatnot over
Wayland.

Or maybe sysfs could expose all the information (EDID, modes,
whatnot).

Lastly, there is the arduous option of defining how to serialize
everything to be passed through Wayland. You already have EDID. You
could add video modes to that blob by defining more structure.

I might favour sysfs, but then I guess BSD would be left out cold.


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/20190912/deaa8f3e/attachment-0001.sig>