Timeline for Low resolution in the EFI/VGA early boot framebuffer/console (and in GRUB)
Current License: CC BY-SA 4.0
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 5, 2024 at 21:59 | history | edited | eyoung100 | CC BY-SA 4.0 | Added Github Link |
| Jun 6, 2024 at 19:37 | vote | accept | Elisa K. K. | ||
| Jun 6, 2024 at 19:01 | history | edited | eyoung100 | CC BY-SA 4.0 | Fixed spelling |
| Jun 6, 2024 at 18:47 | comment | added | eyoung100 | @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. | |
| Jun 6, 2024 at 16:28 | comment | added | eyoung100 | 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 | |
| Jun 6, 2024 at 15:49 | comment | added | Elisa K. K. | I have also changed the question to match your answer contents, so it will be helpful to others. | |
| Jun 6, 2024 at 15:24 | comment | added | Elisa K. K. | Finally I was able to run Xorg on the efifb device. To do that, I had to first insmod the vfb driver (virtual framebuffer, which is detected fine by Xorg), and then to issue mount --bind /dev/fb0 /dev/fb1 command to make the /dev/fb1 device (vfb) pointed to /dev/fb0 (efifb) instead. Then Xorg thinks that it is not running on efifb, and starts successfully. And when it gets to opening the device, the bind-mount causes it to open my efifb instead of vfb! Im not sure if there is a better solution. Its super weird, first of all, that Xorg doesnt run if i just have /dev/fb0 (efifb). | |
| Jun 5, 2024 at 22:36 | comment | added | eyoung100 | As I said, previously, It's one or the other based on how the driver is implemented. That was a developer/company choice that's been argued about for almost 3 decades now. Long before efifb some users feel that NVIDIA doesn't properly support the open-source community, but that discussion isn't related to this post. | |
| Jun 5, 2024 at 22:33 | history | edited | eyoung100 | CC BY-SA 4.0 | Added Rebuttal to Comments |
| Jun 5, 2024 at 22:21 | comment | added | Elisa K. K. | I already have the high resolution console, using efifb. Now I want to start Xorg on top of efifb (only) - as I did before (when I had the efifb with low resolution). But it doesn't work. Interesting thing is that it worked properly before, until I disabled CSM and booted full resolution | |
| Jun 5, 2024 at 22:18 | comment | added | eyoung100 | See: NVIDIA devs: any ETA on FBDEV (console mode setting) implementation? | |
| Jun 5, 2024 at 22:10 | comment | added | Elisa K. K. | You got me wrong, I meant I want to run Xorg on efifb which I now have configured for the correct resolution. efifb is a framebuffer device, just a normal framebuffer device. There should be nothing that would prevent me from running Xorg on any framebuffer devices (using the fbdev Xorg driver). It should not require any different "gpu drivers", only the FB. But for some reason I can't correctly specify the BusID option for the fbdev driver in Xorg. It doesn't detect my framebuffer. I don't know why it works even with vfb (the virtual frame buffer), but not with efifb... | |
| Jun 5, 2024 at 21:56 | comment | added | eyoung100 | 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. | |
| S Jun 5, 2024 at 21:49 | history | suggested | Elisa K. K. | CC BY-SA 4.0 | fix my pronouns and one typo |
| Jun 5, 2024 at 21:48 | comment | added | eyoung100 | 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). | |
| Jun 5, 2024 at 21:42 | review | Suggested edits | |||
| S Jun 5, 2024 at 21:49 | |||||
| Jun 5, 2024 at 21:39 | comment | added | Elisa K. K. | I wanted to run Xorg on framebuffer device only (not Nvidia drivers). | |
| Jun 5, 2024 at 21:38 | comment | added | Elisa K. K. | Thank you a lot for your effort. | |
| Jun 5, 2024 at 21:36 | history | bounty awarded | Elisa K. K. | ||
| Jun 5, 2024 at 21:35 | vote | accept | Elisa K. K. | ||
| Jun 6, 2024 at 19:37 | |||||
| Jun 5, 2024 at 21:35 | history | edited | eyoung100 | CC BY-SA 4.0 | Fixed Asterisks |
| Jun 5, 2024 at 21:29 | history | answered | eyoung100 | CC BY-SA 4.0 |