Handling DRM master transitions cooperatively

Wed Sep 22 08:56:57 UTC 2021

On Tue, 14 Sep 2021 15:45:21 +0200
Daniel Vetter <daniel at ffwll.ch> wrote:

> On Thu, Sep 09, 2021 at 10:37:03AM +0300, Pekka Paalanen wrote:
> > On Wed, 8 Sep 2021 18:27:09 +0200
> > Daniel Vetter <daniel at ffwll.ch> wrote:
> >   
> > > On Wed, Sep 8, 2021 at 9:36 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:  
> > > >
> > > > On Tue, 7 Sep 2021 14:42:56 +0200
> > > > Hans de Goede <hdegoede at redhat.com> wrote:
> > > >    
> > > > > Hi,
> > > > >
> > > > > On 9/7/21 12:07 PM, Pekka Paalanen wrote:    
> > > > > > On Fri, 3 Sep 2021 21:08:21 +0200
> > > > > > Dennis Filder <d.filder at web.de> wrote:
> > > > > >    
> > > > > >> Hans de Goede asked me to take a topic from a private discussion here.
> > > > > >> I must also preface that I'm not a graphics person and my knowledge of
> > > > > >> DRI/DRM is cursory at best.
> > > > > >>
> > > > > >> I initiated the conversation with de Goede after learning that the X
> > > > > >> server now supports being started with an open DRM file descriptor
> > > > > >> (this was added for Keith Packard's xlease project).  I wondered if
> > > > > >> that could be used to smoothen the Plymouth->X transition somehow and
> > > > > >> asked de Goede if there were any such plans.  He denied, but mentioned
> > > > > >> that a new ioctl is in the works to prevent the kernel from wiping the
> > > > > >> contents of a frame buffer after a device is closed, and that this
> > > > > >> would help to keep transitions smooth.    
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I believe the kernel is not wiping anything on device close. If
> > > > > > something in the KMS state is wiped, it originates in userspace:
> > > > > >
> > > > > > - Plymouth doing something (e.g. RmFB on an in-use FB will turn the
> > > > > >   output off, you need to be careful to "leak" your FB if you want a
> > > > > >   smooth hand-over)    
> > > > >
> > > > > The "kernel is not wiping anything on device close" is not true,
> > > > > when closing /dev/dri/card# any remaining FBs from the app closing
> > > > > it will be dealt with as if they were RmFB-ed, causing the screen
> > > > > to show what I call "the fallback fb", at least with the i915 driver.    
> > > >
> > > > No, that's not what should happen AFAIK.
> > > >
> > > > True, all FBs that are not referenced by active CRTCs or planes will
> > > > get freed, since their refcount drops to zero, but those CRTCs and
> > > > planes that are active will remain active and therefore keep their
> > > > reference to the respective FBs and so the FBs remain until replaced or
> > > > turned off explicitly (by e.g. fbcon if you switch to that rather than
> > > > another userspace KMS client). I believe that is the whole reason why
> > > > e.g. DRM_IOCTL_MODE_GETFB2 can be useful, otherwise the next KMS client
> > > > would not have anything to scrape.
> > > >
> > > > danvet, what is the DRM core intention?    
> > > 
> > > Historical accidents mostly. There's two things that foil easy
> > > handover to the next compositor:
> > > - RMFB instead of CLOSEFB semantics, especially when closing the
> > > drmfd. This is uapi, so anything we change needs to be opt-in  
> > 
> > What does this mean and refer to?
> > 
> > Are you trying to say, that closing the DRM device fd (freeing the file
> > description) causes an implicit RmFB on all the FBs tied to that DRM
> > device file description?
> > 
> > I never realised that before.  
> 
> Yes, final close does iterate over fb and do an RMFB. Which is why we've
> had this discussion whether closefb semantics should be an ADDFB2 flag at
> creation time instead.

Hi Daniel,

such flag would make sense to me.

> > > - Forced fbdev restore on final close of all drm fd. This is only
> > > prevented if there's a drm master left around (systemd-logind can keep
> > > that instead of forcing the compositor to survive until the other has
> > > taken over, which it needs to do anyway to prevent the drm master
> > > handover from going sideways). This can be fixed by simply disabling
> > > fbdev completely, which you really want to do anyway. Again it's uabi,
> > > people will complain if we break this I think.  
> > 
> > Do you mean that it is not enough to leave the tty in KD_GRAPHICS mode
> > to stop fbcon/fbdev from taking over?  
> 
> Nope. You need an open drm master.
> 
> This is because we do actually support /dev/fb clients rendering in
> KD_GRAPHICS mode for backwards compat with the fbdev subsystem.
> 
> > Is it really fbdev on its own rather than fbcon (poking at fbdev) that
> > will change the KMS state?
> > 
> > That is, it's not enough to disable fbcon?  
> 
> fbcon doesn't disable fbdev, and the only way to block fbdev is to have a
> drm master around.

Thanks for pointing this out.

> I guess we could try and make this smarter by creating some kind of weak
> master status for fbdev, but only when either fbcon or fbdev is opened.
> Maybe this would help?

It would make sense to me if we wanted a bandaid, but do we? I don't
know.

> fbdev already keep track of this open count, so wouldn't be too onerous to
> wire that up into drm_client.
> 
> The problem there is then that not yet all drivers use the drm_client
> stuff for fbdev emulation, so you'd need to either convert more, or hack
> up a few more things to make this consistent.
> 
> > > > Or am I confused because display servers do not tend to close the DRM
> > > > device fd on switch-out but Plymouth does (too early)?    
> > > 
> > > Yeah, that stops both forced restore/disable from kicking in.  
> > 
> > Which "that"?  
> 
> that = open drm master. Open drm master alwasy wins agains fbdev/fbcon,
> and with latest patches it's guaranteed to be race free.
> 
> > > > If so, why can't Plymouth keep the device open longer and quit only
> > > > when the hand-off is complete? Not quitting too early would be a
> > > > prerequisite for any explicit hand-off protocol as well.    
> > > 
> > > With closefb semantics and fbdev disabled plymouth could quit early,
> > > and things still work.  
> > 
> > What is "closefb semantics"?  
> 
> closefb semantics = no forced plane/crtc disable, active plane keeps a
> drm_fb reference
> 
> rmfb semantics = forced plane/crtc disable, the drm_fb is guaranteed to be
> forcefully removed from the system

Very good.

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/20210922/b82ee589/attachment.sig>