Hi, On 9/22/21 10:56 AM, Pekka Paalanen wrote: > On Tue, 14 Sep 2021 15:45:21 +0200 > Daniel Vetter <daniel@xxxxxxxx> 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@xxxxxxxx> wrote: >>> >>>> On Wed, Sep 8, 2021 at 9:36 AM Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote: >>>>> >>>>> On Tue, 7 Sep 2021 14:42:56 +0200 >>>>> Hans de Goede <hdegoede@xxxxxxxxxx> 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@xxxxxx> 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
