Re: Handling DRM master transitions cooperatively

[Pekka Paalanen <ppaalanen@gmail.com>]

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

On Wed, 22 Sep 2021 11:21:16 +0200
Hans de Goede <hdegoede@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@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@ffwll.ch> wrote:
> >>>     
> >>>> On Wed, Sep 8, 2021 at 9:36 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:    
> >>>>>
> >>>>> On Tue, 7 Sep 2021 14:42:56 +0200
> >>>>> Hans de Goede <hdegoede@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@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?


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]