NVidia fbdev does not use correct screen resolution / primary monitor on multi monitor setups

Graphics / Linux Linux
1

On multi-monitor setups, Nvidia drivers, including fbdev, assign monitors incorrectly. For instance, my 1440p primary monitor gets ID 1, while my 1080p secondary monitor gets ID 0. Swapping ports does make the 1440p monitor have ID 0, but puts the BIOS and systemd boot menu on the secondary monitor, which I don’t want.

This becomes problematic with Wayland and fbdev, as Wayland lacks an easy way to set a default monitor. This causes Xwayland games to start in 1080p with no option to scale up, sometimes locking the FPS to the refresh rate of the secondary monitor (75Hz).

In short, there’s no way to:

  • Assign ID 0 to the main monitor
  • Have the BIOS and systemd boot on the main monitor

It’s always one or the other. Here’s an image showing fbdev using the secondary monitor’s resolution, resulting in a low resolution and small font on the main monitor.

image
image1724×1298 200 KB

Ideally, fbdev should prioritize the monitor displaying the BIOS and systemd boot. Disabling fbdev resolves this, launching the TTY in 1440p on the main monitor, but with its ID still as 1 instead of 0.

2

still occuring with the nvidia 565 drivers. nvidia team, any update on this simple issue? affecting windows also

3

I believe this might be the cause to what I am experiencing here: when I boot with fbdev=1 and without an external monitor plugged to Nvidia dGPU, no output goes to the built-in display (controlled by AMD iGPU). At first I thought it was a hardware problem, but then I tried it with the external monitor, and I realized the output was going only to the dGPU.

4

Workaround no longer works with 6.12 kernel and I’m now stuck with low res tty.

Any update would be appreciated

5

update:

seems issue stems from the fact that there isn’t proper fbdev resolution control. Running cat /sys/class/graphics/fb0/modes will give me U:1920x1080p-0 which is wrong, it should be 1440p.

nvidia team, any update?

6

Still seems to be occurring on 570.133.07.

Has a bug been filed? Now that fbdev is default its a regression compared to previous behaviour.

Previously the TTY would only show on my main, 1440p monitor, and at the correct resolution.

With fbdev however, the TTY shows on both monitors but now at the wrong resolution on my main, 1440p monitor. This causes a very large portion of my screen to become unusable as shown in those original screenshots.

It’s placing the contents of the 1080p monitor in the corner of my 1440p. Instead it should be scaling my 1440p monitor down to 1080p and showing it on my secondary, OR my secondary monitor should be blank.

1 Like
7

Issue still occuring on 575.64.03. Whats also annoying is it seems nvidia fbdev driver does not seem to respond to any sort of video kernel parameters I have set. I thought I’d be able to force a mode through those but I guess not.

8

See: Nvidia driver isn't compatible with simpledrm so boot output and TTYs are blank - #40 by Tekstryder

The driver patch that will land in 580 essentially only got me to the issue you’re describing.

You could try my described workaround (scenario #2).

9

580? do you have access to the driver?

10

Of course not. It doesn’t exist yet.

Did you read the thread I linked? I built the module with the patch provided there.

Unless you have an older (pre-Pascal) GPU that would be irrelevant to your case.

My point was as stated…

…to see if you get a better fbcon resolution combo than you’ve described upthread.

11

This behavior is all controlled by the kernel’s DRM subsystem. By default it loops over all connected monitors, finds the maximum dimensions of the modes supported on them, allocates a framebuffer that size, and then configures the console for the minimum of the enabled monitor dimensions. The nvidia-drm driver is just plugging all of the connected monitor information into DRM and then letting DRM handle the configuration. As far as I know, nothing about the way this behaves is specific to the NVIDIA driver.

If you want it to have different behavior, you’ll need to look at the configuration options the kernel provides.

12

hi there, thanks for your reply.

the issue is that the behaviour when using fbdev=0 is not the same as the behaviour of fbdev=1.

I showcased in the original post that with fbdev=0, the console would be 2560x1440, with it scaled down to fit on the 1080p monitor.

However, with fbdev enabled it’s the case that the console is 1920x1080, and left unscaled on both monitors. This causes the console to be confined to a space on the top left corner of the larger resolution monitor.

Are you saying that there are kernel options to mimic the behaviour i see without fbdev?

13

This is the viewport issue I worked around.

Did you try booting with the lower resolution display unplugged initially?

I’m curious of the same, and also asked the same question.

I’ve fiddlefucked with just about every conceivable combo of kernel video= parameters.

The fact that I can get the kernel to keep my higher-res display at native fullscreen resolution fbcon via workaround suggests it must be possible.

I’ve tried each of these individually, both with and without nVidia modules in my initramfs:

nvidia_drm.modeset=1
nvidia_drm.fbdev=1
nvidia_drm.modeset=1 nvidia_drm.fbdev=1
video=DP-1:2560x1440@60
video=DVI-D-1:3840x2160@60
nvidia_drm.modeset=1 video=DVI-D-1:2560x1440@60,3840x2160
video=DP-1:3840x2160@60 video=DVI-D-1:3840x2160@60e fbcon=map:0

I’ll buy a beer for anyone who can give me native res fullscreen nvidia-drmdrmfb fbcon on my primary monitor whilst the secondary lower-res display is connected. I don’t care if that screen displays nothing, an oversized viewport, or cat pics.

14

Not looking for beer but I was actually able to resize the framebuffer to make it fit my 1440p monitor. Appears oversized on my other monitor tho not a huge deal.

Config here: hosts/fazziPC/default.nix · main · fazzi / NixOhEss · GitLab

It’s simply just a systemd service which runs fbset at boot. No extra config was required actually :)

I also set video params just above, don’t think it matters though unless your monitors don’t actually use their native res by default.

Let me know how it goes

- faz

1 Like
15

Thanks for providing that. I hadn’t messed with fbset.

I’m hoping that concept will work, if needed, once the fix for my older card lands with the 580 driver.

Currently, attempting similarly here fails:

fbset -xres 3840 -yres 2160 -match --all
ioctl FBIOPUT_VSCREENINFO: Invalid argument

Tried setting -vxres and -vyres separately as well.

Setting both displays at 2560x1440 framebuffer is still the best I can achieve.

Only losing out on primary screen real estate and living with the resolution-switching pauses.

16

Oh I’m a knucklehead. When I rebuilt the latest 575.64.03 modules today I forgot to apply the patch. D’oh.

Yes, with the patched module I can use fbset to enable fullscreen native resolution on my primary display and an over-sized viewport on the smaller display.

Effectively the exact same result as the aforementioned workaround… without unplugging anything.

Progress. This is awesome.