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.
It absolutely sucks to be running your console at 80x25 when your display supports 4K resolution.

Artem S. Tashkinov
Linux and Open Source advocate

#1
Posted 12/30/2016 09:14 PM   
Not exactly what you are looking for, but there is this: https://wiki.archlinux.org/index.php/NVIDIA#DRM_kernel_mode_setting [quote]DRM kernel mode setting 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 high-resolution nvidia console on EFI systems.[1] Another option to get high-resolution consoles is to use GRUB, see NVIDIA/Tips and tricks#Fixing terminal resolution and [2]. nvidia 364.16 adds support for DRM kernel mode setting. To enable this feature, add the nvidia-drm.modeset=1 kernel parameter, and add nvidia, nvidia_modeset, nvidia_uvm and nvidia_drm to your initramfs#MODULES. Warning: Do not forget to run mkinitcpio every time you update driver.[/quote]
Not exactly what you are looking for, but there is this:
https://wiki.archlinux.org/index.php/NVIDIA#DRM_kernel_mode_setting
DRM kernel mode setting
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 high-resolution nvidia console on EFI systems.[1] Another option to get high-resolution consoles is to use GRUB, see NVIDIA/Tips and tricks#Fixing terminal resolution and [2].
nvidia 364.16 adds support for DRM kernel mode setting. To enable this feature, add the nvidia-drm.modeset=1 kernel parameter, and add nvidia, nvidia_modeset, nvidia_uvm and nvidia_drm to your initramfs#MODULES.
Warning: Do not forget to run mkinitcpio every time you update driver.

#2
Posted 01/02/2017 11:50 PM   
Bump!
Bump!

Artem S. Tashkinov
Linux and Open Source advocate

#3
Posted 01/24/2017 08:25 AM   
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.
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.

Aaron Plattner
NVIDIA Linux Graphics

#4
Posted 01/27/2017 05:04 PM   
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.
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.

#5
Posted 01/27/2017 06:12 PM   
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: [code]vga=0x34c video=vesafb:mtrr:3,ywrap[/code] 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. [url=https://devtalk.nvidia.com/member/1882081/]@Aaron[/url] Please reconsider your decision. It's driving me mad.
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.

Artem S. Tashkinov
Linux and Open Source advocate

#6
Posted 01/27/2017 09:36 PM   
[quote=""]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.[/quote] I already reported this issue 3 months ago. See [url=https://devtalk.nvidia.com/default/topic/973292/driver-v375-10-not-returning-to-the-console-on-shutdown/]this thread[/url]. 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.
said: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.

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.

#7
Posted 01/28/2017 08:47 AM   
Edit: Nevermind. The link I posted mentioned out of date information.
Edit: Nevermind. The link I posted mentioned out of date information.

#8
Posted 01/28/2017 06:35 PM   
[quote=""]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.[/quote] 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.
said: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.


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.

Artem S. Tashkinov
Linux and Open Source advocate

#9
Posted 01/28/2017 06:52 PM   
[quote=""]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?[/quote] 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.
said: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?

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.

#10
Posted 01/29/2017 08:26 AM   
[quote="birdie"]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: [code]vga=0x34c video=vesafb:mtrr:3,ywrap[/code] 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.[/quote] Hmm, that does sound strange. I saw your post about this in the other thread -- I'll reply there. [quote="birdie"]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.[/quote] 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.
birdie said: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.

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

birdie said: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.

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.

Aaron Plattner
NVIDIA Linux Graphics

#11
Posted 01/30/2017 03:58 PM   
[quote="aplattner"]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.[/quote] 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 !
aplattner said: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 !

#12
Posted 01/31/2017 12:17 AM   
[quote="aplattner"][quote="birdie"]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.[/quote] 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.[/quote] 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
aplattner said:
birdie said: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.

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.

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

#13
Posted 03/07/2017 03:23 PM   
Scroll To Top

Add Reply