You are not logged in.
Thank you, and your systemd service works for me in regards of terminal resolution.
I assume KDE and plasma login manager to be out of the equation since switching to weston was not possible as well, after trying to run konsole in another TTY
Last edited by ColinVortex (2026-06-08 14:33:56)
Offline
I assume KDE and plasma login manager to be out of the equation
But you said upthread:
switching to plasma AND weston NOT possible anymore
So, as a test to find the root cause, I'm suggesting:
1) disable whatever DM plasma uses temporarily
2) boot to multi-user target
3) start weston session on TTY1
4) start sway session on TTY2
Can you then switch back and forth without issue?
If yes... KDE/plasma/DM is the likely culprit to investigate further (with seth
)
Offline
@tekstryder while you were posting I tried to get rid of drkonqi as seth suggested. Uninstalled with pacman and all the issues are gone now.
I have no explanation for this. I'll post the journal.
https://paste.c-net.org/BimboSidewalk
I can also confirm that it's not due to your systemd service, disabled it and everything still works
Last edited by ColinVortex (2026-06-08 14:48:33)
Offline
Uninstalled with pacman and all the issues are gone now.
Including the original, VRR related one?
I can see where kwhatever tries to use the wayland server, fails, aborts, triggers drkonqi and that wants to show a dialog or otherwise occupies a wayland resource (socket?) but doesn't crash or so (nb that this is a hypothesis based on absolutely no evidence) - but I don't quite see how this ties in w/ the VRR situation.
Offline
I see.
So I was really happy that it worked (also with VRR enabled) until it did not anymore.
I just tried a lot of combinations.
Installed sway, disabled plasma login manager and switched to multi-user target. Switching between console-launched weston and sway without problems (I don't know if sway enables VRR or not, since my monitor always shows "enabled" in HUD when Linux is running.
Switched back to graphical target, enabled plasma login manager and sometimes it works now and sometimes the system still freezes. It feels more likely when VRR is enabled but I really couldn't figure out a pattern.
The log of the last failure:
https://paste.c-net.org/ChimesTyping
Is it worth trying to use sddm instead of plasma login manager?
Last edited by ColinVortex (2026-06-08 15:22:22)
Offline
You could test whether SDDM w/ the default X11 backend, weston and using https://wiki.archlinux.org/title/SDDM#KDE_Plasma_/_KWin makes a difference ![]()
Offline
So while I have yet to try using SDDM (or X11 instead of wayland) I set up a hyprland environment.
Until then I figured the module parameter
nvidia_modeset.conceal_vrr_caps=1 to be a reliable workaround. My display then reported a fixed refresh rate in OSD instead of "freesync". I had no problems frequently switching between TTY's and even running plasma and hyprland simultaneously worked (as bad as can be expected, but at least no system crash).
Then I removed the parameter again and enabled VRR in hyprland and tailed the journal via ssh. On TTY-switching the "pageflip timeout" error arbitrarily occurred but I could not let it crash the system in a way it does under kwin.
So I suppose kde/kwin is not entirely the root cause?
Nevertheless I figured that even when enabled, VRR in fact is not working at all. Both vrrtest and gl-gsync-demo suffer from severe stuttering.
Offline
You might want to record that at https://wiki.archlinux.org/title/NVIDIA/Troubleshooting or https://wiki.archlinux.org/title/Variab … leshooting
Offline
I added a section to the wiki.
Would you say it's safe to assume that it's a driver bug at this point?
Offline
https://download.nvidia.com/XFree86/Lin … E/kms.html
Probably an issue w/ the VRR implementation of the specific monitor though afaiu nvidia requires these things to be "gsync approved" by nvidia so you'd expect the driver to blacklist the model ¯\_(ツ)_/¯
Offline
Oh yeah you are right, I totally forgot about this gsync vs. gsync compatible vs. gsync approved thing. It's good to see though that it's intended behavior of the driver to permanently send an active VRR signal to the monitor. And if the monitor's freesync implementation isn't compatible with Nvidia's driver it will eventually crash.
Before I open a possibly unnecessary new topic on the forum I just wanted to ask if it's normal that gaming performance (in terms of FPS) is around 30% lower on both vulkan native and dxvk application on Nvidia + Linux in comparison with windows? On vkd3d it's around 70% lower.
Offline
Before I open a possibly unnecessary new topic on the forum I just wanted to ask if it's normal that gaming performance (in terms of FPS) is around 30% lower on both vulkan native and dxvk application on Nvidia + Linux in comparison with windows? On vkd3d it's around 70% lower.
Hardly, open the new thread w/ "vulkaninfo --summary" and probably try an X11 session (like openbox) to rule out overhead/bugs in the compositor (and also nvidia might still have hiccups w/ wayland)
Also quantify the performance gap in absolute term (5000 fps to 2500fps and 50fps to 25fps is both 50% but has completely different implications about the pot. bottleneck) and nb. that for specific games the windows driver might have optimizations not available for the linux driver (but you'd see different changes in different games)
Offline
Will do soon. Thank you seth!
Offline