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

[Simon Ser]

On Friday, June 28, 2019 10:51 AM, Marius Vlad <marius.vlad at collabora.com> wrote:
> >> +    <event name="connector">
> >> +      <description summary="advertise connectors available for leases">
> >> +        The compositor may choose to advertise 0 or more connectors which may be
> >> +        leased to clients, and will use this event to do so. This object may be
> >> +        passed into a lease request to lease that connector. See
> >> +        zwp_drm_lease_request_v1.add_connector for details.
> >> +
> >> +        When this global is bound, the compositor will send all connectors
> >> +        available for lease, but may send additional connectors at any time.
> >
> > I'm not sure the client is in the best position to decide which connectors to
> > pick here.
>
> If you assume connectors are (always) dynamic, they can appear and
> disappear at will (which is the real world). My initial take on this was
> to limit which connectors to advertise using the configuration file,
> idea being that the connectors advertised are already vouched by the
> compositor, but doesn't play that nicely with the idea of connectors
> appearing and disappearing.
>
> > Maybe it would be better for the client to say _why_ it needs a lease (e.g. it
> > needs the non-desktop connectors for VR) and let the compositor pick appropriate
> > connectors.
> >
> > What would be other use-cases for DRM leases? Probably fullscreen games? If the
> > compositor advertizes both non-desktop outputs (for VR) and desktop outputs (for
> > games), how should the VR client pick the right output?
>
> Testing. The ability to run 2 applications simultaneously was the
> initial use case for us, even though we didn't had any kind input for
> it. For instance I imagine intel-ci BAT running a bit faster (at least
> for some of the tests). dEQP was our candidate for speeding it things a
> bit and an internal testing framework. Showcasing.

I don't think we can run BAT faster, because we rely on dmesg, which is global
state.

> Maybe include the/a kind of connector type (based on that property -
> !non_desktop && non_desktop) besides the name of the connector. This
> combined with the connector name might provide enough information for
> the client to choose the correct HMD?

See Philipp Zabel's reply.