Kernel mode setting does not work in CONSOLE mode under linux
I would like to enable modeset in my linux system while retaining the nvidia drivers. My objective is to gain HDMI resolution for my consoles in addition to those under X. I would like to run in [color="orange"]console[/color] mode, completely avoiding invoking X. I am running a Slackware 64 bit linux system with the 4.8.10 kernel. I have a GTX 660 video card, and am running the NVIDIA-Linux-x86_64-375.39.run driver. The following nvidia modules are loaded: nvidia_uvm 599998 0 nvidia_drm 39655 0 nvidia_modeset 773859 1 nvidia_drm nvidia 12059531 2 nvidia_modeset,nvidia_uvm drm_kms_helper 111734 1 nvidia_drm drm 277190 3 nvidia_drm,drm_kms_helper i2c_core 39534 6 nvidia,i2c_i801,i2c_smbus,i2c_dev,drm_kms_helpe$ I have included an nvidia.conf file in my /etc/modprobe.d directory, the contents of which are: options nvidia-drm modeset=1 If I check /sys/module/nvidia_drm/parameters/modeset the content is Y. So modeset seems to be enabled. Nevertheless, I have 25x80 characters. The linux nouveau driver enables modeset and I have HDMI resolution both for characters and graphics. I'm stumped; I don't know how to get the desired resolution with the nvidia driver. If I turn my monitor off and back on again it gives the current mode as 1920x1080 60 Hz, but the font is not correspondingly fine as it is with the nouveau driver. Am I correct in assuming that I would not be able to use CUDA programming with the nouveau driver, that it requires the actual nvidia driver? I can provide the nvidia bug report file, but there doesn't seem to be a way to attach it here. I would like to emphasize that I am interested ONLY in [color="orange"]CONSOLE[/color] mode; X is completely out of the picture (but works fine). The first-level customer support person seemed to not understand this concept.
I would like to enable modeset in my linux system while retaining the nvidia drivers. My objective is to gain HDMI resolution for my consoles in addition to those under X. I would like to run in console mode, completely avoiding invoking X.

I am running a Slackware 64 bit linux system with the
4.8.10 kernel. I have a GTX 660 video card, and am
running the NVIDIA-Linux-x86_64-375.39.run driver.

The following nvidia modules are loaded:
nvidia_uvm 599998 0
nvidia_drm 39655 0
nvidia_modeset 773859 1 nvidia_drm
nvidia 12059531 2 nvidia_modeset,nvidia_uvm
drm_kms_helper 111734 1 nvidia_drm
drm 277190 3 nvidia_drm,drm_kms_helper
i2c_core 39534 6 nvidia,i2c_i801,i2c_smbus,i2c_dev,drm_kms_helpe$

I have included an nvidia.conf file in my /etc/modprobe.d directory, the contents of which are:

options nvidia-drm modeset=1

If I check /sys/module/nvidia_drm/parameters/modeset the content is Y.

So modeset seems to be enabled. Nevertheless, I have 25x80 characters. The linux nouveau driver enables modeset and I have HDMI resolution both for characters and graphics. I'm stumped; I don't know how to get the desired resolution with the nvidia driver.

If I turn my monitor off and back on again it gives the current mode as 1920x1080 60 Hz, but the font is not correspondingly fine as it is with the nouveau driver.

Am I correct in assuming that I would not be able to use CUDA programming with the nouveau driver, that it requires the actual nvidia driver?

I can provide the nvidia bug report file, but there doesn't seem to be a way to attach it here.

I would like to emphasize that I am interested ONLY in CONSOLE mode; X is completely out of the picture (but works fine). The first-level customer support person seemed to not understand this concept.

#1
Posted 08/20/2017 09:46 PM   
Kernel modesetting is not what gives you a high resolution console. That's a misconception that's been around forever. The high-res console still uses, as it always has, fbdev. It's just that open source KMS drivers typically have fbdev compatibility in them. But the Nvidia proprietary driver does not. So no high-res console until Nvidia codes fbdev compatibility into their driver.
Answer Accepted by Original Poster
Kernel modesetting is not what gives you a high resolution console. That's a misconception that's been around forever. The high-res console still uses, as it always has, fbdev. It's just that open source KMS drivers typically have fbdev compatibility in them. But the Nvidia proprietary driver does not. So no high-res console until Nvidia codes fbdev compatibility into their driver.

#2
Posted 08/21/2017 03:24 AM   
Thanks, that explains what I observed. The whole effort seems to have been a waste of energy since I now know that CUDA is 32-bit only and I'm running a 64-bit system. Thanks again!
Thanks, that explains what I observed. The whole effort seems to have been a waste of energy since I now know that CUDA is 32-bit only and I'm running a 64-bit system. Thanks again!

#3
Posted 08/21/2017 04:08 AM   
CUDA isn't 32-bit only... there's a 64-bit libcuda.so.1 shipped with the driver and a 64-bit CUDA toolkit is available at https://developer.nvidia.com/cuda-downloads As for the fbdev thing, Gusar is correct; the nvidia-drm driver does not implement an fbdev console. But you should be able to use vesafb or efifb, depending on your system setup. vesafb isn't [i]technically[/i] supported at the moment, but we're making an effort to make it work better overall. The main reason, currently, that we don't implement a framebuffer console is that when a kernel module is plugged in as the framebuffer console driver, it can't be unloaded. We need to be able to support unloading the kernel module.
CUDA isn't 32-bit only... there's a 64-bit libcuda.so.1 shipped with the driver and a 64-bit CUDA toolkit is available at https://developer.nvidia.com/cuda-downloads


As for the fbdev thing, Gusar is correct; the nvidia-drm driver does not implement an fbdev console. But you should be able to use vesafb or efifb, depending on your system setup. vesafb isn't technically supported at the moment, but we're making an effort to make it work better overall.

The main reason, currently, that we don't implement a framebuffer console is that when a kernel module is plugged in as the framebuffer console driver, it can't be unloaded. We need to be able to support unloading the kernel module.

Aaron Plattner
NVIDIA Linux Graphics

#4
Posted 08/21/2017 07:10 PM   
[quote="aplattner"]The main reason, currently, that we don't implement a framebuffer console is that when a kernel module is plugged in as the framebuffer console driver, it can't be unloaded. We need to be able to support unloading the kernel module.[/quote] This could have been solved with an unsupported/hidden module option so that you won't get a torrent of bug reports related to your fbdev implementation. Say, [code]fbdev_experimental=1[/code] in which case driver unloading becomes unavailable. I guess 99% of your desktop users will agree to that. It's not a big deal to reboot in case one wants to upgrade their NVIDIA driver. It's not like you have too many drivers releases to even be inconvenienced by this.
aplattner said:The main reason, currently, that we don't implement a framebuffer console is that when a kernel module is plugged in as the framebuffer console driver, it can't be unloaded. We need to be able to support unloading the kernel module.


This could have been solved with an unsupported/hidden module option so that you won't get a torrent of bug reports related to your fbdev implementation.

Say,
fbdev_experimental=1
in which case driver unloading becomes unavailable. I guess 99% of your desktop users will agree to that. It's not a big deal to reboot in case one wants to upgrade their NVIDIA driver. It's not like you have too many drivers releases to even be inconvenienced by this.

Artem S. Tashkinov
Linux and Open Source advocate

#5
Posted 08/21/2017 07:29 PM   
When/how would one use the fbdev_experimental=1 thing? NOT a developer. I don't intend to be a bother, but the helpdroid said this was where I had to come to get an answer to my question :-(
When/how would one use the fbdev_experimental=1 thing?

NOT a developer. I don't intend to be a bother, but the helpdroid said this was where I had to come to get an answer to my question :-(

#6
Posted 08/21/2017 08:44 PM   
Scroll To Top

Add Reply