Re: Handling DRM master transitions cooperatively

[Dennis Filder <d.filder@web.de>]

On Wed, Sep 08, 2021 at 09:51:54AM +0000, Simon Ser wrote:
> > 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".
>
> 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.

The use case for the animation is e.g. the transition from Plymouth to
the display server.  Currently it is done as a still frame transition,
maybe with a blend-over effect.  But with the current design it is not
possible to blend Plymouth's animation over into another animation in
the display server because the second client lacks the knowledge how
to keep it going for a little bit.

Another use case is switching between sessions which currently also is
only possible as a still frame transition.  However, if you wanted to
present the session switching by doing e.g. a shaking screen animation
and blending the old display content over into the new content then
the first client would have to render the first half of the animation,
and the second client would have to render the second half during
which it would then blend away the content of the first screen while
blending in its own content and also slowing the shaking to a stop.
For that to work the second client would need all the information
necessary to render that animation, and also a way to perform the
frame-perfect change-over.

Granted, that is a very complicated, eye-candy-oriented use case, but
it would serve to show-case the potential of the design.

Regards.