> On Tue, 07 Sep 2021 10:19:03 +0000 > Simon Ser <contact@xxxxxxxxxxx> 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 KMS state can be limited to single FB on primary plane covering the whole CRTC, no scaling, no other property set than FB_ID/CRTC_*/SRC_*. Is it useful to make the previous client perform the animation? I don't really understand the use-case here. > 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. Hm, right. I'm not 100% clear if it's possible for the next client to set everything up while the VT is not active. It would help to make logind/seatd give a non-master DRM FD when VT-switched away. Not sure they do it atm.
