Kernel mode setting does not work in CONSOLE mode under linux

Graphics / Linux Linux
1

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.

2

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.

3

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!

4

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 CUDA Toolkit 11.7 Update 1 Downloads | NVIDIA Developer

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.

5

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.

6

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 :-(

7

@ Aaron :
Any updates concerning fbdev compatibility for hi-res console?
This is more than overdue … for years now.
Kind regards
Manfred

8

You can already have high resolution console.

#/boot/grub/grub.cfg
set timeout=5
menuentry 'Arch Linux' {
        set root='hd0,1'
        <b>set gfxpayload=1920x1080</b>
        linux /vmlinuz-linux-lts cryptdevice=/dev/sda3:root resume=/dev/mapper/swap root=/dev/mapper/root....
        initrd /intel-ucode.img /initramfs-linux-lts.img
}
9

Hussam,
please, read Aaron’s confirmation above …

10

I did. I’m just saying there is an easy way to get high resolution that’s been working for me since a while now. I have high res console since March. I’m not negating what he said.

11

NEITHER initramfs NOR vesafb NOR efifb
“the nvidia-drm driver does not implement an fbdev console [compatibility]” <— plain
“open source KMS drivers typically have fbdev compatibility in them.”

12

This is what my dmesg output says.

[    0.450140] vesafb: mode is 1920x1080x32, linelength=7680, pages=0
[    0.450140] vesafb: scrolling: redraw
[    0.450141] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    0.450147] vesafb: framebuffer at 0xd1000000, mapped to 0xffffb06f42000000, using 8128k, total 8128k
[    0.704592] fb0: VESA VGA frame buffer device
13

Excuse me if I step in and make some dumb questions but what would be the advantage or use case of this? fbdev is depreciated in favor of drm/kms so in future only efifb and drmfb/kmscon would matter anyway?

14

Yes. But for now, sadly setting “nvidia-drm modeset=1” often makes gnome-shell unstable for me.

15
16

I’m not understanding then.Can you explain?

17

[url]https://www.phoronix.com/scan.php?page=news_item&px=Generic-FBDEV-Emulation-DRM[/url]

18

Working as SysAdmin @ 3840 x 2160 @ 4K QFHD Monitor,
getting 25x80 characters is not offence any more,
but plain torture.
Kind regards again
Manfred

19

Booting EFI or CSM? Did you check if the proposal I linked to succeeded?