On boot, the screen resolution seems to fluctuate a couple times, starting with a 800x600-ish resolution, then getting a bit better until you get in the display manager. See screenshots that I will post right after. Three screenshots will be posted: 1- Image right after the kernel loads (Often is the only screen you see until the DM loads) 2- Image that sometimes shows right before the DM loads (#1 would still show, but it switches midway through loading) 3- How it looks like on shutdown, on normal resolution Reproducible: Always
Created attachment 2077803 [details] #1 (Right after kernel boots)
Created attachment 2077804 [details] #2 (Sometimes, before the DM loads in)
Created attachment 2077805 [details] #3 (Shutdown)
Proposed as a Blocker for 42-beta by Fedora user ngompa using the blocker tracking app because: The boot splash looks pretty broken in some configurations, which would leave a very bad first impression for people trying Fedora.
Steve, it's quite important to mention what GPU you have (and which driver you use, if there are multiple options). Also the screen resolution is a good info.
(In reply to Kamil Páral from comment #5) > Steve, it's quite important to mention what GPU you have (and which driver > you use, if there are multiple options). Also the screen resolution is a > good info. Oh sorry. Fair enough! AMD Radeon 7900XT I believe my laptop with an AMD APU (Rembrandt, I don't remember exactly which APU off-hand) I believe has the exact same issue too.
This may be poorly interacting with the combination of https://fedoraproject.org/wiki/Changes/PlymouthUseSimpledrm and https://src.fedoraproject.org/rpms/plymouth/blob/rawhide/f/plymouth-24.004.60-device-scale-fixes.patch
With plymouth-24.004.60-17.fc42 I'm experiencing awful display scaling during boot using Ryzen 7950X integrated graphics and a 27-inch 1440p monitor. The UI is huge and blurry. Surely a 27-inch monitor should not require any scaling. I suggest removing the device scale fixes patch. Fortunately, this only affects Fedora 42 and presumably rawhide, so it's not an emergency.
I don't think it's so much the "combination of" those two things as it is simply the PlymouthUseSimpledrm change. I don't see anything wrong with the device-scale-fixes patch, and it would not change the scaling factor chosen for a 1440p 27" monitor (both before and after that patch, the answer would be 1). The Change description, I think, actually specifically calls out the issues we're seeing here: "Using simpledrm may lead to some changes in the splash appearance: 1. With simpledrm plymouth will fallback to heuristics on the resolution instead of DPI info to decide whether or not to use hidpi (e.g. 2x size) rendering. This may result in a different scaling factor for some setups, but I do not expect this really to be an issue. 2. On old UEFI systems the efifb will not come up in native mode, but rather in 800x600 or 1024x768. This will lead to a pretty significant discontinuity in the boot experience when switching from say 800x600 to 1920x1080 while plymouth was already showing the spinner at 800x600. 3. On systems where a full modeset is done the monitor going briefly black from the modeset will move from being just before plymouth starts to the switch from simpledrm drm to the real driver." it sounds to me like we're seeing one, two or all three of those issues here. I think Michael is running into point 1. The "heuristics on the resolution" referred to in point 1 are...not complicated heuristics. Ahem. This is the `guess` path in the code. Before device-scale-fixes.patch, it looked like this: if (height < HIDPI_MIN_HEIGHT) return 1; if (guess) return (width >= HIDPI_MIN_WIDTH) ? 2 : 1; After the patch, it looks like this: if (guess) { return (width >= HIDPI_MIN_WIDTH && height >= HIDPI_MIN_HEIGHT) ? 2 : 1; } 'width' and 'height' here are the display resolution in pixels (so, 2560 and 1440 in Michael's case). If the height >= 1200 and the width >= 2560 - those are the HIDPI_MIN_HEIGHT and HIDPI_MIN_WIDTH values - and we're on the "guess" path, we short-circuit the rest of the function and just return 2. So *any time* the resolution is 2560x1200 or greater, we will use a scaling factor of 2. This "heuristic" just doesn't really account for large monitors at non-high DPIs. This would happen with or without the device-scale-fixes patch. I think I'd disagree with the Change's evaluation that "This may result in a different scaling factor for some setups, but I do not expect this really to be an issue", given the relative popularity of monitor's like Michael's - 27" at 1440p is 108dpi, and so will look pretty weird at a scaling factor of 2 - and 32" 4k monitors, which are ~137dpi. Those look best at 125% scaling, but since that's not an option here, 1 is a much better choice for them than 2, but we are going to wind up using 2 on all of them. There *is* one functional change caused by the patch here - before the patch we return 1 if height is lower than HIDPI_MIN_HEIGHT *even if we're not on the guess path*, after the patch we do not - but that doesn't seem relevant here. It sounds a lot like Steve is experiencing point 2. The description there sounds awfully similar to what Steve wrote above.
-3 in https://pagure.io/fedora-qa/blocker-review/issue/1768 , marking rejected Beta blocker.
Since 2560x1440 is a very standard non-hidpi display resolution, I'd say it should surely never be scaled. If the heuristics scale at this resolution, the heuristics are bad.
I'm not sure we can ever win the 'guess whether this display is hidpi based solely on the resolution' game. Yep, 27" 2560x1440 monitors (which are not hidpi) are very common...but 2560x1440 is *also* a fairly common native resolution for 15-17" gaming laptops. That's between 172dpi and 195dpi, i.e. probably *should* be scaled. As long as we don't have the display's physical size, or any other information we could at least use to guess - do we at least know if the display is a laptop panel or not? that might help - we're never going to be able to get this right reliably. So this sort of becomes a question of "is the benefit of avoiding the fallback to "ugly text splashscreen" on some systems greater than the cost of probably getting the scaling factor wrong quite often?", I think.
First of all Adam, thank you for your analysis. I agree that Steven (original bug reporter) is hitting likely hitting 2. from the "Using simpledrm may lead to some changes in the splash appearance:" list in https://fedoraproject.org/wiki/Changes/PlymouthUseSimpledrm#Detailed_Description : "2. On old UEFI systems the efifb will not come up in native mode, but rather in 800x600 or 1024x768. This will lead to a pretty significant discontinuity in the boot experience when switching from say 800x600 to 1920x1080 while plymouth was already showing the spinner at 800x600." Steven, is your system perhaps setup to always show the grub menu, for e.g. multiboot purposes ? I would expect a modern system like what you seem to have to initialize the panel in its native mode not 800x600, but sometimes showing messages in EFI's text-console like the grub menu will cause a switch to 800x600. Note I'm not claiming this is not an issue just trying to make sense of why this is happening on your modern system. I would expected this to maybe happen on a few Sandy Bridge systems (e.g. i5-2600 CPU, somewhat old) with 1st generation UEFI firmware, but not on something recent.
(In reply to Hans de Goede from comment #13) > First of all Adam, thank you for your analysis. > > I agree that Steven (original bug reporter) is hitting likely hitting 2. > from the "Using simpledrm may lead to some changes in the splash > appearance:" list in > https://fedoraproject.org/wiki/Changes/ > PlymouthUseSimpledrm#Detailed_Description : > > "2. On old UEFI systems the efifb will not come up in native mode, but > rather in 800x600 or 1024x768. This will lead to a pretty significant > discontinuity in the boot experience when switching from say 800x600 to > 1920x1080 while plymouth was already showing the spinner at 800x600." > > Steven, is your system perhaps setup to always show the grub menu, for e.g. > multiboot purposes ? I would expect a modern system like what you seem to > have to initialize the panel in its native mode not 800x600, but sometimes > showing messages in EFI's text-console like the grub menu will cause a > switch to 800x600. > > Note I'm not claiming this is not an issue just trying to make sense of why > this is happening on your modern system. I would expected this to maybe > happen on a few Sandy Bridge systems (e.g. i5-2600 CPU, somewhat old) with > 1st generation UEFI firmware, but not on something recent. This system does not have multiboot. My laptop does though, but not my main desktop. My main desktop is also a R9 7900xt (AM5) so not very old :) And no, it's not set to show the grub menu, though I think I can make it show by mashing Escape on boot?
Sorry I meant to say R9 7900x, AMD and their naming schemes...
(In reply to Adam Williamson from comment #12) > I'm not sure we can ever win the 'guess whether this display is hidpi based > solely on the resolution' game. Yep, 27" 2560x1440 monitors (which are not > hidpi) are very common...but 2560x1440 is *also* a fairly common native > resolution for 15-17" gaming laptops. That's between 172dpi and 195dpi, i.e. > probably *should* be scaled. Well yeah, if you want to do this properly you obviously have to consider screen size. But since plymouth is trying to do it without screen size, I suggest considering the most common monitor resolutions: 1920x1080 (standard size is 24 inches, definitely not hidpi), 2560x1440 (standard size is 27 inches, definitely not hidpi), 3840x2160 (standard size is 27 or 32 inches, either way it's definitely hidpi). Maybe some 1440p laptops really do want to be scaled, but failing to scale is surely less bad than scaling improperly.
I also agree with Adam's analysis that Michael's problem is simply caused by enabling the use of simpledrm by plymouth by default, which in turn results in using heuristics to guess the scaling, since we don't have the physical dimensions at this point during boot and thus no DPI info. Michael, to confirm can you run: sudo grubby --update-kernel=ALL --args="plymouth.use-simpledrm=0" this should revert to the old behavior. Since I mostly work on laptops and tablets these 27" 2560x1440 monitors were not on my radar. I chose the original heuristic cutoff of 1200 for the height to get 2x scaling on 10" tablets like e.g. the Microsoft Surface Go models with their 1800x1200 / 1920x1280 resolutions at 10" / 10.5" (see: https://surfacetip.com/surface-display-comparison/ ). These devices have around 200dpi for which e.g. GNOME will default to 150% scaling. So for plymouth's 1x or 2x scaling we could go either way. I just gave things a try on my own Surface Go and plymouth still looks ok there when using 1x scaling instead of 2x scaling. So since 10" is about the smallest size which we support, I guess we could change the heuristics to make 2560x1440 still use 1x and only use 2x scaling on 2736x1536 and higher. I have picked 2736x1536 as the new cut off to e.g. use 2x scaling on the Surface Pro 4 and later which are all 267 DPI. This should also pick the correct values for the standard monitor resolutions list Michael just posted. Note the reason why I've added https://src.fedoraproject.org/rpms/plymouth/blob/rawhide/f/plymouth-24.004.60-device-scale-fixes.patch to Fedora's plymouth is because these changes are already upstream and I did not want to scaling choices to change when rebasing to the latest upstream code sometime in the near future.
(In reply to Hans de Goede from comment #17) > Michael, to confirm can you run: > > sudo grubby --update-kernel=ALL --args="plymouth.use-simpledrm=0" FYI, running this on my local computer reverted the boot back to F41- behavior (Which is fine and looks great).
(In reply to Steve Cossette from comment #18) > (In reply to Hans de Goede from comment #17) > > Michael, to confirm can you run: > > > > sudo grubby --update-kernel=ALL --args="plymouth.use-simpledrm=0" > > FYI, running this on my local computer reverted the boot back to F41- > behavior (Which is fine and looks great). Ok, that is good to know. Do you still get the "extra large" AORUS 800x600 mode logo in this case? or does not using simpledrm somehow result in only the small AORUS logo (at presumably the native's LCD panel resolution) showing during a (re)boot ?
(In reply to Hans de Goede from comment #19) > (In reply to Steve Cossette from comment #18) > > (In reply to Hans de Goede from comment #17) > > > Michael, to confirm can you run: > > > > > > sudo grubby --update-kernel=ALL --args="plymouth.use-simpledrm=0" > > > > FYI, running this on my local computer reverted the boot back to F41- > > behavior (Which is fine and looks great). > > Ok, that is good to know. Do you still get the "extra large" AORUS 800x600 > mode logo in this case? or does not using simpledrm somehow result in only > the small AORUS logo (at presumably the native's LCD panel resolution) > showing during a (re)boot ? Well, it's still showing the 800x600 aorus logo on the uefi screen, but nothing you can do about that. I swear though that on F41, it was a seamless transition and it never used that 800x600 resolution at all. Maybe the uefi adapts? .....but that's beside the point. The resolution is now much better, thanks!
> Well, it's still showing the 800x600 aorus logo on the uefi screen, but nothing you can do about that. That is the real culprit here though. I was thinking I could add some extra code to plymouth to skip simpledrm if the resolution is 800x600 but that is a bit meh. Are you seeing any text messages flash by during boot before the kernel loads ? I suspect something is printing some text during boot and that is causing this.
(In reply to Hans de Goede from comment #21) > > Well, it's still showing the 800x600 aorus logo on the uefi screen, but nothing you can do about that. > > That is the real culprit here though. I was thinking I could add some extra > code to plymouth to skip simpledrm if the resolution is 800x600 but that is > a bit meh. Are you seeing any text messages flash by during boot before the > kernel loads ? I suspect something is printing some text during boot and > that is causing this. Nope. It shows the bios screen with F12/F2/... then *screen resolution change* Fedora logo in normal, good resolution.
(In reply to Steve Cossette from comment #18) > FYI, running this on my local computer reverted the boot back to F41- > behavior (Which is fine and looks great). Same.
I just checked on my laptop. Do keep in mind I do have dual boot on that computer, so it does show the grub menu. But it goes Good resolution (uefi) -> Grub menu -> Black Screen -> Bad resolution (plymouth, initial) -> Good resolution (Plymouth, before sddm) -> sddm
Ok, so I'm going to work on: 1. Tweak the hidpi guess to only trigger for resolutions >= 2736x1536 2. Make plymouth not use simpledrm if the simpledrm provided resolution is 800x600 or 640x480 Steve, I want to verify that the EFI framebuffer used by simpledrm indeed is 800x600 in your case. Can you do the following please for both your desktop and laptop: sudo grubby --update-kernel=ALL --remove-args="plymouth.use-simpledrm=0" sudo grubby --update-kernel=ALL --args="plymouth.debug=stream:/dev/null" and then reboot and collect /var/log/plymouth-debug.log and attach it here ? (twice once for both machines) Note if you use disk-encryption with a passphrase please make the attachment private. Your passphrase is not in the log, but people can glean information about the length of your passphrase from the logs.
(In reply to Michael Catanzaro from comment #16) > Maybe some 1440p laptops really do want to be scaled, but failing to scale > is surely less bad than scaling improperly. *If* plymouth scaling also affects the font size (when you press Esc during boot), then I disagree. I have a 2560x1600 16" laptop and the default font is very difficult to read. [1] If there was some boot problem, it would be very inconvenient to debug it with such a small text. Being able to read an error message trumps the prettiness of the spinner, in my eyes. If we don't know the screen size during boot, I think we should rather aim for the safer scaling factor. [1] I had to set FONT="latarcyrheb-sun32" (which is twice the size than the default one, I believe) in /etc/vconsole.conf to make it readable.
Created attachment 2078071 [details] Plymouth Log (Desktop) There ya go, this is for the desktop. I'll do the laptop one later today.
> 3840x2160 (standard size is 27 or 32 inches, either way it's definitely hidpi) It's not, though. I'm typing this on a 32", 3840x2160 monitor. That's 137dpi. The 'natural' scaling factor for it is 1.25x, but if I can only choose 1x or 2x, 1x is *definitely* better than 2x. That's what I mean when I say we're never going to win this game...
A random thought occurs to me here. If the thing we're trying to avoid is the eight-second fallback *to an ugly text display*, can we not have a hybrid design where we try the native driver then fall back after eight seconds *to simpledrm*, if possible?
> Created attachment 2078071 [details] > Plymouth Log (Desktop) > > There ya go, this is for the desktop. I'll do the laptop one later today. Steve, thank you for the logs. The EFI framebuffer on your desktop is actually running at 1024x768.
Created attachment 2078207 [details] Plymouth Logs (Laptop) This is for the laptop. That one does have multiboot.
(In reply to Adam Williamson from comment #28) > > 3840x2160 (standard size is 27 or 32 inches, either way it's definitely hidpi) > > It's not, though. I'm typing this on a 32", 3840x2160 monitor. That's > 137dpi. The 'natural' scaling factor for it is 1.25x, but if I can only > choose 1x or 2x, 1x is *definitely* better than 2x. That's what I mean when > I say we're never going to win this game... Adam, I hear you (and I agree) when you say "we're never going to win this game", but something to keep in mind here is that we are talking about just the boot-splash, not the final UI. With a 32" 3840x2160 with x2 scaling the boot splash will look the same as on a 32" 1920x1080 monitor, like the TV in my living room. Also proportionally the size of e.g. the Fedora logo vs the width of the monitor will be the same as with any other 1920x1080 monitor. I agree we can never get the heuristics perfect, but the questions is can we get them good enough for the bootsplash ? The plymouth change is not just about fixing the text fallback after 8 seconds it is also intended as a first step to potentially moving the GPU drivers out of the initrd fully relying on the firmware framebuffer for the boot splash in the initrd. This is desirable because GPU drivers and especially their firmware is getting bigger and bigger and we want to move to a pre-generated generic desktop initrd which can be build and signed on the buildserver for secureboot and/or measured boot so that we can possibly use the TPM for diskencryption. Also see: https://hansdegoede.dreamwidth.org/28291.html So I would like to try and get this working. Reverting to the F41 behavior is as simple as dropping these 2 lines from the spec file: ``` # Use simpledrm /dev/dri/card# by default echo UseSimpledrm=1 >> src/plymouthd.defaults ``` and users can also override this both from the kernel commandline and from /etc/plymouth/plymouthd.conf. Or users can keep using simpledrm but force a specific hiDPI scale-factor (same factor will apply to all displays), also from both the cmdline as well as the configfile. I'll add some notes about this to the Release Notes section of the change wiki page. Also thank you all for your feedback on this. This discussion is exactly why I filed a change-proposal for this even do it is just a change to the config of a single package.
(In reply to Adam Williamson from comment #29) > A random thought occurs to me here. If the thing we're trying to avoid is > the eight-second fallback *to an ugly text display*, can we not have a > hybrid design where we try the native driver then fall back after eight > seconds *to simpledrm*, if possible? plymouth will already try to use simpledrm after the timeout, the problem is that often the GPU driver is only a tad to slow and it has already unbound the simpledrm driver, removing the simpledrm /dev/dri/card# but it is still busy probing connectors so its own /dev/dri/card# is not ready yet. I guess I could add some code to detect we hit that condition and then wait for the real GPU driver a bit longer, but that is going to be tricky, e.g. how long should we wait ? And 8 seconds without any feedback to the user already is a long time. I would rather try to find some other solution then try to workaround this race. E.g. I'm pretty sure that Windows does use some form of firmware framebuffer to show its boot spinner all the way until it shows its loginscreen or directly shows the desktop. If Windows can get this to work then so should we.
Ok, I've just started a new plymouth build with the following changelog: - Update simpledrm hiDPI scaling heuristics (rhbz#2347519) - Ignore simpledrm when EFI fb is running at 1024x768/800x600 (rhbz#2347519) - Update spinner theme to match latest libadwaita spinner (rhbz#2325399) This should fix: 1. The original problem reported by Steve on his desktop where plymouth was using the low-resolution 1024x768 EFI framebuffer which looked ugly. 2. The problems with plymouth using 2x scaling on 1440p monitors which was too large 3. Bug 2325399 which was about the spinner theme being out of date wrt Adwaita (backported fix from upstream) This hopefully resolves most issues brought up here in this bug.
FEDORA-2025-ccd133bc29 (plymouth-24.004.60-18.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-ccd133bc29
FEDORA-2025-8d59e6ce13 (plymouth-24.004.60-18.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-8d59e6ce13
FEDORA-2025-ccd133bc29 (plymouth-24.004.60-18.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-8d59e6ce13 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-8d59e6ce13` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-8d59e6ce13 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I went ahead and updated this morning and saw there was the update for plymouth in it. So, I rebooted and checked what it looked like. Looks great now! I noticed the spinning animation seems... different now. Maybe it's smaller? I don't hate it though, looks great!
(In reply to Steve Cossette from comment #39) > I went ahead and updated this morning and saw there was the update for > plymouth in it. So, I rebooted and checked what it looked like. Great, thank you for testing. Did you remove plymouth.use-simpledrm from your kernel commandline while testing? Or maybe you never added this permanently ? > Looks great now! I noticed the spinning animation seems... different now. > Maybe it's smaller? I don't hate it though, looks great! The spinner change is intentional, the old spinner matched the old Adwaita theme spinner and his now been updated to match the new updated Adwaita spinner.
(In reply to Hans de Goede from comment #40) > (In reply to Steve Cossette from comment #39) > > I went ahead and updated this morning and saw there was the update for > > plymouth in it. So, I rebooted and checked what it looked like. > > Great, thank you for testing. Did you remove plymouth.use-simpledrm from > your kernel commandline while testing? Or maybe you never added this > permanently ? Yeah I removed that shortly after. > > Looks great now! I noticed the spinning animation seems... different now. > > Maybe it's smaller? I don't hate it though, looks great! > > The spinner change is intentional, the old spinner matched the old Adwaita > theme spinner and his now been updated to match the new updated Adwaita > spinner. Great!
I've added a release-notes section to the Fedora change page now which documents how to switch back to the old behavior of not using simpledrm KMS devices and/or how to force a specific hiDPI scaling factor: https://fedoraproject.org/wiki/Changes/PlymouthUseSimpledrm#Release_Notes
FEDORA-2025-8d59e6ce13 (plymouth-24.004.60-18.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.