0

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?

Improve this question
15
  • 1
    Yes, it's likely outdated. Funny thing, although "ancient", the GT710 chip is still being shipped today in brand new graphics cards from at least one mainstream vendor. Nvidia suggests running the 470.239.06 driver version released just a few months ago.
    – ChanganAuto
    Commented Jun 2 at 19:27
  • 1
    As a user of NVIDIA based cards foe nearly 25 years, the in-kernel reverse engineered drivers have never worked as well as the out of kernel proprietary blobs. That being said my guess would be this is some sort of kernel regression bug. If you insist on using nvidiafb, you'll need to downgrade kernels until the regression disappears or as ChanganAuto has pointed out, realize that this module has been replaced, and you need to use efifb on newer UEFI systems.
    – eyoung100
    Commented Jun 4 at 20:30
  • 1
    Look here: UEFI Resolution Woes. I had forgotten I wrote and answered that post myself. Hopefully your motherboard manufacturer has provided something similar to change/update your GOP setting. In short try gop set from inside a UEFI shell or use your motherboard firmware's utility to set the resolution.
    – eyoung100
    Commented Jun 4 at 20:51
  • 1
    I believe you can use gop mode ro list available resolutions. Would you mind adding your motherboard model to your question? I have a feeling mode is only going to list 2 options, as your NVRAM is marked read-only. Reread my answer and see if the WHQL option is turned off on your Motherboard.
    – eyoung100
    Commented Jun 5 at 15:25
  • 1
    Hang on let me look all that up, and I'll write up an answer. Big Picture here: 1) We're going to turn on the WHQL setting in the setup utility if there is one, or 2) We're going to create a USB with the EFI shell on it and manually set the mode, or lastly 3) We will check the NVIDIA website for this update and see if it can be applied.
    – eyoung100
    Commented Jun 5 at 17:10

1 Answer 1

Reset to default
1
+150

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: 800x600 and 1024x768. My display is 1920x1080, 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 1024x768. 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.

Improve this answer
12
  • Thank you a lot for your effort.
    – melonfsck
    Commented Jun 5 at 21:38
  • 1
    NVIDIA cards and the proprietary drivers have never supported a frame-buffer device, since about the late 1990's. The newer drivers (550.xx+) now have a kernel module that supports Kernel Mode Switching but it's experimental. The closest you can get is to use the nouveau driver which I believe supports a framebuffer but then you'll lose all the changes you made to get the efifb working at the correct resolution. It's either one or the other based on the age of the card (The 470 series drivers don't contain the code for the KMS module IIRC).
    – eyoung100
    Commented Jun 5 at 21:48
  • 1
    Continuing: 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. To see why look at the GOP link to the source code I posted. To reduce complexity for the mode command and keep the size small the efifb driver only loads after the system is booted. Since the NVRAM was loaded read-only the ability to change it while booting doesn't work, i.e., it's not in the source code. Those framebuffer drivers you tried using haven't worked since the mid 1990's. Using the plain VGA console was a workaround until UEFI.
    – eyoung100
    Commented Jun 5 at 21:56
  • 1
    I'm glad that works. According to that NVIDIA post I linked earlier, it has something to do with how the framebuffer (fbdev) attaches itself to the driver (nvidia/nouveau/efifb). I don't understand what the dev meant by the "module doesn't unload" when insmod and rmmod` can be used. I suppose what you did (faking a second device and linking it to the first would be considered correct, although it may break on upgrade
    – eyoung100
    Commented Jun 6 at 16:28
  • 1
    @melonfsck I never got to finish my thought, so here goes: Like you, I do wish they would fix the problem/find another approach. As a gamer and an IT type ,I prefer NVIDIA branded graphics cards but I've been dealing with issues like the one you posted for decades now because that's what NVIDIA chose as a design decision, and while some of their engineers etc might use LInux etc., NVIDIA has always lagged behind in the Linux market, and I think it's because most hardcore gamers don't want to waste time configuring drivers etc when they can just start a game on Windows and it works.
    – eyoung100
    Commented Jun 6 at 18:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .