Re: Handling DRM master transitions cooperatively

[Hans de Goede <hdegoede@redhat.com>]

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.

Regards,

Hans