You are not logged in.
@letterlock You've gotten me the closest to fixing this problem so far, I've tried what feels like everything.
My setup is as follows:
GPU: NVIDIA 1660Ti
3 monitors
Right/Left are both 2560x1440@165
Above Right is: 1920x1080@60
All three monitors are on DisplayPort.
My boot setup consists of:
Bootloader: systemd-boot
Fast Boot enabled in the UEFI firmware settings, and Secure Boot enabled and working correctly via sbctl
Unified Kernel Images with kernel cmdlines set through /etc/kernel{cmdline,fallback_cmdline}
mkinitcpio.conf
MODULES=(btrfs vfio_pci vfio vfio_iommu_type1 nvidia nvidia_modeset nvidia_uvm nvidia_drm)
BINARIES=(/usr/bin/btrfs /usr/bin/setfont) - (setfont is in here from some pre-userspace testing)
FILES=(/usr/lib/firmware/edid/omen_left.bin /usr/lib/firmware/edid/omen_right.bin /usr/lib/firmware/edid/samsung_top.bin)
HOOKS=(base systemd plymouth autodetect microcode modconf keyboard sd-vconsole block sd-encrypt filesystems fsck)/etc/kernel/cmdline:
rd.luks.name=d20d44cf-fa3b-47f6-bb6f-3e1ed620ed81=cryptlvm root=/dev/mapper/cryptlvm rootfstype=btrfs rootflags=subvolid=393 vfio-pci.ids=10de:2487,10de:228b drm.edid_firmware=DP-0:edid/omen_left.bin,DP-4:edid/omen_right.bin,DP-2:edid/samsung_top.bin loglevel=3 quiet splash rw/etc/kernel/fallback_cmdline boots to systemd.unit=rescue.target with loglevel=4 and no quiet or splash, the rest is the same
Kernel: linux-zen 6.11.5-zen1-1-zen
NVIDIA Driver: nvidia-dkms 560.35.83.18 (dkms required because of zen kernel)
Modes are forced with EDID files exported from nvidia-settings as you can see with my mkinitcpio FILES tag and my kernel command line.
Display manager - tty based: ly
I have tried:
console-mode max - in /boot/loader/loader.conf
as well as setting various forms of the video= kernel parameter to no avail.
The only thing that has worked for me so far is doing what @letterlock said in their most recent post, setting up a systemd service at boot time required by multi-user.target that runs:
fbset -xres 2560 -yres 1440I've avoided trying @letterlock's method of using ddcutil so far (as they metioned it could brick your monitors), but the only problem I have left is that my 1920x1080 monitor now has the console outside of its bounds due to the manual fbset at boot to a higher resolution than it is capable of.
X11 does not listen to what the console is set to, and everything past logging in at the ly login prompt works perfectly. In that vane this problem could be ignored if I switched to an X/Wayland based display manager, but I like ly.
If I can figure out how to set that monitor back to 1920x1080 and still keep 2560x1440 on my other two monitors in ly at boot I'll be golden, I just don't think it's possible at this point.
At any rate, thanks again @letterlock, you've gotten me to the last roadblock for my setup lol
Last edited by aerofractal (2024-10-27 00:37:07)
Offline
I'm glad I could help!
I've avoided trying @letterlock's method of using ddcutil so far (as they metioned it could brick your monitors), but the only problem I have left is that my 1920x1080 monitor now has the console outside of its bounds due to the manual fbset at boot to a higher resolution than it is capable of.
Regarding this - I personally had no issue using it and mostly mentioned the bricking possibility because I didn't want someone just running the commands I posted without reading up on the utility first. I wanted to stress that the possibility was there but maybe should have made it more clear that if you do some careful reading of the man pages for ddcutil and are only using the settings the monitor itself reports you should be fine. I think when you're at the level of exporting custom EDID files (even if they were auto generated), there isn't that much danger, but obviously its good to take what any random forum user says with a healthy dose of salt.
My understanding of the utility is that all of the commands I mention up until:
ddcutil setvcp [XX] [YY] --display [DISPLAY NUMBER]are safe to run with no possibility of bricking, because they're just doing very basic querying of the monitor's capabilities. The ones after can potentially brick things because they can tell the monitor to do something it can't do, or things could be improperly labeled in a very stupid way. When I queried the monitor I got back fairly clear power state options, and the biggest risk that I could find was having to manually turn the monitor back on because I set it to fully power down instead of go to sleep (it isn't going to receive commands if its fully shut off).
However, speaking of custom EDID files -- I don't know how they might affect ddcutil, so if you end up wanting to try the above or anything like that, I would run the querying steps with both the factory setup and with the custom EDID files to see if there is any difference in the output.
X11 does not listen to what the console is set to, and everything past logging in at the ly login prompt works perfectly. In that vane this problem could be ignored if I switched to an X/Wayland based display manager, but I like ly.
If I can figure out how to set that monitor back to 1920x1080 and still keep 2560x1440 on my other two monitors in ly at boot I'll be golden, I just don't think it's possible at this point.
This was basically my exact problem, and what ended up making me resort to just shutting the dang thing off and turning it back on with ddcutil. At the end of the day, the FB console/TTY/whateveryouwannacallit is just not built for multihead (as far as I can tell, if someone knows otherwise PLEASE prove me wrong) and therefore we'll always run into a jam unless we remove one of the problematic factors (the console itself or the offending monitor).
If you end up finding a solution/workaround or even if you just make some progress, I would be very interested to hear about it.
Offline