Console is worst available resolution when booting w/multiple monitors

scot · 2026-01-16 00:19:41

This is in fact a continuation of this post. But that post is so confused that even the question is wrong.
Background: I have a Dell XPS 9500, which is an optimus machine with both an integrated Intel i915 and an NVIDIA GeForce GTX 1650 Ti Mobile.
I have two external monitors attached:
one has resolution 1920x1080 and HDMI, and is attached directly to a USB-C socket on the laptop;
one has resolution 3840x2160 and DIsplayPort, and is attached to a DisplayPort socket on a Dell WD19 dock; the dock is attached via Thunderbolt to the Thunderbolt (USB-C) socket on the other side of the laptop.
The built-in screen is 3840x2400.
I load KVM early: the first line of my mkinitcpio.conf file is

MODULES=(btqca nvidia nvidia_modeset nvidia_uvm nvidia_drm)

The issue is this:
If i boot with no external monitors attached, I get a console that uses the full 3840x2400 resolution of the laptop screen, with 248 lines.

But if I boot with either or both external monitors attached, the text console has the resolution of the lowest-rez screen. The console is letterboxed on the higher-rez screens. For example, if I boot with the 1920x1080 monitor attached, the console fills the low-rez screen, has only 80 lines, and fills only a small corner on the high-rez screen.

Now I know that there must be some way to configure things so that even when I boot with all screens, fbset will give me a geometry of 3840x2160. I know this because I can boot with no screens attached, get the fbset that I want, then attach the monitors and connect them, and the console is still high-rez. BUT I can't for the life of me figure out how to boot with the screens attached and working and still have the framebuffer be

 mode "3840x2160"

(i.e. the mode that that it configures itself to have when no external screens are attached).

The best that I've been able to manage is to have this as my kernel option line in /boot/loader/entries/arch-linux.conf:

options root="UUID=c119.....82b54e" rw ibt=off intel_iommu=on iommu=pt  nvidia-drm.fbdev=1  nvidia-drm.modeset=1  video=DP-3:d  video=DP-1:d

These last two options effectively boot with the external monitors disconnected, and then I have to turn them on with

 echo on > /sys/kernel/debug/dri/2/DP-3/force

I have tried adding video=eDP-1:9.216MA as a kernel parameter or video=eDP-1:3840x2160@60 and 1000 other things. Is there some way to boot up and have the console framebuffer be the highest resolution of the monitors attached and not the lowest one?

Thank you !

Last edited by scot (2026-01-21 07:10:39)

seth · 2026-01-16 14:39:01

Fix your shift key…

If you're running outputs at different resolutions one of two things will happen.
1. The framebuffer console is at the lower resolution, you get black right and bottom borders on the output w/ the higher res
2. The framebuffer console is at the larger resolution, it will flow out of the output w/ the lower res (ie. text at the right and bottom will not be visible on those monitors)

For the latter try to simply set the video mode w/o output specifier "video=3840x2160" but mind you that the bottom of the console is where you enter commands!
You can use fbset to test this interacively.

tekstryder · 2026-01-16 18:47:13

scot wrote:

Now I **KNOW** that there must be SOME way to configure things so that even when I boot with all screens, fbset will give me a geometry of 3840x2160. I know this because I can boot with no screens attach, get the fbset that I want, then attach the monitors and connect them, and the console is still high-rez. BUT I can't for the life of me figure out how to boot with the screens attached and working and still have the framebuffer be
 mode "3840x2160" 
that it configures itself.

You're on the right track.

After we finally got multi-monitor console framebuffer support fixed by Nvidia., I also needed to solve this same issue.

The easiest solution for me was to create a simple systemd oneshot service as I explain on the Nvidia forum for another user here:

• https://forums.developer.nvidia.com/t/5 … tekstryder

Substitute 3840x2160 for the fbset resolution, and I have my primary display at native resolution in the console.

This also provides seemless switching between TTYs/compositors without triggering unwanted modesets.

scot · 2026-01-21 07:53:22

seth wrote:

simply set the video mode w/o output specifier "video=3840x2160"

This does not work for me: if I change the line of kernel options in /boot/loader/entries/arch.com from the one listed in the opening post of this thread to the following:

options root="UUID=c119.....82b54e" rw ibt=off intel_iommu=on iommu=pt  nvidia-drm.fbdev=1  nvidia-drm.modeset=1  video=3840x2400

the result is identical to what i get when there is no "video=...." option at all -- namely, the resolution of the text console is that of the lowest-rez monitor attached at boot time. Perhaps this is the result of some other mistake I've made; I'll be happy to post any diagnostic output that might explain why this is what happens and not what seth asserted would happen.
I will try tekstryder's suggestion next.

seth wrote:

mind you that the bottom of the console is where you enter commands!

Of course. But 3840x2400 is the (native) resolution of the built-in laptop screen, which is always connected. All I'm trying to do is to ensure that I can use the built-in screen as console as productively as possible, no matter what other screens are attached to the laptop at boot time.

seth wrote:

Fix your shift key…

I had to reread my post 5-10 times before I had even a vague guess about what you meant. My vague guess is that just as almost anyone would find it annoying if my post was written with all caps, AS IF I WERE SHOUTING, you found it annoying that I capitalized even just 3-4 words; perhaps you'll find it even more annoying when i tell you that I did that entirely intentionally -- not to annoy, of course, but just to mimic the kind of emphasis I would have used for those words when speaking. If my guess is correct, then please know that my intent was not to annoy, and I have edited the post to use BBC code instead of all-caps (as well as to correct a few typos). I hope you now consider the shift key "fixed."

Anyway, the essence of this post is that seth's suggestion did not work for me, I'll post next about tekstryder's.

seth · 2026-01-21 09:38:50

Also please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

@tekstryder, hybrid graphics or do the nvidia modules categorically override/ignore the video parameter?

Last edited by seth (2026-01-21 09:39:24)

tekstryder · 2026-01-21 18:17:25

video= parameters get stomped early from my experience. I don't care about initram resolutions as I don't hang out there long.

The OP has demonstrated that manual fbset produces the desired outcome, and has the nv modules loaded early.

Nvidia should™ grab the fbcon framebuffer early enough, followed by the oneshot fbset, before console login.

EDIT: OP could also remove obsolete, but harmless, kernel params for ibt and nvidia just to tidy up.

Last edited by tekstryder (2026-01-21 18:30:15)

scot · 2026-01-25 10:23:07

Apologies for the delay in my reply here; I was laid VERY low by the worst flu of my life (and yes, I was vaccinated; if the vaccine did attenuate the disease, i'm honestly not sure I would have made it through unvaccinated ).

First, @seth: I have posted THREE different system journal boot records:

http://0x0.st/PZyk.txt -- "video=3840x2400" is specified as kernel option, and two lower rez external monitors
are attached at boot. Text console is low-rez (I believe 1920x1080, that of lowest rez
monitor)
http://0x0.st/PZyF.txt -- NO "video= " kernel option is specified, and two lower rez external monitors
are attached at boot. Text console is low-rez (I believe 1920x1080, that of lowest rez
monitor)
http://0x0.st/PZt8.txt -- NO "video= " kernel option is specified, and NO external monitors are attached at
boot. Text console is 3840x2400, the native resolution of the built-in laptop screen

Second, @tekstryder -- I can confirm that your Oneshot service does the trick; I did all the simplifications you suggested in your Nvidia forum post. Just to save a future reader from having to wade through the discussion there -- your solution is to create a oneshot service as follows: create a file in /etc/sysystemd/system with a service name of your choosing, I'll use console-rez.service:

$ cat /etc/systemd/system/console-rez.service 
[Unit]
Description=Set framebuffer resolution

[Service]
Type=oneshot
ExecStart=/usr/bin/fbset -xres 3840 -yres 2400 -match --all

[Install]
WantedBy=multi-user.target

(in the above file, substitute the horizontal and vertical resolution you desire for "3840" and "2400").

Enable the service:

$ sudo systemctl enable console-rez.service

(obviously, using the name you chose for the service file) and reboot.

Please allow me a tiny nit question about this solution: with it in place, when the machine boots, the text console starts out at the lower resolution, and then at some point during the boot process the service executes and the framebuffer/console fills the whole screen. I note that when no external monitor is attached, the framebuffer and console use the large full resolution from the very beginning. It's fine as is, but is there some way to have the full resolution from the beginning? Would adding

Before=sddm.service

to the Unit section do this? Is this safe?

Lastly: Since this thread now has a solution to my problem, I'll tag it as [SOLVED], although I certainly am interested to learn if there is something to seth's

video=3840x2400

kernel option suggestion (for example, perhaps I am doing something that prevents that from working).

Thank you both!

seth · 2026-01-25 14:07:33

From http://0x0.st/PZyk.txt ("video=3840x2400" is specified as kernel option, and two lower rez external)

Jan 25 10:37:16 scott-xps9500 kernel: simple-framebuffer simple-framebuffer.0: [drm] Registered 1 planes with drm panic
Jan 25 10:37:16 scott-xps9500 kernel: [drm] Initialized simpledrm 1.0.0 for simple-framebuffer.0 on minor 0
Jan 25 10:37:16 scott-xps9500 kernel: simple-framebuffer simple-framebuffer.0: [drm] User-defined mode not supported: "3840x2400": 60 793744 3840 4160 4584 5328 2400 2401 2404 2483 0x20 0x6
Jan 25 10:37:16 scott-xps9500 kernel: simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device
Jan 25 10:37:16 scott-xps9500 kernel: [drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver
Jan 25 10:37:16 scott-xps9500 kernel: [drm] Initialized nvidia-drm 0.0.0 for 0000:01:00.0 on minor 1
Jan 25 10:37:16 scott-xps9500 kernel: nvidia 0000:01:00.0: [drm] No compatible format found
Jan 25 10:37:16 scott-xps9500 kernel: nvidia 0000:01:00.0: [drm] Cannot find any crtc or sizes
Jan 25 10:37:16 scott-xps9500 kernel: i915 0000:00:02.0: [drm] Found cometlake (device ID 9bc4) integrated display version 9.00 stepping N/A
Jan 25 10:37:16 scott-xps9500 kernel: i915 0000:00:02.0: [drm] VT-d active for gfx access
Jan 25 10:37:16 scott-xps9500 kernel: i915 0000:00:02.0: [drm] User-defined mode not supported: "3840x2400": 60 793744 3840 4160 4584 5328 2400 2401 2404 2483 0x20 0x6
Jan 25 10:37:16 scott-xps9500 kernel: i915 0000:00:02.0: [drm] User-defined mode not supported: "3840x2400": 60 793744 3840 4160 4584 5328 2400 2401 2404 2483 0x20 0x6

1. hybrid graphics
2. no output attached to the nvidia GPU
3. nvidia and i915 are both in the initramfs, nvidia loads first
4. 3840x2400 isn't a supported mode - is your monitor actually that or 3840x2160 ?

for OUT in /sys/class/drm/card*; do echo $OUT; edid-decode $OUT/edid; echo "================="; done

You'll need https://archlinux.org/packages/extra/x86_64/v4l-utils/

tekstryder · 2026-01-25 19:37:26

scot wrote:

substitute the horizontal and vertical resolution you desire for "3840" and "2400"

I'm jealous. I wish large (30 inch) 16:10 WQUXGA displays were prevalent. I'd buy two.

scot wrote:

a tiny nit question about this solution: with it in place, when the machine boots, the text console starts out at the lower resolution, and then at some point during the boot process the service executes and the framebuffer/console fills the whole screen.

tekstryder wrote:

I don't care about initram resolutions as I don't hang out there long.

I never bothered to try to get this applied earlier in the boot process.

I can live with the LUKS password prompt in the smaller viewport of my primary monitor before the oneshot fbset.

I also have a discrete GPU, so no nvidia modules in my initramfs. Late loading is fine here as I do not use a display manager.

scot wrote:

I note that when no external monitor is attached, the framebuffer and console use the large full resolution from the very beginning.

That's expected.

scot wrote:

is there some way to have the full resolution from the beginning? Would adding
Before=sddm.service
to the Unit section do this? Is this safe?

The display manger is even later than the oneshot's multiuser target. You'd need to bake this into the initramfs.

scot wrote:

I certainly am interested to learn if there is something to seth's video=3840x2400 kernel option suggestion

Try it and see what happens. That was the first route I took, but...

tekstryder wrote:

video= parameters get stomped early from my experience.

Last edited by tekstryder (2026-01-25 19:40:59)

tekstryder · 2026-02-05 20:12:17

scot wrote:

@tekstryder -- I can confirm that your Oneshot service does the trick
Since this thread now has a solution to my problem, I'll tag it as [SOLVED]

Please do so if you've no further questions.

Arch Linux

#1 2026-01-16 00:19:41

Console is worst available resolution when booting w/multiple monitors

#2 2026-01-16 14:39:01

Re: Console is worst available resolution when booting w/multiple monitors

#3 2026-01-16 18:47:13

Re: Console is worst available resolution when booting w/multiple monitors

#4 2026-01-21 07:53:22

Re: Console is worst available resolution when booting w/multiple monitors

#5 2026-01-21 09:38:50

Re: Console is worst available resolution when booting w/multiple monitors

#6 2026-01-21 18:17:25

Re: Console is worst available resolution when booting w/multiple monitors

#7 2026-01-25 10:23:07

Re: Console is worst available resolution when booting w/multiple monitors

#8 2026-01-25 14:07:33

Re: Console is worst available resolution when booting w/multiple monitors

#9 2026-01-25 19:37:26

Re: Console is worst available resolution when booting w/multiple monitors

#10 2026-02-05 20:12:17

Re: Console is worst available resolution when booting w/multiple monitors

Board footer