Handling DRM master transitions cooperatively

[Pekka Paalanen]

On Wed, 08 Sep 2021 09:51:54 +0000
Simon Ser <contact at emersion.fr> wrote:

> > 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 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.

I guess the use cases are more or less imaginary for now.

Imagine one HDR-capable display server handing off to another
HDR-capable display server. If the releasing display server does not
know the receiving display server understands HDR, the releasing
display server might run an animation to turn HDR off - fade to black,
for instance, so that the impact from changing from HDR to SDR is
minimized. Then the receiving display server sees KMS is in SDR mode,
and maybe sets up a black image and then switches back to HDR.

If you're happy with fade-to-black on switch, then no problem. However,
the only way to not fade-to-black or even come cross-fade is
some negotiation to see that both sides understand HDR.

If the previous FB was rendered for HDR display, you will need to know
a lot from it if you want to do a cross-fade that doesn't glitch.

Also, while I don't see why changing between SDR and HDR would require
a modeset in KMS, I suppose it might take a moment for the monitor to
adapt. It might cause glitches similar to changing video modes.

> > 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.

Oh yeah, that may be an obvious gap I missed.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20210908/f52c0d39/attachment.sig>