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@redhat.com wrote:
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.
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