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

[Drew DeVault]

On Thu Sep 12, 2019 at 2:42 PM Pekka Paalanen wrote:
> > This was resolved by choosing to have multiple drm_lease_manager
> > globals, one for each DRM device. No reworking should be necessary.
> 
> in that case, document it in the XML please.

ack

> > 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.

I thought about this, but I don't really like it. It would be adding
more complexity to this protocol for the sake of propping up a
second-class implementation, namely Xwayland. In the future, the
EDID/name/description should be more than sufficient to select the
hardware you want to lease, and from that point forward you should just
query DRM yourself to find modes and such. One source of truth is better
than two.

> 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.

Some care would have to be taken to make sure that the compositor
creates a non-master DRM fd instead of accidentally making another
master fd. I think this would be a reasonable solution, though.

> 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, simplifying things, we could send them that non-master fd and then
they can just query it themselves and match the resources by their IDs
with the resources offered for lease by the compositor. I'm not sure why
constraining the resources they can browse (read-only) is necessary. We
could drop the EDID if we went with this approach.

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

NACK to sysfs for this reason