| Summary: | Switching virtual desktops causes keyboard shortcuts to stop working until click | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | abulhair.saparov |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | nate, xaver.hugl |
| Priority: | NOR | ||
| Version First Reported In: | 5.24.4 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
abulhair.saparov
2022-04-06 06:35:05 UTC
(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 |