On Fri, 18 Oct 2019 10:43:16 -0400 "Drew DeVault" <sir@xxxxxxxxx> 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 disconnected. 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 shall see. > 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. Thanks, pq
Attachment:
pgp8jQpw3Q4jh.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
