Re: Handling DRM master transitions cooperatively

[Pekka Paalanen <ppaalanen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

On Tue, 07 Sep 2021 10:19:03 +0000
Simon Ser <contact@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".

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]