Handling DRM master transitions cooperatively

[Daniel Vetter]

On Thu, Sep 23, 2021 at 11:23:00AM +0300, Pekka Paalanen wrote:
> On Wed, 22 Sep 2021 11:21:16 +0200
> Hans de Goede <hdegoede at redhat.com> wrote:
> 
> > Hi,
> > 
> > On 9/22/21 10:56 AM, Pekka Paalanen wrote:
> > > 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.  
> > 
> > Hmm, I was thinking having a separate call to mark a FB to switch to
> > closefb semantics. But both plymouth (because of end of animation)
> > and GNOME (because a mostly empty gnome-shell needs to be rendered
> > to avoid leaking privacy sensitive info) will need to prepare a
> > special FB on exit anyways, so then an ADDFB2 flag would work fine.
> > 
> > I would be happy to work on the plymouth side of this, so that we
> > have at least one consumer of such a flag lined up for merging.
> 
> Right, but I'm thinking this from the other side: why would anyone
> deliberately *want* RmFB semantics on device close?
> 
> I can't think of any, and hence I would be inclined to assume that
> userspace would just switch to using closefb semantics for everything
> all the time.
> 
> Legacy userspace is one thing, but userspace that is updated to set
> closefb semantics will also be aware of what closefb means: it leaves
> the FBs up and CRTCs and planes enabled, if you leave them like that.
> So if they don't want that, they know they should not do that.
> 
> Asking in another way: why would the same program sometimes use RmFB
> semantics and sometimes closefb semantics? Even more so, why would one
> switch an FB from one to the other?
> 
> Hmm... to prevent leaking sensitive FBs on crash, perhaps? But you can
> do that decision at AddFB2 time, right? Maybe not, as you can't really
> force EGL to allocate a new buffer at will. Oh, but when EGL gives me a
> buffer that I know is safe to leave up, I also know that it is not up
> on any KMS plane (no front buffer rendering), so I can just RmFB and
> AddFB2 again. That's a bit of a detour though.
> 
> At least a separate ioctl on an FB would be more flexible than a flag
> at AddFB2.
> 
> Btw. what happens if I try to AddFB2 the same buffer twice?

drm_fb are just refcounted metadata containers. So you could have the same
underlying gem bo wrapped in 2 addfb, one with rmfb and one with closefb
semantics. Depending which one you're using on which crtc, the crtc might
be shut off or not when you close the drmfd.

It's a bit silly, but no problem for the kernel, so I think this is all
fine.

Real use-case of multiple drm_fb for the same underlying object is stuff
like XRGB vs ARGB or different modifiers (like with compression enabled or
compression metadata not up to date).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch