Handling DRM master transitions cooperatively

[Hans de Goede]

Hi,

On 9/8/21 9:36 AM, Pekka Paalanen 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.

I'm pretty sure that that is what is happening though.

But hopefully someone else can either confirm or deny this :)

> 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?
> 
> Or am I confused because display servers do not tend to close the DRM
> device fd on switch-out but Plymouth does (too early)?
> 
> 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.

plymouth is actually keeping the device open longer for exactly this
reason, the following happens:

1. plmouth starts
2. gdm starts and tells plymouth to "deactivate" which will stop it from
making drm ioctls and drop its drm master rights, while keeping the fb around
3. gdm waits for the greeter process to tell it that it has successfully
taken over the screen
4. gdm tells plymouth to quit

And something similar is happening on gdm greeter -> gnome user session
handover.

But we need the new ioctl at least on shutdown / reboot to avoid the
"fallback fb" (typically the EFI/BIOS setup fb which i915 inherited at boot)
showing for a brief moment when plymouth quits at shutdown / reboot and
there is nothing to hand-over the fb to in that case.

And the new ioctl would also make the above handover a lot simpler.

And we currently also have a flicker when going from user-session to
gdm on logout or from gdm/user-session to plymout on shutdown/reboot.

Basically we have quite a few transitions and currently only the
boot + login path is smooth and the rest needs more work, which either
requires a standardized handover method (instead of the current
hardcoded plymouth -> gdm stuff), or just allowing the FB to sit
around until the next drm-client installs its FB, which would be
much more KISS, so that has my preference.

And this KISS method will also work with transitions to a new
console-owner process which is not aware of any handover protocols,
as long as the old process uses the ioctl the transition will be
smooth. So e.g. gdm -> i3 on Xorg session will be smooth (1)

Regards,

Hans


1) I think this actually already is smooth because in this case gdm
just sleeps for 5 seconds before killing the greeter I believe, but
with the ioctl we could remove this hack