On Tue, Sep 07, 2021 at 05:52:41PM +0200, Sebastian Wick wrote: > > On Tue, 07 Sep 2021 10:19:03 +0000 > > Simon Ser <contact at emersion.fr> wrote: > > > > > FWIW, I've just hit a case where a compositor leaves a "rotation" KMS > > > prop set behind, then Xorg tries to startup and fails because it doesn't > > > reset this prop. So none of this is theoretical. > > > > > > I still think a "reset all KMS props to an arbitrary default value" flag > > > in drmModeAtomicCommit is the best way forward. I'm not sure a user-space > > > protocol would help too much. > > > > Hi Simon, > > > > for the "reset KMS state" problem, sure. Thanks for confirming the > > problem, too. > > > > The hand-off problem does need userspace protocol though, so that the > > two parties can negotiate what part of KMS state can be inherited by > > the receiver and who will do the animation from the first to the second > > state in case you want to avoid abrupt changes. It would also be useful > > for a cross-fade as a perhaps more flexible way than the current "leak > > an FB, let the next KMS client scrape it via ioctls and copy it so it > > can be textured from". > > The state reset already is an implicit protocol. Another IPC mechanism > however could extend it to work the other way around: instead of > inheriting all the state and trying to transition from that to the > second client's desired state the second client would send its own > desired state back to the first (instead of applying it immediately) > which would then try to transition from its own state to the second > state (and if it can't you fall back to the implicit inherited state > protocol). However, this is only an improvement if the first client > knows how to do the transition and the second does not. All in all I > doubt that you can convince most people to add this kind of complexity > just for slightly higher chances of a good transition. > > The reset state protocol on the other hand solves real problems and > gives you a good transition as long as the second client knows about the > same properties as the previous one which usually is the case for the > typical bootsplash->login manager->compositor chain. > > Maybe I'm completely missing how such a protocol would work though.
The idea was that since you would have to have some IPC mechanism in user space anyway to quickly effect a flicker-free transition from Plymouth to the display manager (since, as de Goede reiterates in the other message, both processes must have the device already open and call drmSetMaster/drmDropMaster coordinatedly) you might just as well look for ways how it could be designed for the benefit of everyone. Using "implicit protocols" for things like this is usually the go-to way, not because it's good design, but because it is easy to implement. But these "implicit protocols" have a tendency to greatly limit what can be done and to not be easily adaptable once the use cases become more complicated or refined, and thus they force contortions on everyone eventually. How such a protocol could look? I don't know. Maybe some DBus interface for a broker/multiplexer for shared devices that would keep track of the current DRM master and tell any process interested in obtaining it what process to talk to. It could then contact it either via DBus or over a separate socket, communicate its capabilities, negotiate the modalities for the transition and acquire the necessary resources in the form of file descriptors passed over DBus/the socket. Then both processes could set themselves up for the transition and effect it, which could involve e.g. unlocking a locked mutex/semaphore in shared memory. Alternatively, the donor could refuse the handover, e.g. if a screen locker is configured to prohibit release of the device. Complexitywise the sky would be the limit, of course, but it needn't be this complicated from the beginning. An initial version of such a protocol could be held just as simple as the status quo. As for the point raised by Paalanen that implementing something like this would require a lot of effort I must state that, while certainly true, many of the things I mentioned here are already implemented somehow somewhere. Plymouth has a control socket and protocol with which the state of the splash screen can be controlled from the outside to make the transition to gdm smoother. The xlease project apparently was designed with the intent that DRM devices should be leased (and subleased) out to processes, and cross-process coordination would be governed this way. The kmscon project also had to come up with something to govern device access since it could no longer piggy-back on the VT-API. systemd-logind also draws up a framework for governance over a shared device and how to tie them to sessions/seats (with such peculiarities that you cannot auto-spawn a getty on tty1 since that is "reserved" for Wayland). Then there is the VT console, and probably lots of other little things I don't even know about. All this effort is already being expended, and IMO it proves the need for some way to gracefully coordinate access to shared devices that offers more than what can be done with current "implicit protocols". The community should consider acknowledging this need and trying to answer the question what such a subsystem should and should not look like. Once the nature of the problem is understood better implementational questions will become easier. Regards.
