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". 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
Attachment:
pgpzrfNYQ2gi6.pgp
Description: OpenPGP digital signature
