[PATCH v7] unstable/drm-lease: DRM lease protocol support
ppaalanen at gmail.com
Fri Oct 18 15:26:05 UTC 2019
On Fri, 18 Oct 2019 10:43:16 -0400
"Drew DeVault" <sir at cmpwn.com> wrote:
> Regarding hotplugging, the Wayland compositor is probably keeping track
> of hotplugs itself and withdrawing/offering connectors as appropriate.
> Also, when the lease is issued, the compositor withdraws that connector.
> For the client, upon hotplug I imagine the DRM asks start to fail, and
> it handles that accordingly (presumably it'll close the lease, if the
> compositor hasn't already, and wait for it to come back, or just exit).
DRM KMS operations do not fail merely because a connector becomes
disconnected. You can even force on a connector that is initially
If you mean on revoking the lease or losing DRM master, yes, then I'd
expect KMS ioctls start to fail.
But is disconnection reason enough to revoke the lease? I guess we
> When a hotplug of a leased connector happens on the compositor side, it
> can notice this and exercise its descretion in the implementation. I
> think the current text of the protocol supports this view.
Ok, so the expectation is that a compositor does not offer disconnected
connectors, and withdraws offered but then disconnected connectors, and
that it sends offers for connectors that become connected while
leasable. I suppose that is reasonable, I still think a sentence
suggesting towards such behaviour would be in place.
Btw. there is more to hotplug events than just connected/disconnected:
link status changes, and HDCP status changes. I suspect more is coming,
too. At some point we might need to add a hotplug event in the
protocol, but I think that is easy to do even after stabilization.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the dri-devel