Low resolution in the EFI/VGA early boot framebuffer/console (and in GRUB)

When I boot my Linux machine with UEFI and grub2, I get only few graphic modes (resolution modes) available. And both of them are really smaller than my monitor/screen. For example, the boot console resolution gets set to 800x600 while my screen is 1920x1080, and the picture looks really bad.

My GPU is Nvidia, but I don’t want to install, insert or use any GPU-specific drivers. At least, not at boot.

I am interested in changing the initial EFI/VGA boot console (and GRUB2) resolution to match my full screen.

Some sources say that I can not, because it is only possible to use resolutions supported by the GPU in VESA-extensions mode. Is it true? Does it apply to my case? Or do I just need to change some UEFI settings?

I would like to have the full resolution enabled right from the moment when GRUB starts. Is it possible?

Asked By: melonfsck

||

Boot Level Vs. Kernel Level

From the OP’s Comment:

@eyoung100 I’m able to view and select EFI GOP modes in the grub2 menu. But there are only two modes available: 800×600 and 1024×768. My display is 1920×1080, and these modes look awfully on it (especially if I use Xorg with efifb). That’s why I can’t use EFI framebuffer…

I believe that the OP is trying to fix a boot level issue with a kernel level fix. Some things to remember:

  1. The GOP resolutions and EFI Variables are stored in the computer’s NVRAM as read-only.
  2. The only time the read-only protection is removed is after the computer boots.
  3. Theoretically, the values can be changed, but the only time I’ve ever seen them updated is with a tools like efivars and versions of grub
  4. While the above tools can access the EFI values to change things like the boot order, I’ve never seen, or been able to Google anyone ever using the tools to access and change the GOP or Graphics Output Protocol.
  5. As one can see from the link in 4, the Graphics port is coded into the UEFI shell. The advantage of this is that it removes the reliance on hardware in order to create the display output, as noted in this PDF.

What’s Next

Because the GOP is only accessible in a pre-boot environment, the resolution must be set in the pre-boot environment a.k.a. the UEFI Shell, which the OP seems to have beaten me to:

@eyoung100 I was able to fully disable CSM in UEFI, and then in grub2 I saw about six new modes for GOP! One of them was my full-resolution mode! It worked fine. I booted in the correct mode with /dev/fb0 provided by efi-framebuffer.0

As such, I’m providing a method to create a UEFI Shell for future readers. One can use this method to perform shell scripting (to set-up the way the PC boots), set resolutions, repair broken boot options and more, without any OS. I could write them out here, but for length and brevity sake, follow steps 1 through 7 at: KilianKegel/Howto-create-a-UEFI-Shell-Boot-Drive.
– Note that you can replace Step 3 with a more recent stable version by Downloading a shell.efi file from the EDK2 Releases Page.

Determining Available Resolutions

  1. Boot from the newly created USB stick.
  2. After letting startup.nsh finish, at the prompt type gop mode
  3. A list will appear displaying 3 columns and a row which will be asterisked**.
    • Starting on the left, the first column is the choice number
    • The Second column is the number of characters per column per screen
    • The Third Column is the number of Rows per Screen
  4. Use gop set x where x is the number corresponding with your chosen choice***.
  5. Reboot to save the choice***.

Notes:
** I believe the First Choice is 80x25 which if I’m remembering right equates to a resolution of 640x480.
*** It may take multiple reboots and sets before selecting the desired outcome.

Now That My Resolution Is Set

As the OP noted via the comment above make sure that when using a completely UEFI based system, CSM is completely off. CSM was put in to emulate BIOS based systems until the UEFI protocol was completely accepted.

  • One of those emulations was the VBIOS in graphics cards. Until the OS took over the boot process the VGA BIOS protocol instructed the card to boot to a video mode no greater than 1024×768. After the OS took over, the driver was switched to the mode that was set via the OS settings, i.e., the Driver you Download from your Graphics Card’s manufacturer or a third-party OEM like PNY takes over.

In the case of my question and answer, to completely disable CSM, I had to Enable WHQL Support for Windows 8.1/10 so all my OS’es could see the GOP aware NVIDIA GeForce 1070 in my system, even though FreeBSD has no need for Windows Driver signing. I’ll let the OP comment how they were able to find the 6 additional resolutions below, as I spent about an hour searching through screenshots of the surprisingly common Aptio Setup Utility before I started writing this answer, and was unable to find a written procedure.

We’re Now at the Kernel Level

…There is another new problem though, likely caused by disabling CSM. I can read/write to /dev/fb0 and it displays correctly. But if I run Xorg, it refuses to detect my framebuffer device, no matter what I do to the configuration file (or the total lack of one). It says No screens found after few attempts to invoke fbdevhw

The OP now needs to use their OS’es package manager (they never stated the OS but I’m going to guess at a Debian based one), and issue a:

sudo apt nvidia-driver

to install the last supported version of the proprietary binary blob which will be 470.xx.xx Included in that download/install should be a tool nvidia-xconfig. If it’s not there, try:

sudo apt nvidia-xconfig

That tool will write a xorg.conf file that can then be modified by hand. Unfortunately, because of the proprietary driver the auto-detection in X.Org will attempt to install the nv driver, which is worse than the nouveau driver, and the nouveau driver provides no 3D acceleration.

Adding this Based on Comments Below

I realize the OP wants to run X.Org in the fbdev device. The reason I answered this post the way I did (advising the OP to use either the NVIDIA proprietary or nouveau driver) is because the NVIDIA devs refuse to create code that allows their Graphics Cards to "attach" to the fbdev or fbcon kernel drivers, as evidenced by the answer directly from a Developer all the way back in 2016. Note that the version of the driver is a moot pint here, because as I stated in my comments below:

With the advent of UEFI, the ability to use the uvesa kernel module and pass vga=xxx on the kernel command line flew out the window.

This was backed up by birdie‘s answer. The user community has been complaining about this issue long before that post, and has asked multiple times that NVIDIA release an open-source driver that the community can refine, but seeing as NVIDIA is a for profit company, I don’t see that happening anytime soon.

Answered By: eyoung100