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

[Pekka Paalanen]

On Fri, 13 Sep 2019 09:32:01 -0400
"Drew DeVault" <sir at cmpwn.com> wrote:

> On Thu Sep 12, 2019 at 2:42 PM Pekka Paalanen wrote:

...

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

Hi Drew,

I don't like it either, but it is an option.

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

This idea would need to be checked by the kernel DRM developers, there
could be a catch we're not aware of.

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

My only reason is that it would be obvious which resources the
compositor will not lease out. If the resource picking in the client is
automatic, that's not a big deal. But if the client has some UI to let
the user pick a connector, it might be useful. Or, we need accompanying
Wayland events to carry the leasability, but they could be as simple as
device/drm-resource-id and nothing more.


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/20190916/d9fd7ac5/attachment.sig>