Handling DRM master transitions cooperatively

[Hans de Goede]

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.

> - Xorg doing something (e.g. resetting instead of inheriting KMS state)
> 
> - Something missed in the hand-off sequence which allows fbcon to
>   momentarily take over between Plymouth and Xorg. This would need to
>   be fixed between Plymouth and Xorg.
> 
> - Maybe systemd-logind does something odd to the KMS device? It has
>   pretty wild code there. Or maybe it causes fbcon to take over.
> 
> What is the new ioctl you referred to?

It is an ioctl to mark a FB to not have it auto-removed on device-close,
instead leaving it in place until some some kernel/userspace client
actively installs another FB. This was proposed by Rob Clark quite
a while ago, but it never got anywhere because of lack of userspace
actually interested in using it.

I've been thinking about reviving Rob's patch, since at least for
plymouth this would be pretty useful to have.

Regards,

Hans