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

[Philipp Zabel]

Hi Marius,

On Thu, 2018-09-06 at 11:29 +0000, Marius-cristian Vlad wrote:
> > [...]
> > > - removed 'revoked' event entirely as it adds complexity without
> > > adding
> > > too much benefit.
> > 
> > The client will notice this via the leased drm fd sooner or later
> > anyway, so it seems that this event is not strictly necessary. I
> > wonder if there is any value in letting the client know immediately,
> > though. For example, if a client displays mostly static content
> > (like a presentation running on a non-desktop projector), it could
> > be a long while until the next page flip attempt.

[...]
> > Currently, all heads without enabled output are skipped, and trying
> > to lease a disabled monitor with:
> > 
> > [output]
> > name=HDMI-A-1
> > leasable=on
> > mode=off
> > 
> > crashes the compositor.
> 
> Yes, I've never taken this into consideration. I assume this is the
> case for HMDs where by default the connector will be disconnected?

Yes, in fact if the current implementation [1] is accepted, it will by
default behave exactly as if "mode=off" was set for non-desktop displays
in weston.ini.

[1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/12

> The output contains the scanout_plane which contains the plane id,
> and obviously for a disconnected output this will not be the case.

I see, that is a problem. drm_output contains the crtc_id as well, so do
we just need a way to attach a drm_head to a disabled drm_output?

[...]
> > What happens if a new connector becomes available, either because it
> > is
> > physically plugged in, or because another client cancels its lease?
> > This could be handled by sending the connector advertisement (again),
> > in which case leasable connectors could appear any time, not only
> > upon
> > connecting.
> 
> Care to explain a bit how exactly does the client reaches that state? 

I was thinking first about a hypothetical presentation application that
gets notified as soon as a projector is plugged into a non-desktop
connector. That way one could start the presentation program and plug in
the connector in either order and never have the desktop spill out onto
the projector.

[...]
> > Not sure if the "connector_add_failed" and "connector_added" events
> > are necessary. If something is wrong, the following "create" request
> > can just return the "failed" event.
> 
> I've kept these events because "failed" event seemed to generic for me,
> and explained a little bit in the beginning another reason why I've
> kept them. 

It would be great to add a note that these don't have to be waited for,
i.e. that it is possible to just call:

  -> "add_connector"
  -> "add_connector"
  -> "create"

without inserting round-trips to wait for these events in-between.

regards
Philipp