grub2 boot: displayed resolution does NOT match that set in gfx_mode

archuser_9999 · 2020-04-20 13:04:32

Please read carefully, because I am NOT here asking for basic instructions, or "how do I?" this is a specific problem related to the loading screen in grub2 as it appears via my monitor.

Like many I run older hardware. As such I'm stuck with BIOS/mft partition and have no access to the UEFI boot loaders. So, while boot screen appearance is a small thing, I do the best I can with it. As such I've never really thought too hard about odd visual effects during boot all the while the system boots correctly. From the wiki I've read and found maximum resolution supported, and have set

GFX_MODE=1280x1024

Booting in text mode everything behaves as expected. Then I got around to a bit of styling.

Using the Archlinux theme designed for a different mode I set my config at

GFX_MODE=1024x768

(exactly as the theme suggests). The theme appears slightly misaligned and the progress circle appears oval. I wondered why. I thought about editing the theme. True that my monitor is a more up to date 1920x1080 affair, but didn't think this should be a factor.

And then I decided to instead edit one of the more modern 'flat' themes simply by way of changing a few colours. This is a theme designed to include UEFI boot and thus its included background image was intended to fill a widescreen. No problem, I thought, I'll edit that, fill it with solid colour, and it'll just fill the default 1240x1024 area it can render in tty. However upon boot I noticed that while background was now filled with this colour, the size and shape of it bears no resemblance to a 1280x1024 area. Coupled with the above observation regarding circles, I realise that however I set GFX_MODE, whatever is shown appears to get stretched horizontally, as if the screen is not using a 1:1 pixel ratio.

So I'm just asking if anyone knows whether this curious effect is anything to do with `grub2` and settings, or whether this really is distortion caused by the monitor and in which case there's nothing I can do about it?

headkase · 2020-04-20 13:29:18

This is recollection through the workings so the details to do so are likely different.

What is probably happening is that your monitor is receiving a "4:3 signal" and displaying it in a "16:9 mode".

These are the standards that have evolved, we started with 4:3 or 5:4 modes, went through odd ones like 16:10, settled on 16:9 and now even 21:9 and wider are appearing.

So, monitors started off roughly square and have become wider over time.

Where this matters is that you have a BIOS boot sequence. BIOS modes, unless you're lucky with some VESA extensions, are almost exclusively 4:3 modes.

Now, what you can do about it. The signal is 4:3 and may not be able to be changed because of BIOS limitations. So, experiment to find the highest resolution that does display with your specific BIOS. Now, go to your monitor settings and you are looking for "stretch" "wide" "normal" "zoom" and maybe other labels. The effect of a label you are trying to find is for the monitor to display the signal in "pillar box". That means your aspect for the image will be more correct, circles will display as circles, and you should get black regions on the left and right of the screen which can't be drawn to but are there to make the centre appear correctly.

Years back when I was on Windows I had a program that extended your graphics hardware with new VESA modes. It allowed you to use resolutions that weren't available with just the manufacturer drivers. There likely is something similar with Linux and hopefully someone can drop a technical pointer for that.

archuser_9999 · 2020-04-20 13:40:35

Thanks, that's really constructive.

You've rather confirmed what I was suspecting i.e. that this is more to do with the devices involved than anything directly with configuring grub2.

The only relevant setting I can change on my monitor is "input type" which I've now set to "auto" but while it didn't make any difference did raise another related question. Perhaps the use of HDMI to connect graphics output to monitor has also nobbled vesa's ability to draw the screen? Just curious.

Seems like there's not much I can do about it, although it would be nice to have things properly rendered. I have been looking around for extensions etc. but thus far no joy.

I did read somewhere that removing the nvidia driver and booting with Nouveau does allow the higher resolutions. In my case there's only one further up

GFX_MODE=1600x1200

which doesn't quite seem right, since the vertical resolution would be higher than this monitor's native one... but that said, there's nothing going on with this machine that means the Nvidia GTX-580 is really helping me with, especially since I'm using a stacking window manager, and I'm not trying to play games on it.

I might just try flipping back to Nouveau and see what happens?

V1del · 2020-04-20 15:43:07

The kernel driver should not really factor in on the GRUB screen (conversely the GRUB graphics mode can have a factor on the kernel mode display, but it doesn't read like that's what you're struggling with).

archuser_9999 · 2020-04-20 16:14:45

V1del wrote:

The kernel driver should not really factor in on the GRUB screen (conversely the GRUB graphics mode can have a factor on the kernel mode display, but it doesn't read like that's what you're struggling with).

I gather this was thanks to Nvidia and their being SO slow in opening their code, thus the wiki states that

DRM kernel mode setting
nvidia 364.16 adds support for DRM (Direct Rendering Manager) kernel mode setting. To enable this feature, add the nvidia-drm.modeset=1 kernel parameter. For basic functionality that should suffice, if you want to ensure it's loaded at the earliest possible occasion, or are noticing startup issues you can add nvidia, nvidia_modeset, nvidia_uvm and nvidia_drm to the initramfs according to Mkinitcpio#MODULES.
If added to the initramfs do not forget to run mkinitcpio every time there is a nvidia driver update. See #Pacman hook to automate these steps.
Warning: Enabling KMS causes GNOME to default to Wayland. Non-Wayland-native applications suffer from poor performance in Wayland sessions because of the lack of hardware accelerated XWayland. This is expected to be resolved "soon", but there is no committed timeline from NVIDIA. Use the GNOME on Xorg session instead.
Note: The NVIDIA driver does not provide an fbdev driver for the high-resolution console for the kernel compiled-in vesafb module. However, the kernel compiled-in efifb module supports a high-resolution console on EFI systems. This method requires GRUB or rEFInd and is described in NVIDIA/Tips and tricks#Fixing terminal resolution.[1][2][3].

so assuming I'm not getting out of my depth, and assuming this is what you meant, I'd say that yes this is what I'm struggling with - if we can call it a struggle. I'm somewhat loathe to start calling grub2 "ugly" or to criticise it, I was so interested to find Burg but that seems to have died a quiet death (or been subsumed by Canonical) so... those of us still using machines from the last decade are being left behind somewhat, while UEFI has all the pretty bells and whistles

headkase · 2020-04-20 16:55:35

archuser_9999 wrote:

V1del wrote:
The kernel driver should not really factor in on the GRUB screen (conversely the GRUB graphics mode can have a factor on the kernel mode display, but it doesn't read like that's what you're struggling with).
I gather this was thanks to Nvidia and their being SO slow in opening their code, thus the wiki states that
DRM kernel mode setting
nvidia 364.16 adds support for DRM (Direct Rendering Manager) kernel mode setting. To enable this feature, add the nvidia-drm.modeset=1 kernel parameter. For basic functionality that should suffice, if you want to ensure it's loaded at the earliest possible occasion, or are noticing startup issues you can add nvidia, nvidia_modeset, nvidia_uvm and nvidia_drm to the initramfs according to Mkinitcpio#MODULES.
If added to the initramfs do not forget to run mkinitcpio every time there is a nvidia driver update. See #Pacman hook to automate these steps.
Warning: Enabling KMS causes GNOME to default to Wayland. Non-Wayland-native applications suffer from poor performance in Wayland sessions because of the lack of hardware accelerated XWayland. This is expected to be resolved "soon", but there is no committed timeline from NVIDIA. Use the GNOME on Xorg session instead.
Note: The NVIDIA driver does not provide an fbdev driver for the high-resolution console for the kernel compiled-in vesafb module. However, the kernel compiled-in efifb module supports a high-resolution console on EFI systems. This method requires GRUB or rEFInd and is described in NVIDIA/Tips and tricks#Fixing terminal resolution.[1][2][3].
so assuming I'm not getting out of my depth, and assuming this is what you meant, I'd say that yes this is what I'm struggling with - if we can call it a struggle. I'm somewhat loathe to start calling grub2 "ugly" or to criticise it, I was so interested to find Burg but that seems to have died a quiet death (or been subsumed by Canonical) so... those of us still using machines from the last decade are being left behind somewhat, while UEFI has all the pretty bells and whistles

It's not nVidia's fault here though, nVidia provides a display driver. That driver isn't loaded, at the earliest for my understanding, until after GRUB. GRUB loads before the display driver so what it can display is only what the BIOS has. There may be some means to include some kind of extension to the grub files themselves, that would be a possible solution if someone can provide a technical pointer.

archuser_9999 · 2020-04-20 17:00:37

thanks for that clarification. Yes, I understand that now.

It will be interesting to see if anyone has any further ideas on this.

Meanwhile I'm just booting up a donor Windows machine that's a bit newer... on the mainboard I saw written the magic letters UEFI

headkase · 2020-04-20 18:20:28

Right on, you're welcome. UEFI is much nicer, for that I recommend systemd-boot, simple configuration files that just do it - not a complex script like GRUB generates.

https://wiki.archlinux.org/index.php/Systemd-boot

Mount your EFI partition directly onto /boot for the sanest configuration..

Head_on_a_Stick · 2020-04-20 18:39:37

headkase wrote:

There may be some means to include some kind of extension to the grub files themselves

Only for Intel cards: https://wiki.archlinux.org/index.php/GR … ution_hack

headkase wrote:

a complex script like GRUB generates

If you don't like the complex configuration file produced by grub-mkconfig(8) then just write your own instead:

empty@E485 ~ % wc -l /boot/grub/grub.cfg
7 /boot/grub/grub.cfg
empty@E485 ~ %

^ Two of those lines aren't actually needed to boot the machine :-)

archuser_9999 · 2020-04-22 19:31:55

Well, I've resolved the issue in a different way: I've ended up switching to another computer entirely!

note to mods: very happy to mark this "solved" but if this post is to remain helpful to others... perhaps 'solved' is not quite right - read on please:

What the various replies above helped me to do was focus, and reappraise where any other aspect of this could be addressed, it not finally being a bug or an 'issue' beyond the choice of hardware.

And so it was, in an idle moment, I dragged out a small metal box from under a small stack of old computers I've been donated or have somehow collected, and starting wondering. Long story short: now using a five/six year old PC that has a UEFI bios chip... OH BOY does that make a difference! So, with integrated Intel graphics, and no need whatsoever for me to need to configure or do anything else, I'm content to just put it down to age (of computer, not mine!).

Worth noting: reformatted all the drives in said machine, and went through the live install of basic Arch, loaded a DE on top, added bootloader. Voila! It booted first time in full 1920 x 1080 res, didn't need to touch any settings!

Seems it's all very well keeping old Nvidia cards supported but err... in my case clearly should have moved on ages ago

Thanks for all the help.

Arch Linux

#1 2020-04-20 13:04:32

grub2 boot: displayed resolution does NOT match that set in gfx_mode

#2 2020-04-20 13:29:18

Re: grub2 boot: displayed resolution does NOT match that set in gfx_mode

#3 2020-04-20 13:40:35

Re: grub2 boot: displayed resolution does NOT match that set in gfx_mode

#4 2020-04-20 15:43:07

Re: grub2 boot: displayed resolution does NOT match that set in gfx_mode

#5 2020-04-20 16:14:45

Re: grub2 boot: displayed resolution does NOT match that set in gfx_mode

#6 2020-04-20 16:55:35

Re: grub2 boot: displayed resolution does NOT match that set in gfx_mode

#7 2020-04-20 17:00:37

Re: grub2 boot: displayed resolution does NOT match that set in gfx_mode

#8 2020-04-20 18:20:28

Re: grub2 boot: displayed resolution does NOT match that set in gfx_mode

#9 2020-04-20 18:39:37

Re: grub2 boot: displayed resolution does NOT match that set in gfx_mode

#10 2020-04-22 19:31:55

Re: grub2 boot: displayed resolution does NOT match that set in gfx_mode

Board footer