D’oh, of course not, sorry.
I got this to work by setting console resolution via kernel parameter!
Tested on Arch kernel 6.15.1 (so with simpledrm patch).
video=DP-1:2560x1440@60 nvidia_drm.modeset=1 nvidia_drm.fbdev=1
Setting the primary display to the resolution of the secondary allows booting with the nVidia framebuffer, switching TTYs, and full boot text after initramfs!
EDIT: This also works on my custom kernel sans simpledrm and no need for modeset of course.
Thanks so much for the tip about the display resolutions matching. That was the key clue to getting this working after almost a year.
If you are able to patch the driver for this to function with non-matching multiple display resolutions by default that would be fantastic.
Hopefully my workaround helps serve as another data point.
Um yeah. So you don’t… have a problem?
To be expected without the modules loaded.
Since I’ve demonstrated that setting the console resolution to match secondary monitor allows a fully functional nVidia framebuffer, can we now confidently track this issue as internal bug 4157529?
With having a functional fbdev=1 now, I can confirm that blocking the simpledrm device is no longer required. Nice!
As this is a known issue is there an internal bug # to reference?
If you actually want to verify the fix, you can do it by installing 575.57.08 and then building just nvidia-modeset.ko from the open source repository:
git clone --depth=1 -b nvidia-drm-fbdev-window-adjust https://github.com/aaronp24/open-gpu-kernel-modules
cd open-gpu-kernel-modules
make -j`nproc`
# from an SSH session since you'll lose your console
rmmod nvidia-drm nvidia-modeset
insmod kernel-open/nvidia-modeset.ko
modprobe nvidia-drm modeset=1 fbdev=1
Mixing modules like this is definitely not a supported configuration so I wouldn’t really recommend actually running your system this way, but it should be good enough to verify that the fix works for you.
– Aaron
Cool. Thanks!
I did it from a tmux session.
Jun 12 20:15:28 kernel: Console: switching to colour dummy device 80x25
Jun 12 20:15:28 kernel: [drm] [nvidia-drm] [GPU ID 0x00000100] Unloading driver
Jun 12 20:15:29 kernel: nvidia-modeset: Unloading
Jun 12 20:15:32 kernel: nvidia_modeset: module uses symbols nvidia_get_rm_ops from proprietary module nvidia, inheriting taint.
Jun 12 20:15:32 kernel: nvidia-modeset: Loading NVIDIA UNIX Open Kernel Mode Setting Driver for x86_64 575.57.08 Release Build (tekstryder@) Thu Jun 12 08:05:38 PM EDT 2025
Jun 12 20:15:33 kernel: [drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver
Jun 12 20:15:33 kernel: [drm] Initialized nvidia-drm 0.0.0 for 0000:01:00.0 on minor 0
Jun 12 20:15:33 kernel: nvidia 0000:01:00.0: vgaarb: deactivate vga console
Jun 12 20:15:33 kernel: fbcon: nvidia-drmdrmfb (fb0) is primary device
Jun 12 20:15:33 kernel: Console: switching to colour frame buffer device 160x45
Jun 12 20:15:33 kernel: nvidia 0000:01:00.0: [drm] fb0: nvidia-drmdrmfb frame buffer device
This is working, but should I have first booted without my workaround with kernel parameter setting the console resolution?
I think the answer is yes, so I’ll do that and edit/update…
So nice… I’m replying twice!
Confirmed this fix on vanilla kernel 6.15.2.
The nVidia framebuffer is working at the (different) native resolutions of each monitor!
Jun 12 20:41:05 kernel: Console: switching to colour dummy device 80x25
Jun 12 20:41:05 kernel: [drm] [nvidia-drm] [GPU ID 0x00000100] Unloading driver
Jun 12 20:41:05 kernel: nvidia-modeset: Unloading
Jun 12 20:41:08 kernel: nvidia_modeset: module uses symbols nvidia_get_rm_ops from proprietary module nvidia, inheriting taint.
Jun 12 20:41:08 kernel: nvidia-modeset: Loading NVIDIA UNIX Open Kernel Mode Setting Driver for x86_64 575.57.08 Release Build (tekstryder@) Thu Jun 12 08:05:38 PM EDT 2025
Jun 12 20:41:09 kernel: [drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver
Jun 12 20:41:10 kernel: [drm] Initialized nvidia-drm 0.0.0 for 0000:01:00.0 on minor 0
Jun 12 20:41:10 kernel: nvidia 0000:01:00.0: vgaarb: deactivate vga console
Jun 12 20:41:10 kernel: fbcon: nvidia-drmdrmfb (fb0) is primary device
Jun 12 20:41:10 kernel: Console: switching to colour frame buffer device 240x67
Jun 12 20:41:10 kernel: nvidia 0000:01:00.0: [drm] fb0: nvidia-drmdrmfb frame buffer device
Great, thanks for verifying! I’m going to go ahead with this fix for the upcoming 580 release.
Awesome to hear. Sadly I cannot mark a “Solution” to the thread as I’m not the OP.
But, I’ll pop back in here to confirm the fix when 580 lands.
The downstream Arch GitLab issue tracking this has been closed now following these findings.
Updated here:
Also the package maintainer for the kernel will likely drop the long-carried patch suppressing the simpledrm device when the 580 series is released.
Hi Aaron,
I ran with your patched nvidia-modeset.ko module for a few days of heavy use and several suspend/resume cycles without issue. It was flawless.
However, when I add the module to my initramfs and reboot I do have an issue.
The primary display (3840x2160) sets at its native resolution, but output is constrained to a “viewport?” area that’s less than the full screen. There’s artifacting and old buffer contents stuck on the remainder of the screen.
Not sure viewport is the correct term, but if I had to guess the operable output area on the primary display is equal to the native resolution of the secondary display (2560x1440).
The “viewport” thing is normal Linux kernel behavior. That’s actually what was causing the problem in the first place: the drm fbdev code allocates a buffer the size of the largest screen, but only draws into the section that corresponds to the smallest screen. I don’t know why the kernel isn’t clearing the portion of the surface outside the viewport, though. I’ll see if I can track that down.
Thanks! To be clear this isn’t the case when I swap the module in after booting (and 2nd monitor unplugged during the module swap).
In that case, both monitors are full resolution and displaying at native resolutions. No viewport and no artifacts (image below):
EDIT: It would be extra super cool if the fbcon could be set to just a single, specified display.
The cloning is particularly useless, but perhaps that’s outside the purview of the driver and rather the kernel’s doing per your comment above.
EDIT2: Now that I actually directed my eyeballs toward the 2nd display, it must have a (virtual?) viewport larger than its display, as some of the contents are outside of the screen bounds. This is the “better” scenario. I tried forcing it with
video= kernel param with no luck:
video=DP-1:3840x2160@60 video=DVI-D-1:3840x2160@60e fbcon=map:0
It must be possible as I’m seeing it working this way after re-plugging the 2nd display.
EDIT3:
$ cat /sys/class/graphics/fb0/modes
U:3840x2160p-0
$ cat /proc/fb
0 nvidia-drmdrmfb
With your patched module in my initramfs, the easiest way to achieve this is by booting with the 2nd monitor unplugged, then plugging it in at the console LUKS password prompt.
With or without the patch, I can set the fbcon resolution of my primary display equal to the lesser resolution of the secondary display. Unfortunately, this still causes the annoying pause during mode changes each time switching between TTY and graphical target.
Obviously in a perfect world, the framebuffer would output at each display’s native resolution.
And for my umpteenth edit of this post… I could just purchase another 4k monitor to replace the secondary display and this whole issue would be moot :)
Hi @aplattner, your patch applies cleanly against the 575.64 upstream open modules branch, so I rebuilt against kernel 6.14.11 and have continued testing.
I think I’ve exhausted all possible permutations of kernel video parameters and the best scenario I can achieve is currently is this:
Photo in previous post.
This gives me a fast-switching TTY on my primary display at its native resolution.
If you have any other ideas or changes upcoming I’m always happy to test.
The Arch nVidia package maintainer is considering taking your patch pre-580 driver release, but still not decided.
I don’t think that’s a good idea; combining the open version of nvidia-modeset.ko with the closed version of nvidia.ko was just a test. I don’t know what will break if you run the whole system that way.
Thanks, warning acked and understood!
I ran it for days without any issue under heavy use and several suspend/resume cycles. I can always revert or fix any possible fallout. Using at my own risk :)
Summarizing findings (compared to ideal) more concisely, ordered from most to least desirable.
@aplattner please let me know if the ideal scenario is achievable.
If not… is scenario #2 possible without workaround?
| Scenario | Workaround | Result |
|---|---|---|
| (1) Ideal | None | Primary: Native resolution. Fullscreen 3840x2160, No viewportSecondary: Native resolution, Fullscreen 2560x1440, No Viewport |
| (2) Patched module | Re-plug⁽¹⁾ | Primary: Native resolution, Fullscreen 3840x2160, No ViewportSecondary: Native resolution, Viewport 3840x2160 |
| (3 ) Unpatched 575 | Kernel Param⁽²⁾ | Primary: Lower resolution 2560x1440, Fullscreen, No ViewportSecondary: Native resolution, Fullscreen 2560x1440, No Viewport |
| (4) Patched module | None | Primary: Native resolution, Viewport 2560x1440, ArtifactsSecondary: Native resolution, Fullscreen 2560x1440, No Viewport |
⁽¹⁾ Re-plug: System is booted with secondary display unplugged, reconnect at LUKS console prompt
⁽²⁾ Kernel Param: Set primary display resolution to match lesser secondary (video=DP-1:2560x1440@60)
Downsides:
(1) None!
(2) Cannot see full output on secondary display as it exceeds the screen bounds. No biggie.
(3) Pauses while primary display switching resolutions between TTY and graphical targets.
(4) Smaller usable area on primary screen due to lower resolution viewport bounds. Artifacting.
nVidia internal tracking Bug #4157529
As stated, and per the 580.65.06 Beta release notes…
I can confirm this is indeed resolved at long last!
Behavior is now in exact parity with that of the nouveau driver.
Marking this issue as SOLVED.
I will update my overall tracking thread with this info as well.
Thanks so much for showing us Pascal folks some love at the end of the line driver-wise. Much appreciated!
As I’m not the OP here on this aged thread… @blucobalt if you’re still hanging around please do test and mark solved.