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.
Regards,
Hans