[PATCH wayland-protocols v5] unstable/drm-lease: DRM lease protocol support
p.zabel at pengutronix.de
Thu Sep 6 13:36:00 UTC 2018
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  is accepted, it will by
default behave exactly as if "mode=off" was set for non-desktop displays
> 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
> > 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:
without inserting round-trips to wait for these events in-between.
More information about the wayland-devel