NVIDIA devs: any ETA on FBDEV (console mode setting) implementation?

It absolutely sucks to be running your console at 80x25 when your display supports 4K resolution.

Not exactly what you are looking for, but there is this:
https://wiki.archlinux.org/index.php/NVIDIA#DRM_kernel_mode_setting

Bump!

We don’t have any plans to add this feature at the moment. The big problem, according to my understanding, is that when a driver registers to drive an FB console, it gets plugged into the fbcon driver in a way that prevents the module from ever being unloaded.

It’s possible to unbind the device from the console with “echo 0 > /sys/class/vtconsole/vtcon1/bind” which will then allow you to unload the module. The tricky part is restoring the VGA text console after the unbind happens.

That’s really really sad because recent NVIDIA drivers have become incompatible with Vesa FB :-( Whenever I try to shutdown or reboot my PC, my console blanks/goes black when the X server exits. That also means I cannot change runlevel from 5 to 1(or 3), because the screen will go totally black.

Here’s my kernel boot options:

vga=0x34c video=vesafb:mtrr:3,ywrap

Pre 37x.xx drivers ran just fine with it, everything new doesn’t. I know NVIDIA has never guaranteed that any text console mode, other than plain 80x25, will work but it worked up until half a year ago.

However I’m curious: most modern PCs run UEFI and UEFI is driven by UefiFB which must work with NVIDIA drivers, yet VesaFB doesn’t any longer.

@Aaron

Please reconsider your decision. It’s driving me mad.

I already reported this issue 3 months ago. See this thread. At the time being NVIDIA devs did not manage to reproduce it on their hardware. I’m glad someone else comes up, speaks about this show stopper and confirms it…

@Birdie:
You will also find a couple workarounds in my thread for this issue. You may insert a “chvt 1;sleep 3” in your rc files (the main one, which detects reboots, see the other thread, and the display manager one,in the “stop” path, just before dm is killed): this will work like 50% of the time and gives you the opportunity (thanks to the sleep) to hit CTRL ALT F1 to switch to the fb console before X11 is killed and the screen would go blank.

As for the last NVIDIA driver version not affected by this bug, it’s v370.28, and that’s the driver I’m now using and stuck with, till NVIDIA reverts their catastrophic changes to the FB switching code in their driver.

Edit: Nevermind. The link I posted mentioned out of date information.

This driver must be incompatible with new linux kernels, how do you run it? Do you have a repository of patches or some distro already maintains them?

I bumped your thread because I’m sure it deserves attention until the console mode restoration code is reverted.

Simply reuse v375’s fixed common/inc/nv-mm.h header in v370.28’s sources, and the latter become compatible with the current v4.9 Linux kernel.

I’m attaching the corresponding patch below.
nvidia-370.28-kernel-4.9.patch.gz (958 Bytes)

Hmm, that does sound strange. I saw your post about this in the other thread – I’ll reply there.

The UEFI GOP driver always puts the screen into a mode that nvidia-modeset should be able to restore natively, and uefifb never changes it. So it should always use the new console restore path.

vesafb sets modes that, depending on the configuration, may or may not be compatible with the new console restore code, so the driver will either try to restore it natively or fall back to using the VBIOS to do the modeset. That’s why we don’t officially support non-text mode on legacy boot systems.

v370.28 and all former versions of the NVIDIA drivers used to work just fine on all my computers with all my NVIDIA cards and all my Linux distros for many, many years. True, sometimes, the console was “corrupted” on restoration when X11 was shut down (spurious lines/characters), but I never cared.

Starting with v375 however (i.e. with your latest changes to the console switching/restoration code), the screen now goes blank every time X11 is killed before a console switch occurs (either manually, or via a “chvt 1;sleep 2” sequence in a script, and even in the latter case, it sometimes fails), which is a show stopper for many people using the console.

Please, consider reverting to the old console switching/restoration code: even if not perfect, it at least did not lock the screen in a blank mode that only a computer reset can exit !

Just for your information I am on UEFI (efifb) and NVIDIA 378.13 driver for my GTX 1070 and my console is NOT getting restored after I shutdown Xserver. I get blank screen and I must either reboot my computer or access it remotely to restart Xserver.

So I’d appreciate if NVIDIA has fixed at least UEFI path, which is the modern path for new PCs.

See my other answer at:
https://devtalk.nvidia.com/default/topic/973292/linux/-bug-driver-v375-10-and-newer-not-returning-to-the-console-on-shutdown/3

Well, you problem was fixed, OnO. As I understand with having efifb I do not care about fbdev?