Plymouth flicker-free shutdown side-effect

[Hans de Goede]

Hello João,

On 01-01-19 02:08, João Paulo Rechi Vita wrote:
> Hello Hans,
> 
> Firstly, thanks for your flicker-free boot work, it is really nice to
> finally see a completely smooth boot process on the Linux desktop.
> 
> I've been integrating your work on Endless, where we do not want to
> show the BGRT graphics for the entirety of the boot process, but use a
> fully Endless-branded splash animation instead.

Interesting have you seen my recent work on integration the BGRT
with plymouth for reporting some sort of process:
https://hansdegoede.livejournal.com/19673.html

This is still under development and doing a fade-over into something
without the vendor branding has been considered, can you (privately)
share a video of what your boot looks like? And have you added code
to plymouth to do a fade-over in this case, or is the transition
from the BGRT screen to the endless branded screen done in a single
frame update?

> With your kernel
> changes to have fbcon defer its setup, have efifb copy the BGRT
> graphics to the framebuffer, the flicker-free changes to grub, shim
> and Plymouth, and and passing i915.fastboot=1 on the kernel command
> line, I'm able to have a 100% flicker-free boot process.
> 
> That being said these also bring a side-effect that makes the shutdown
> process very unpleasant. After X is shut down the BGRT logo will be
> displayed for a moment, then the shutdown splash will be shown, and
> finally the BGRT logo will be displayed for a moment again before the
> machine powers off. Before the flicker-free changes, this would be a
> clblack text console with a blinking cursor on the first character
> position, but with these changes the console was never setup and the
> BGRT logo is still on the TTY frame buffer.

Right, so the problem here is that the i915 driver needs *some* framebuffer
to scanout, so here is what is happening:

Phase 1: Firmware / grub: Firmware displays its splash, grub leaves everything alone

Phase 2: EFIFB: EFIFB rebuilds firmware splash from BGRT ACPI table in case something hosed it,
also some firmwares do not show the BGRT themselves at all (also dependend on fastboot settings)

Phase 3: i915 driver takes over, with a recent kernel it will re-use the framebuffer set
up by the firmware (GOP) and it will preserve its contents. This framebuffer is kept around
by i915 as a fallback framebuffer

Phase 4: Plymouth loads installs its own framebuffer

Phase 5: Plymouth - gdm (*) transition step 1, plymouth is told to stop, but not exit before
gdm starts, on stop plymouth drops its master rights, but its framebuffer is still in
use and will be used until another one is installed; *or* plymouth closed the drm fd
(or exits).

Phase 6: Plymouth - gdm transition step 2, gdm installs its own framebuffer then
tell plymouth it is ok to quit now.

Phase 7: gdm -> user session transition. This works the same as plymouth -> gdm, gdm
drops its master rights, but keeps the framebuffer around to allow for a smooth transition
this is currently done based on a timeout since user-sessions have no way to signal gdm
that they have installed their own framebuffer.

Phase 8: User session runs using its own framebuffer(s)

Phase 9: Shutdown step 1: The user session exits, without doing anything to guarantee a
smooth transition. The i915 driver now looses the framebuffer it is scanning out and
falls back to the framebuffer it inherited from the firmware/GOP, which contains the BGRT
logo. This is the first BGRT flash you are seeing

Phase 10: Shutdown step 2: plymouth takes over, installs its own framebuffer.

Phase 11: Shutdown complete, ready to reboot. Plymouth gets killed just before, releasing
its framebuffer, i915 again goes to the fallback framebuffer (it has to scan out something)
this is the second BGRT flash you are seeing

I hope this helps explain what you are seeing. There is another issue, at least when
using gdm from GNOME-3.30 or newer. The latest GDM kills the greeter-session when the
user-session has started to free up about 300M of RAM. But if the user now logs out,
then gdm needs some time to restart leading to an experience similar to the shutdown
(on the switch to VT1 the BGRT logo will show until the greeter starts).

This is why for now I've chosen to integrate the BGRT logo into the plymouth theme,
then all these transitions become smooth since on shutdown we go:
user-fb -> fallback-fb -> plymouth-fb -> fallback-fb
and both the fallback-fb and plymouth-fb have the BGRT on them so the transition
looks smooth.  Also keeping the BGRT logo around until just before gdm starts
makes it showing again when loging out seem normal.

Note that using the BGRT is a workaround and you could dd the endless splash screen
to the fb somewhere during boot to do a similar workaround for your problem.

But there is a proper way to fix this, which is to allow applications to
unref a framebuffer rather then removing it. In this case the kernel would no
longer accept the framebuffer handle from userspace (and untie it from the drm fd)
but keep it around until a new framebuffer is installed. This would also avoid the
need for the complex stop plymouth, wait for gdm to install new fb, exit plymouth
shenanigans we need to do atm.

Rob Clark has written a patch for this, but it did not get merged since there were
no immediate userspace uses for it back when this was first submitted:

https://www.spinics.net/lists/dri-devel/msg140912.html

I believe now would be a good time to dust-off this patch and to teach mutter
to call the unref ioctl on the last shown framebuffer when it exits, so that
that stays around until something else installs a new framebuffer.

Regards,

Hans



*) I know Endless is (was?) not using gdm, not sure how this works for you