This is a relatively short post, seeing as it isn’t a bug report but a general suggestion.
Currently, if you boot fedora on a high-dpi screen, the entire graphical boot (until you reach the GDM) is pixelated or blurry. My 13.5" screen has a resolution of 2256x1504, which is automatically scaled to 150% on Windows. It seems plymouth’s assets are scaled by default when I boot, but being rasters, they look pretty awful. I don’t know if it’s a 150% or 200%.
If it’s technologically feasible, making all of the plymouth assets vector graphics could solve this. As it stands, most first-time Fedora (and Linux) users will have a fairly unpolished experience from their first boot.
I’m fairly sure that vector graphics are not supported by Plymouth, but i could be wrong. It runs extremely early in the boot proces so it uses really basic image rendering options (bitmap).
Vector graphics are much more complex to display, they require a canvas and a rendering engine that translates vectors to the screen. This would not be something you would normally want to do at boot time.
Does this vary between Legacy and UEFI boots? I wouldn’t expect any scaling from POST to the log-in screen, but would expect it to be native and worst-case tiny with UEFI boot and reusing the firmware’s logo.
In Dell’s case, their boot logo can be scaled or non-scaled depending on a BIOS option, and that might carry-over to GRUB/Plymouth/Linux boot
@adonnen, of what I’ve recently ascertained, GRUB2 doesn’t appear to be capable of scaling whatsoever. Consequently, on 2560x1400px monitor, by default, it’s set to a low resolution equivalent to 200% scaling:
I presume that on a 4K monitor, it would be low enough resolution to be equivalent to 400%, with the problem compounding the higher than the resolution is set, unless it acquiesces eventually and merely renders everything tiny.
The monitor hardware can do scaling for any of its supported modes.
4k monitors will scale from 1920x1080 for example for a 200% scaling.
I tested 1024x768 on my setup that scaled well.
@barryascott, that’s probably dependent upon the monitor. My monitor is 2K, and I’m fairly confident that it’s crappy hardware barely has the clock speed to render my OSD.
Do you use your monitor’s scaling capability? If you do, I’m surprised, since I can’t imagine how it would communicate with GRUB that certain aspects of the GUI (the midsection) need to be removed when scaled.
@barryascott, when you scale anything, be it CLI, TUI, or GUI, 99% of the time, you have to completely redraw what has been rendered for it to be entirely viewable without scrolling. This is true in GRUB2’s case.
Merely increasing the scale of the output would cause it to render off the display, unless what has been rendered originally is incredibly padded to the centre. Even then, it would merely be a decrease in resolution via alternative means, rather than a genuine scale increase.
@barryascott, I see what you mean now. You’re correct that most monitors shall override the standard 1:1 aspect ratio, depending upon the resolution provided to them. They even appear to utilize interpolation to reduce pixelation (albeit at the expense of increased blur).
However, that’s exactly what @adonnen and I consider to be undesirable — we want the native resolution, correctly scaled, rather than upscaled.
On this note:
@hamrheadcorvette, have you verified that auto doesn’t set the value correctly for a HiDPI display? I ask per the undermentioned (which I’ve yet to evaluate):
If auto does not, then that’s worth a bug, for it would remediate this.
@barryascott, I’ve just not got enough information yet to determine whether Red Hat is setting auto incorrectly, or whether this is a matter of absent functionality within GRUB2.
