On Thu, Sep 23, 2021 at 11:23:00AM +0300, Pekka Paalanen wrote: > On Wed, 22 Sep 2021 11:21:16 +0200 > Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > > > 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. > > 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? drm_fb are just refcounted metadata containers. So you could have the same underlying gem bo wrapped in 2 addfb, one with rmfb and one with closefb semantics. Depending which one you're using on which crtc, the crtc might be shut off or not when you close the drmfd. It's a bit silly, but no problem for the kernel, so I think this is all fine. Real use-case of multiple drm_fb for the same underlying object is stuff like XRGB vs ARGB or different modifiers (like with compression enabled or compression metadata not up to date). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
