On Wed, 8 Sep 2021 18:21:12 +0200 Dennis Filder <d.filder@xxxxxx> wrote: > 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. Hi, such broker daemon exists already. It is called systemd-logind, and maybe some of the logind replacements as well. Currently it handles session switching, the D-Bus API replacing the legacy VT switching API and drmSetMaster/drmDropMaster. It's also independent of the VT subsystem, so it can be used on all physical seats. The existing D-Bus API there is probably not flexible enough for the best hand-over experience though, as Simon said. Since session switching is what the logind API does, hand-over protocols would fit there IMO. > 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. DRM leasing was not designed for permanent hand-over. Instead, it was designed for temporarily leasing some KMS resources to another process, where the lessor can forcibly revoke them at any time. That said, I'm not sure what happens to the lessee if the lessor quits. I would expect the lease to get revoked, since how else would the next display server instance gain control if the lessor e.g. crashed. I'd keep the DRM leasing out of the permanent whole-device hand-off design, it seems like a detour to me. > 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. Your initial email came out a bit ranty rather than a technical question. I think it would help if you had a tangible goal, some specific behaviour you want to implement, and write that down in detail. Then it would be easier to discuss how to achieve that while not making the solution excessively single-purpose or hacky. Imaginary use cases are both fairly abstract so hard to discuss, and uncertain if they would ever actually be done - putting the effort needed at risk of being wasted, reducing interest. I acknowledge a lot of needs all over, but there are only so many hours in a day. My wish for a "KMS state reset" feature is in the same position. First I am working towards userspace features (color management and HDR) that I expect to highlight the need for the feature, and then see if the wish gets more traction - unless one day I would be able to work on it myself. It is also perfectly possible that KMS state reset feature will never happen, since it is too easy to fix KMS clients to just program more KMS properties. Thanks, pq
Attachment:
pgpQaCQUBhUTr.pgp
Description: OpenPGP digital signature
