Hello!
I have the following monitor setup:
Office:
DP-1 - Side 1440p@60hz monitor
DP-3 - Side 1440p@60hz monitor
DP-4 - Primary 4k@240hz monitor
Downstairs:
HDMI-A-1 - AV Receiver > LG TV - Connected via fiber optic HDMI cable capable of 48gbps.
My problem is as follows, I want to choose between using the PC upstairs, or using the PC downstairs on the TV for gaming, and I encounter some issues/friction when trying to do so:
If all 4 outputs are enabled at the same time via KDE, kwin_wayland stalls hard with the following errors:
nvidia-modeset: WARNING: GPU:0: RLD advertized maximum pixel clock 230000 KHz violates maximum pixel clock constraint for HDMI
"kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated."
"kwin_scene_opengl: Invalid framebuffer status:" "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
The only way to get control of the system again is to ssh in and kill the kwin_wayland process (or SDDM if it’s failing before the login screen).
I reported this to KDE, who said it’s fixed upstream by NVIDIA and closed the bug, and reported it to NVIDIA, who didn’t respond yet. This has been happening for a while, so I have to work around this:
The workaround:
In the below two files:
~/.config/kwinoutputconfig.json
/var/lib/sddm/.config/kwinoutputconfig.json
We need to deactivate one of the monitors in the array of outputs so that < 4 are enabled at any one time. This needs to be done while SDDM/kwin_wayland aren’t running.
This causes an Xid crash with NVIDIA at the moment when the SDDM config is different from the kwin config, so I can’t use that. Instead, I have removed SDDM, and installed greetd and tuigreet, and created two new .desktop files in /usr/local/share/wayland-sessions that exec a small wrapper I wrote in bash:
Exec=/usr/local/bin/session-wrapper pc
This wrapper takes the param ‘pc’ or ‘tv’ and copies a new kwinoutputconfig.json to ~/.config BEFORE starting startplasma-wayland.
This works okay, but I also noticed that I can achieve a much cleaner solution via kernel parameters:
For using the TV downstairs for gaming:
video=DP-1:d video=DP-3:d video=DP-4:d
and for using the PC upstairs:
video=HDMI-A-1:d
I’m using systemd-boot but obviously with the snapshot nature of Tumbleweed, it’s not as simple as crashing a new BLS compliant entry in /boot/efi/loader/entries, and I think multiple kernel parameters would get overwritten anyway. I did find that booting with no snapshot parameter specified would end up just using my default btrfs subvolume, which appears to be the correct snapshot anyway, but I’m not sure if that’s guaranteed.
There’s also another solution, of creating a script that uses kscreen-doctor, but I’ve found that switching outputs at runtime can be a bit unreliable.
So my questions are:
- Has anyone seen the same GL attach error? Is there a workaround for it that I’m not aware of, or do I need to wait for NVIDIA to fix it? I don’t see many people with similar repros, as I’m an edge case, I wonder if there’s a workaround I don’t know about?
- Is there a better way to manage multiple monitor configurations other than creating a session wrapper or using kscreen doctor?
- Is there a good way to dynamically specify kernel parameters at boot with systemd-boot, or is there a kwin parameter that will render the monitor “invisible” to Plasma?
Thanks for any help anyone can provide!