I have a desktop PC with the only GPU which is NVIDIA’s 1660 Ti.
I’ve enabled modesetting via
options nvidia-drm modeset=1
However I don’t feel or see any difference. My text terminal is still running its initial EFI resolution (I guess it’s 720p or something - hard to say), it takes a few seconds to switch between an X.org session and text console.
and dmesg says:
Console: colour dummy device 80x25
printk: console [tty0] enabled
pci 0000:08:00.0: vgaarb: setting as boot VGA device
pci 0000:08:00.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
pci 0000:08:00.0: vgaarb: bridge control possible
simple-framebuffer simple-framebuffer.0: framebuffer at 0xe1000000, 0x300000 bytes
simple-framebuffer simple-framebuffer.0: format=a8r8g8b8, mode=1024x768x32, linelength=4096
fbcon: Deferring console take-over
simple-framebuffer simple-framebuffer.0: fb0: simplefb registered!
fbcon: Taking over console
Console: switching to colour frame buffer device 128x48
systemd: Started Dispatch Password Requests to Console Directory Watch.
nvidia: loading out-of-tree module taints kernel.
nvidia: module license 'NVIDIA' taints kernel.
nvidia-nvlink: Nvlink Core is being initialized, major device number 248
nvidia 0000:08:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem
NVRM: loading NVIDIA UNIX x86_64 Kernel Module 510.47.03 Mon Jan 24 22:58:54 UTC 2022
nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 510.47.03 Mon Jan 24 22:51:43 UTC 2022
[drm] [nvidia-drm] [GPU ID 0x00000800] Loading driver
caller os_map_kernel_space.part.0+0x6d/0x90 [nvidia] mapping multiple BARs
[drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:08:00.0 on minor 0
The only difference is that I now cannot unload the nvidia kernel module which was possible before.
What am I doing wrong or misunderstanding? I thought the text console would switch to my native monitor resolution and switching between it and X.org will be near instant.
The kernel seemingly supports all the required features:
$ grep CONFIG_DRM config | egrep -v "^#"
I’m not using initrd/initramfs.
Found this post: Kernel mode setting does not work in CONSOLE mode under linux - #4 by aplattner is it still relevant? It’s kinda sad if it is.
And then there’s SIMPLEDRM which should work and I’m getting lost: 510.39.01 on 5.16.0 kernel green screen - #19 by BCS
It’s not enabled for my Linux config.
(Talking about x86 here, keep in mind other arches exist)
The console/VT is still the old linux framebuffer console (fbcon)
which runs on a simple framebuffer device (fbdev).
The fbdev would usually be provided by the bios’ vga or efi framebuffer (over some in-kernel fb driver).
DRM drivers have the possibility to provide a drm based fbdev emulation, like in i915:
Which can be turned on/off by CONFIG_DRM_FBDEV_EMULATION=y
NB: the kconfig setting does not provide a general drm fbdev emulation but only enables it in the gpu specific drm driver, if available. You’ll then see in dmesg:
fb0: switching to inteldrmfb from EFI VGA
The nvidia drm driver does not provide a drm fbdev emulation so the fbcon will stay on e.g. efifb.
In general, there are more-or-less ongoing works/rfcs over the past decade or so to get rid of fbdev/fbcon/CONFIG_VT altogether and replace them with something drm only. Some recent discussion, which provides a good insight:
simpledrm is rather the opposite of this, it provides a minimal drm driver running on the bios provided framebuffer (EFI/VGA) to have a fallback driver for wayland in case no gpu specific drm driver is available. See it as a vesa driver for wayland.
modeset=1 doesn’t actually install a framebuffer console. All it really does is enable the
DRIVER_MODESET capability flag in the nvidia-drm devices so that DRM clients can use the various modesetting APIs. In addition to allowing clients that talk to the low-level DRM interface to work, it’s also necessary for some PRIME-related interoperability features.
The downside, if you want to call it that, is that loading nvidia-drm with
modeset=1 causes it to configure and initialize all GPUs immediately rather than waiting for a client to open the
/dev/nvidia* device files. This means that some options that require a userspace application to configure them before the GPUs are initialized won’t work if they were already configured by nvidia-drm. The big example at the moment is SLI Mosaic, which is enabled by the X driver if /etc/X11/xorg.conf says it should be.
Which should also be noted in the Mosaic chapter of the manual since often this happens:
It’s noted in the drm kms chapter but nobody that’s affected finds it there.
Are there any plans (I know I know you cannot talk about the future) to enable fb emulation in NVIDIA drivers, so that I could run my text console at a native resolution?
BTW, I’ve still noticed a single positive change: resume is now quite faster. Previously it took 2-3 seconds, now I get my Xorg’s unlock screen almost instantly after I resume. I wonder if it’s real or I’m imagining things.
Can’t mark two replies as answers so I’ll just say big thank you!
Not currently, since installing a framebuffer console pins the kernel modules so they can’t be unloaded. We still (for better or worse) support shutting down GPU clients, unloading the kernel modules, installing a different driver, and starting everything back up without rebooting. If nvidia-drm is always in use because it’s driving a framebuffer console, then that won’t work.
It’s theoretically possible to remove the framebuffer console device in order to unload nvidia-drm.ko, but there’s no mechanism for the system to switch back to something like simplefb or efifb so the console just goes blank if you do that.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.