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.
Userspace protocol is also useful for starting the next KMS client first and handing off only later once it's actually running. I'm not sure if that is already possible with the session switching stuff, but I have a feeling it might be fragile or miss pieces like the next KMS client signalling ready before actually switching to it. Thanks, pq
