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). 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. On Fri Oct 18, 2019 at 5:34 PM Pekka Paalanen wrote: > > So the rules are (if I'm not making a mistake) > > - If you're not CAP_SYS_ADMIN you can't get/drop_master. > > not able to drop, yikes. So if someone pokes the Wayland DRM leasing > interface while the display server is VT switched away (does not have > DRM master), and maybe no-one else has DRM master either (you're > hacking in VT text mode), then a new DRM fd would be master with no way > out? fwiw I have an assert(!drmIsMaster(fd)); before I send it to the client, just to be safe. But this may be misguided, since apparently if it ends up with a master node drmDropMaster(fd) won't work. I kind of find this hard to believe, if there's only ever one master, and the master cannot drop master, then why does this ioctl even exist? > So Wayland display servers should make sure they have master themselves > before sending a supposedly non-master DRM fd to anyone else. I wonder > if the Wayland protocol extension needs to consider that the compositor > might not be able to send any fd soon. Being able to defer sending the > fd should probably be mentioned in the protocol spec, so that clients > do not expect a simple roundtrip to be enough to ensure the fd has > arrived. When you VT switch away, the Wayland compositor is no longer necessarily able to lease those displays anyway - it's not the master anymore. So it should withdraw them, and in case of a race it'll reject the lease request. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
