SUMMARY I have a single activity with 4 virtual desktops side-by-side and I have "switch one desktop to the left/right" mapped to a shortcut. When I use this shortcut to switch to an empty desktop, it will (almost) always cause keyboard shortcuts to stop working, and so I can't continue using those shortcuts to switch desktops or go back, *until* I click on the desktop. I'm not exactly sure but it seems like plasma "loses focus" when this happens. Interestingly, this does not happen if there is a window or application open on the new desktop, and I wait for a bit. However, if I switch quickly between desktops that have open windows/applications, the keyboard shortcuts stop working after a few switches. I'm guessing it has to be faster than a few hundred milliseconds. I think this may be related to my Xorg configuration, since I have a monitor connected via displayport and an A/V receiver which is then connected via HDMI to the same NVIDIA GPU. In order to run the monitor at 144Hz, I needed to put them on different X screens, so KDE runs on the primary X screen and doesn't manage the other display. If I instead have KDE manage both displays, the keyboard shortcut problem doesn't occur. STEPS TO REPRODUCE 1. Use keyboard shortcut to switch to empty desktop (no windows or applications open) OBSERVED RESULT In (almost) all cases, all keyboard shortcuts stop working, as if plasma has "lost focus." EXPECTED RESULT Keyboard shortcuts should continue working as normal. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Gentoo Linux Kernel 5.17.1-r1 amd64 KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3
(In reply to abulhair.saparov from comment #0) > I think this may be related to my Xorg configuration, since I have a monitor > connected via displayport and an A/V receiver which is then connected via > HDMI to the same NVIDIA GPU. In order to run the monitor at 144Hz, I needed > to put them on different X screens, so KDE runs on the primary X screen and > doesn't manage the other display. If I instead have KDE manage both > displays, the keyboard shortcut problem doesn't occur. That's an interesting setup. I'll let the KWin developers comment on whether this is something we can support. How does this setup work on Wayland, out of curiosity?
(In reply to Nate Graham from comment #1) > (In reply to abulhair.saparov from comment #0) > > I think this may be related to my Xorg configuration, since I have a monitor > > connected via displayport and an A/V receiver which is then connected via > > HDMI to the same NVIDIA GPU. In order to run the monitor at 144Hz, I needed > > to put them on different X screens, so KDE runs on the primary X screen and > > doesn't manage the other display. If I instead have KDE manage both > > displays, the keyboard shortcut problem doesn't occur. > That's an interesting setup. I'll let the KWin developers comment on whether > this is something we can support. > > How does this setup work on Wayland, out of curiosity? Thanks! Not sure, I haven't tried it with Wayland. Should I?
Yes please. :)
I just tried running with Wayland. It seems the screen/device configuration is not managed by Wayland, but by the compositor. And so it behaves identically to X when both the A/V receiver and monitor are configured as part of a single X screen, which leads to the same problems I had before: I can't get 144Hz unless I disable the A/V receiver in Display Configuration, but doing so will prevent any audio going to the receiver. But at least the switch desktop function works correctly (as it does in X in this configuration).
> I can't get 144Hz unless I disable the A/V receiver in Display Configuration, but doing so will > prevent any audio going to the receiver Would you mind if we used the bug report to track this specific issue? Seems like that's the root cause of all the problems.
I don't mind! I noticed that kwin_wayland is supposed to let each monitor run at its native refresh rate (https://kde.org/announcements/plasma/5/5.21.0/), but https://testufo.com/ showed I was running at 60fps. In the meantime, I'll try some of the methods described in: https://github.com/moonlight-stream/moonlight-qt/issues/557 https://www.reddit.com/r/linux4noobs/comments/tye8n0/what_are_the_consequences_of_forcing_variable/
I was able to get my monitor to run at 144Hz in X using the automatic X configuration (i.e. no xorg.conf file; so both the receiver and monitor are on the same X screen, which is also the Wayland configuration). I added the following to a file in /etc/env.d/ KWIN_X11_REFRESH_RATE=144000 KWIN_X11_NO_SYNC_TO_VBLANK=1 KWIN_X11_FORCE_SOFTWARE_VSYNC=1 __GL_SYNC_DISPLAY_DEVICE=DP-4 __GL_SYNC_TO_VBLANK=0
> https://testufo.com/ showed I was running at 60fps. In what browser? Chromium has some known issues with high refresh rate on Wayland
Ah I tested it in Chromium. Do you know of a better way I can test the refresh rate?
You can try Firefox I guess?
I kept getting 144Hz on Firefox, but I wasn't sure how much to trust it, since I tried to guess the refresh rate simply based on my mouse/window movements and it felt choppier. But that may have just been subjective, which is why I relied on something more objective like testufo.
I also just tried using the "Show FPS" desktop effect. I think the FPS is capped at 100, but at least it can tell us if the frame rate is <100. The results so far: X11: testufo Firefox: 144Hz testufo Chromium: 144Hz ShowFPS: 100Hz Wayland: testufo Firefox: 144Hz testufo Chromium: 60Hz ShowFPS: 100Hz So perhaps Wayland and kwin are correctly running the monitor at 144Hz and Chromium+Wayland is the problem.
If Firefox works then it's definitely chromiums fault. If you want to track the bug in chromium you can follow the bug report there: https://bugs.chromium.org/p/chromium/issues/detail?id=1310539