How do I prevent boot processes from clearing initial frame buffer?

prodego · 2024-11-07 07:56:37

I am trying to get the boot splash I built into my unified kernel image to remain on screen for more of the boot process. Currently the transition from the UEFI logo to the boot splash is completely seamless, but the boot splash shuts off a considerable amount of time before my login screen appears. I'm not expecting a perfectly seamless transition from splash to login, as nice as that would be, but there must be some way to at least hang onto it for a little longer while things that don't need the display are initializing. As far as I can tell based on the research I've done, some process is clearing the initial frame buffer set up by the kernel, which I've taken a few steps to address, but I'm not entirely sure if I've done everything I can. Here's a quick overview of all my different settings.

Splash built into the unified kernel image using /etc/mkinitcpio.d/linux.preset

default_uki="/boot/arch-linux.efi"
default_options="--splash=/etc/mkinitcpio.d/bootsplash.bmp"

KMS removed from mkinitcpio.conf hooks to prevent early modesetting by the GPU

HOOKS=(base systemd autodetect microcode modconf keyboard keymap consolefont block filesystems)

amdgpu.seamless=1 added to kernel parameters to smooth the transition to amdgpu when it inevitably does takeover, as well as various output silencing parameters

quiet
loglevel=3
systemd.show_status=auto
rd.udev.log_level=3
vt.global_cursor_default=0
amdgpu.seamless=1

I've also added the line

TTYVTDisallocate=no

to both systemd-vconsole-setup.service and getty@tty1.service

Can anyone think of anything else I should be changing/adding/trying? Thank you for taking the time to read.

V1del · 2024-11-07 10:05:31

You generally want early KMS (probably especially so if you want the seamless option to actually do anything), and you probably want to setup plymouth as well as a display manager if your really want this. But there's very little of general quantifiability here, this could well be an issue of your firmware, if it's an issue at all. https://wiki.archlinux.org/title/Plymou … transition

Try also explictly blacklisting simpledrm so that there's no inherent need of a handover: Add "initcall_blacklist=simpledrm_platform_driver_init" to the kernel parameters.

Last edited by V1del (2024-11-07 10:09:19)

Lone_Wolf · 2024-11-07 10:06:05

unified kernel image

What bootloader are you using ?

Please post the output of lspci -k, also as root run # journalctl -b | curl -F 'file=@-' 0x0.st and post the link it will output.

prodego · 2024-11-07 15:31:37

V1del wrote:

You generally want early KMS (probably especially so if you want the seamless option to actually do anything), and you probably want to setup plymouth as well as a display manager if your really want this. But there's very little of general quantifiability here, this could well be an issue of your firmware, if it's an issue at all. https://wiki.archlinux.org/title/Plymou … transition
Try also explictly blacklisting simpledrm so that there's no inherent need of a handover: Add "initcall_blacklist=simpledrm_platform_driver_init" to the kernel parameters.

Trying to use Plymouth with KMS and amdgpu modesetting enabled, I no longer get a seamless transition between my UEFI logo and my boot splash. Also, if I tell Plymouth to use the simpledrm driver, it shows up immediately but completely borks the resolution and looks like crap. Those options provide a significantly worse experience than what I'm currently doing, so if they are my only alternatives then I would rather stick to what I have configured already. Plymouth is notorious for not working right without specific hardware, settings, and specific display managers; so I've ruled it out as an option. I'm also not using a conventional display manager, rather auto logging into TTY1, auto starting Hyprland, and auto starting Hyprlock; which is why I said in my post that I'm not expecting a seamless transition between splash and login at all. Black listing simpledrm would cause the transition from UEFI to splash to no longer be seamless as the amdgpu driver is very large and takes a while to decompress, therefore that is not an option either.

prodego · 2024-11-07 15:35:59

Lone_Wolf wrote:

unified kernel image
What bootloader are you using ?
Please post the output of lspci -k, also as root run # journalctl -b | curl -F 'file=@-' 0x0.st and post the link it will output.

I am booting with an EFI stub and not using a boot loader at all.

Here is the output you requested:

~
$ lspci -k
00:00.0 Host bridge: Intel Corporation Device 4648 (rev 02)
        Subsystem: ASRock Incorporation Device 4648
00:01.0 PCI bridge: Intel Corporation 12th Gen Core Processor PCI Express x16 Controller #1 (rev 02)
        Subsystem: ASRock Incorporation Device 460d
        Kernel driver in use: pcieport
00:06.0 PCI bridge: Intel Corporation 12th Gen Core Processor PCI Express x4 Controller #0 (rev 02)
        Kernel driver in use: pcieport
00:14.0 USB controller: Intel Corporation Alder Lake-S PCH USB 3.2 Gen 2x2 XHCI Controller (rev 11)
        Subsystem: ASRock Incorporation Device 7ae0
        Kernel driver in use: xhci_hcd
        Kernel modules: xhci_pci
00:14.2 RAM memory: Intel Corporation Alder Lake-S PCH Shared SRAM (rev 11)
00:14.3 Network controller: Intel Corporation Alder Lake-S PCH CNVi WiFi (rev 11)
        Subsystem: Rivet Networks Device 1672
        Kernel driver in use: iwlwifi
        Kernel modules: iwlwifi
00:15.0 Serial bus controller: Intel Corporation Alder Lake-S PCH Serial IO I2C Controller #0 (rev 11)
        Subsystem: ASRock Incorporation Device 7acc
        Kernel driver in use: intel-lpss
        Kernel modules: intel_lpss_pci
00:16.0 Communication controller: Intel Corporation Alder Lake-S PCH HECI Controller #1 (rev 11)
        Subsystem: ASRock Incorporation Device 7ae8
        Kernel driver in use: mei_me
        Kernel modules: mei_me
00:1b.0 PCI bridge: Intel Corporation Alder Lake-S PCH PCI Express Root Port #21 (rev 11)
        Subsystem: ASRock Incorporation Device 7ac4
        Kernel driver in use: pcieport
00:1c.0 PCI bridge: Intel Corporation Alder Lake-S PCH PCI Express Root Port #3 (rev 11)
        Subsystem: ASRock Incorporation Device 7aba
        Kernel driver in use: pcieport
00:1c.3 PCI bridge: Intel Corporation Device 7abb (rev 11)
        Subsystem: ASRock Incorporation Device 7abb
        Kernel driver in use: pcieport
00:1f.0 ISA bridge: Intel Corporation Z690 Chipset LPC/eSPI Controller (rev 11)
        Subsystem: ASRock Incorporation Device 7a84
00:1f.4 SMBus: Intel Corporation Alder Lake-S PCH SMBus Controller (rev 11)
        Subsystem: ASRock Incorporation Device 7aa3
        Kernel driver in use: i801_smbus
        Kernel modules: i2c_i801
00:1f.5 Serial bus controller: Intel Corporation Alder Lake-S PCH SPI Controller (rev 11)
        Subsystem: ASRock Incorporation Device 7aa4
        Kernel driver in use: intel-spi
        Kernel modules: spi_intel_pci
01:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Upstream Port of PCI Express Switch (rev c1)
        Kernel driver in use: pcieport
02:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Downstream Port of PCI Express Switch
        Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Downstream Port of PCI Express Switch
        Kernel driver in use: pcieport
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700
XT] (rev c1)
        Subsystem: Sapphire Technology Limited Sapphire NITRO+ RX 5700 XT
        Kernel driver in use: amdgpu
        Kernel modules: amdgpu
03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI]
Navi 10 HDMI Audio
        Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 HDMI Audio
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel
04:00.0 Non-Volatile memory controller: Sandisk Corp WD Black SN850X NVMe SSD (rev 01)
        Subsystem: Sandisk Corp WD Black SN850X NVMe SSD
        Kernel driver in use: nvme
        Kernel modules: nvme
05:00.0 PCI bridge: Intel Corporation Device 1133 (rev 02)
        Subsystem: Intel Corporation Device 0000
        Kernel driver in use: pcieport
06:00.0 PCI bridge: Intel Corporation Device 1133 (rev 02)
        Subsystem: Intel Corporation Device 0000
        Kernel driver in use: pcieport
06:01.0 PCI bridge: Intel Corporation Device 1133 (rev 02)
        Subsystem: Intel Corporation Device 0000
        Kernel driver in use: pcieport
06:02.0 PCI bridge: Intel Corporation Device 1133 (rev 02)
        Subsystem: Intel Corporation Device 0000
        Kernel driver in use: pcieport
06:03.0 PCI bridge: Intel Corporation Device 1133 (rev 02)
        Subsystem: Intel Corporation Device 0000
        Kernel driver in use: pcieport
07:00.0 USB controller: Intel Corporation Device 1134
        Subsystem: Intel Corporation Device 0000
        Kernel driver in use: thunderbolt
        Kernel modules: thunderbolt
22:00.0 USB controller: Intel Corporation Device 1135
        Kernel driver in use: xhci_hcd
        Kernel modules: xhci_pci
3d:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
Killer E3000 2.5GbE Controller (rev 06)
        Subsystem: ASRock Incorporation Device 3000
        Kernel driver in use: r8169
        Kernel modules: r8169
~
$ sudo journalctl -b  | curl -F 'file=@-' 0x0.st
[sudo] password for ego:
http://0x0.st/XDQi.txt

V1del · 2024-11-07 16:15:39

FWIW so others can see what you're seeing, can you make a recording or so of the boot process? I doubt you're going to be able to exert that much control without going into quite complicated depths. Since the VT starting will blank you anyway the only other option I'd see of maybe having a chance would be to replace it with kmscon or so https://wiki.archlinux.org/title/KMSCON

Also something I'm noticing, you probably want to replace the consolefont and keymap hook with sd-vconsole, but I doubt it will have a notable effect on this.

Last edited by V1del (2024-11-07 16:20:28)

prodego · 2024-11-07 16:29:22

V1del wrote:

FWIW so others can see what you're seeing, can you make a recording or so of the boot process?

Yes, I can absolutely do this. Do I just upload it to Google Drive and share a link here or what? I don't see the option to add a video to my comments.

V1del wrote:

I doubt you're going to be able to exert that much control without going into quite complicated depths.

I had a feeling this was likely, and quite frankly what I've already done is a bit above my pay grade, but you gotta learn somehow. I figured by sharing this here, best case scenario I accomplish the goal I set and learn a whole lot more about my system in the process; or worst case I give other people with more experience an interesting problem to mess around with.

V1del wrote:

Since the VT starting will blank you anyway the only other option I'd see of maybe having a chance would be to replace it with kmscon or so https://wiki.archlinux.org/title/KMSCON

I have never heard of it before, I will most definitely look into it. Thank you.

V1del · 2024-11-07 16:35:17

Yeah a link to some external site would be nice

prodego · 2024-11-07 16:42:23

V1del wrote:

Yeah a link to some external site would be nice

Here you go

Arch Linux

#1 2024-11-07 07:56:37

How do I prevent boot processes from clearing initial frame buffer?

#2 2024-11-07 10:05:31

Re: How do I prevent boot processes from clearing initial frame buffer?

#3 2024-11-07 10:06:05

Re: How do I prevent boot processes from clearing initial frame buffer?

#4 2024-11-07 15:31:37

Re: How do I prevent boot processes from clearing initial frame buffer?

#5 2024-11-07 15:35:59

Re: How do I prevent boot processes from clearing initial frame buffer?

#6 2024-11-07 16:15:39

Re: How do I prevent boot processes from clearing initial frame buffer?

#7 2024-11-07 16:29:22

Re: How do I prevent boot processes from clearing initial frame buffer?

#8 2024-11-07 16:35:17

Re: How do I prevent boot processes from clearing initial frame buffer?

#9 2024-11-07 16:42:23

Re: How do I prevent boot processes from clearing initial frame buffer?

Board footer