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. > > > - Forced fbdev restore on final close of all drm fd. This is only > > > prevented if there's a drm master left around (systemd-logind can keep > > > that instead of forcing the compositor to survive until the other has > > > taken over, which it needs to do anyway to prevent the drm master > > > handover from going sideways). This can be fixed by simply disabling > > > fbdev completely, which you really want to do anyway. Again it's uabi, > > > people will complain if we break this I think. > > > > Do you mean that it is not enough to leave the tty in KD_GRAPHICS mode > > to stop fbcon/fbdev from taking over? > > Nope. You need an open drm master. > > This is because we do actually support /dev/fb clients rendering in > KD_GRAPHICS mode for backwards compat with the fbdev subsystem. > > > Is it really fbdev on its own rather than fbcon (poking at fbdev) that > > will change the KMS state? > > > > That is, it's not enough to disable fbcon? > > fbcon doesn't disable fbdev, and the only way to block fbdev is to have a > drm master around. Thanks for pointing this out. > I guess we could try and make this smarter by creating some kind of weak > master status for fbdev, but only when either fbcon or fbdev is opened. > Maybe this would help? It would make sense to me if we wanted a bandaid, but do we? I don't know. > fbdev already keep track of this open count, so wouldn't be too onerous to > wire that up into drm_client. > > The problem there is then that not yet all drivers use the drm_client > stuff for fbdev emulation, so you'd need to either convert more, or hack > up a few more things to make this consistent. > > > > > Or am I confused because display servers do not tend to close the DRM > > > > device fd on switch-out but Plymouth does (too early)? > > > > > > Yeah, that stops both forced restore/disable from kicking in. > > > > Which "that"? > > that = open drm master. Open drm master alwasy wins agains fbdev/fbcon, > and with latest patches it's guaranteed to be race free. > > > > > If so, why can't Plymouth keep the device open longer and quit only > > > > when the hand-off is complete? Not quitting too early would be a > > > > prerequisite for any explicit hand-off protocol as well. > > > > > > With closefb semantics and fbdev disabled plymouth could quit early, > > > and things still work. > > > > What is "closefb semantics"? > > closefb semantics = no forced plane/crtc disable, active plane keeps a > drm_fb reference > > rmfb semantics = forced plane/crtc disable, the drm_fb is guaranteed to be > forcefully removed from the system Very good. Thanks, pq
Attachment:
pgpto5G94MrWF.pgp
Description: OpenPGP digital signature
