vendor splash on internal screen persists

[AFwcxx]

Hey, great work on the script. Many many thanks.

I have installed via all-ways-egpu setup. Chosen method 2 and method 3. Reboot.
Everything works really great, I can play 4K video without stuttering and my glmark2 score went up from 789 to 9086!

However, I've noticed that the internal display seems to stuck or just kept showing the Lenovo vendor splash screen after logging in.

This happens when I disable the internal display from being used from the start. Meaning before rebooting. If I re-enabled back the internal display and then disable it after, the internal display is off as expected. But if I reboot, the problem is back.

Tell me what you need.

System:
Fedora Linux 40
Linux 6.10.6-200.fc40.x86_64
Wayland, Mutter, GNOME 46.4

Hardware:
Lenovo ThinkPad X1 Carbon Gen 9
11th Gen Intel® Core™ i7-1185G7 - CPU
Intel® Xe Graphics (TGL GT2) - Internal
AMD Radeon™ RX 7600M XT - eGPU

[ewagner12]

@AFwcxx

Here are some things I'd try based on my experience occasionally seeing the internal display "stuck" after rebooting:

• If you have splash in your kernel parameters remove it
• Try adding thunderbolt.host_reset=0 to your kernel parameters
• In UEFI/BIOS look for a setting like "Thunderbolt Pre-Boot Support" or "Thunderbolt Pre-Boot ACL" and if available turn it off
• I've found using the bootloader rEFInd does something that resets the display during bootup so the internal display always works correctly if booting Linux from rEFInd.

My system is fairly similar: Thinkpad T14s Gen 3 (AMD), Fedora 40, RX 6600 eGPU

[AFwcxx]

Alright, will test that out after work. I'll start with rEFInd first and see how it goes before modify grub parameters.

[AFwcxx]

Tried your recommendations.

• remove splash simply wouldn't show the vendor logo, but the internal monitor is still enabled because the back light is on.
• thunderbolt.host_reset=0 doesn't seem to work either. I've used both combination, with the splash and without.
• rEFInd seems to be creating different issue, for some reason using this boot manager sometimes the laptop restart twice. So i removed this and went back to stock boot manager.

The splash screen shows up and "stuck" after logging in. And the login screen actually happens on the internal display, not on my external display. I don't think it's got something to do with boot manager because that phase has long passed, but I can't and not sure how to confirm this.

[ewagner12]

Ok, if you're seeing it after logging in then that's a different issue to me where I see it starting at boot.

The only other info I have is that the splash screen typically operates on the fbcon so something with fbcon might be your issue here.

For reference I've attached my relevant dmesg output here. This is typical for AMD gpus where it switches from a generic framebuffer to amdgpudrmfb but this should happen during the initial part of the boot, long before logging in.

sudo dmesg |grep " fb"
[    1.050457] fbcon: Deferring console take-over
[    1.050459] simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device
[    4.714782] fbcon: amdgpudrmfb (fb0) is primary device
[    4.714785] fbcon: Deferring console take-over
[    4.714787] amdgpu 0000:33:00.0: [drm] fb0: amdgpudrmfb frame buffer device

[AFwcxx]

Seems to be quite similar to yours:

[    1.364710] fbcon: Deferring console take-over
[    1.364711] simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device
[    4.689105] fbcon: i915drmfb (fb0) is primary device
[    4.689106] fbcon: Deferring console take-over
[    4.689108] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
[    5.393306] fbcon: Deferring console take-over
[    5.393308] amdgpu 0000:54:00.0: [drm] fb1: amdgpudrmfb frame buffer device

[ewagner12]

Yeah that looks normal, and now that I think of it the frame buffer devices shouldn't really be affecting Gnome once you've logged in. Usually fbcon is just for virtual terminals.

Maybe you could try adding the environment variable MUTTER_DEBUG=kms and see if any errors show up in the journalctl logs?