Loading nvidia_drm module changes the tty resolution

When the kernel is loaded with nvidia_drm.fbdev=1, nvidia_drm module changes resolution of frame buffer from native 3840x2160 to 1920x1080. Only left upper quarter of screen is used to display text console. Also my default terminus console font 32x16 resets to default 16x8.

OS: Fedora 43

Kernel: 6.18.3-200.fc43.x86_64

Driver: 580.119.02

When fbdev=1 is enabled, the console resolution is determined by the fbdev code in the kernel’s DRM subsystem. Do you have a second monitor connected? The behavior you’re seeing is what the kernel does when you have two monitors of different resolutions attached.

Yes, this is normal behavior when you have a 3840x2160 and a second 1920x1080 monitor attached. Framebuffer TTY does not do DPI matching. And it probably never will, either.

Worse still, KMSCON, an alternative that some distributions are just starting to finally package, doesn’t do mixed DPI either, as far as I know. It does mixed resolutions, but it has a single global font size.

Yes, I have second monitor with 1920x1080 resolution. When I disconnect it, the console resolution remains 3840x2160. Is it possible to set 3840x2160 when a second monitor is connected?

you can use fbdev to set resolution to 4k, your tty on your other monitor will be too large but its a non-issue compared to previous behaviour. I shared my solution here: hosts/fazziPC/displays.nix · 430c95b737f587f235d3c930c3d40975db66d3ce · fazzi / NixOhEss · GitLab

related nvidia forum post: NVidia fbdev does not use correct screen resolution / primary monitor on multi monitor setups - #13 by Tekstryder

What is this file for? How to use it? I see fbset in it. It was removed from the official Fedora repository many years ago. I tried using it from third party repository and was getting error about missing /dev/fb*.

As one of my posts was linked here, I’ll chime in with a few more relevant links.

This topic comes up occasionally. Recently helped another Arch user here:

And another relevant Nvidia forum thread here:

A oneshot fbset service still the simplest solution I know of.

I’m not a Fedora guy, but there must be a repo build somewhere or easy enough to just package it yourself.

Writing a systemd service isn’t a problem. The problem is switching to the right resolution. I installed fbset from a third-party repository. Result:

> fbset -xres 3840 -yres 2160
open /dev/fb0: No such file or directory
> find /dev -name '*fb*'
>

What am I doing wrong?

fbset -xres 2560 -yres 1440 -match --all

Is your kernel compiled without framebuffer support?

❯ zgrep _FB /proc/config.gz 

EDIT: Hmm, you’ve already demonstrated an active fbcon with having the viewport described in your OP.

Let’s see:

❯ journalctl -b -g fbcon

It’s the newest kernel of Fedora 43 (6.18.6-200.fc43.x86_64):

> zgrep _FB /proc/config.gz
gzip: /proc/config.gz: No such file or directory
> grep _FB /boot/config-`uname -r`
# CONFIG_FBNIC is not set
CONFIG_VIDEO_FB_IVTV=m
# CONFIG_VIDEO_FB_IVTV_FORCE_PAT is not set
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_FBDEV_OVERALLOC=100
# CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is not set
CONFIG_DRM_CLIENT_DEFAULT_FBDEV=y
CONFIG_FB=y
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_UVESA is not set
CONFIG_FB_VESA=y
CONFIG_FB_EFI=y
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_OPENCORES is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I740 is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_SM501 is not set
# CONFIG_FB_SMSCUFX is not set
# CONFIG_FB_IBM_GXT4500 is not set
# CONFIG_FB_VIRTUAL is not set
CONFIG_XEN_FBDEV_FRONTEND=y
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_HYPERV is not set
# CONFIG_FB_SSD1307 is not set
# CONFIG_FB_SM712 is not set
CONFIG_FB_CORE=y
CONFIG_FB_NOTIFY=y
# CONFIG_FB_DEVICE is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYSMEM_FOPS=y
CONFIG_FB_DEFERRED_IO=y
CONFIG_FB_DMAMEM_HELPERS=y
CONFIG_FB_DMAMEM_HELPERS_DEFERRED=y
CONFIG_FB_IOMEM_FOPS=y
CONFIG_FB_IOMEM_HELPERS=y
CONFIG_FB_SYSMEM_HELPERS=y
CONFIG_FB_SYSMEM_HELPERS_DEFERRED=y
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
CONFIG_HID_PICOLCD_FB=y
# CONFIG_FB_SM750 is not set
> journalctl -b -g fbcon
Jan 28 20:20:39 kernel: fbcon: Deferring console take-over
Jan 28 20:20:39 kernel: fbcon: Taking over console
Jan 28 20:20:43 kernel: fbcon: nvidia-drmdrmfb (fb0) is primary device
> fbset -xres 2560 -yres 1440 -match --all
open /dev/fb0: No such file or directory

Interesting. I see CONFIG_FB_DEVICE is not set, but I think that’s legacy.

Does the device at least exist in sysfs (kernel side)?

ls -la /sys/class/graphics/

If so, what’s there?

Also, maybe udev issue?

grep -r fb /etc/udev/rules.d/
grep -r fb /usr/lib/udev/rules.d/
> ls -la /sys/class/graphics/
total 0
drwxr-xr-x  2 root root 0 Jan 29 00:00 .
drwxr-xr-x 68 root root 0 Jan 29 00:00 ..
lrwxrwxrwx  1 root root 0 Jan 29 00:00 fbcon -> ../../devices/virtual/graphics/fbcon
> grep -r fb /etc/udev/rules.d/
> grep -r fb /usr/lib/udev/rules.d/
/usr/lib/udev/rules.d/71-seat.rules:SUBSYSTEM=="graphics", KERNEL=="fb[0-9]*", TAG+="seat"
/usr/lib/udev/rules.d/71-seat.rules:# Allow efifb / uvesafb to be a master if KMS is disabled
/usr/lib/udev/rules.d/71-seat.rules:SUBSYSTEM=="graphics", KERNEL=="fb[0-9]", IMPORT{cmdline}="nomodeset", TAG+="master-of-seat"
/usr/lib/udev/rules.d/71-seat.rules:# Synthesize a seat for graphic devices without DRM and that fall back to fb
/usr/lib/udev/rules.d/71-seat.rules:SUBSYSTEM=="graphics", KERNEL=="fb[0-9]*", ATTRS{modalias}=="?*", IMPORT{builtin}="hwdb fb:$attr{modalias}"

It seems too coincidental that Fedora no longer packages fbset && your kernel lacks CONFIG_FB_DEVICE.

Any chance you can compile a kernel withCONFIG_FB_DEVICE=y baked in?

EDIT: See also my post here:

Perhaps try the workaround I was employing (“Scenario 2”) while testing the in-development kernel module when we were trying to get multi-monitor framebuffer support for mismatched native resolutions working in the driver.

Yes, many years ago they switched to simpledrm.

I can do it, but I won’t because I prefer regular updates and avoid regular builds. It’s enough that the kernel doesn’t have an nvidia driver and it has to be rebuilt with every update. Fortunately, akmods does this automatically for many years. There are no such problems with ATI and Intel.

You’re about module patch? It’s unacceptable to do this with every update.

Now I use nvidia-drm.fbdev=0 to avoid the problems described in the first message.

What are the advantages of using nvidia-drm.fbdev=1?

That was only during testing before a new driver release which fixed this.

Previously, booting an Nvidia system with multiple displays with mismatched resolutions resulted in a blank screen.

Well, that’s fine if you don’t care to have a native resolution framebuffer.

  • Full native (3840x2160) console framebuffer on the the higher resolution, and typically primary, display.
  • No modesetting delays when switching between TTYs.

Yes, this is acceptable.

I set the native resolution 3840x2160 in grub and it does not change during and after boot with nvidia-drm.fbdev=0.

When I switch virtual console from Xorg to TTY or back, my monitor goes blank for a second, both in the case of nvidia-drm.fbdev=0 and in the case of nvidia-drm.fbdev=1.

Yup, Expected if you’re not using the Nvidia fbcon.

Yup, Expected if you’re not using the Nvidia fbcon.

Pretty sure I addressed both of these two concerns succinctly:

If you’re knowledgeable and capable enough to do so, testing a kernel built as suggested, combined with enabling the Nvidia fbcon via nvidia_drm.fbdev=1, could at least provide an answer to this thread.

Do I understand correctly that you are suggesting to compile the kernel with CONFIG_FB_DEVICE=y and boot with nvidia_drm.fbdev=1 for testing?

Yes, correct. Ensure you’re modifying only your existing, running kernel config (copy) with the single option.

make olddefconfig, or whatever mechanism is used with Fedora builds by default, would pick up any other related config options that need modification automatically… if any.

Looking at the config grep you provided upthread, it’s likely just that single option.

This is simply my theory you’d be testing. Regardless, a good data point toward a solution.

I compiled the kernel from Fedora repo with CONFIG_FB_DEVICE=y. Configs are the same except for this option. Now I have framebuffer device. But:

> ls -l /dev/fb*
crw-rw---- 1 root video 29, 0 Jan 30 01:35 /dev/fb0
> modprobe nvidia
modprobe: ERROR: could not insert 'nvidia': No such device
> modprobe nvidia-modeset
modprobe: ERROR: could not insert 'nvidia_modeset': No such device
> modprobe nvidia-peermem
modprobe: ERROR: could not insert 'nvidia_peermem': Invalid argument
> modprobe nvidia-uvm
modprobe: ERROR: could not insert 'nvidia_uvm': No such device