The repeat rate of the keyboard is capped at about 50 repeats per second in certain applications when using wayland / libinput (see also Bug 443721) affected apps / input fields: - systemsettings (including the test area input field) - neochat - folder view rename unaffected apps / input fields: - dolphin - firefox - kate - Kickof Search Thus, this might be a problem of Kirigami (oder QML?) GUIs.
Interesting. I don't currently have an idea how Kirigami/QML apps only can be affected. Meanwhile, could you do more tests to make sure those are only ones suffered?
On a side note, do you think rates above 50 per second might be useful?
(In reply to Andrey from comment #1) > Interesting. > I don't currently have an idea how Kirigami/QML apps only can be affected. > > Meanwhile, could you do more tests to make sure those are only ones suffered? Elisa (search albums) -> affected Okular (Settings annotations author field) -> unaffected Gimp (writing text on an image) -> unaffected Libreoffice Writer -> unaffected So here, the split Kirigami / No Kirigami seems the same. I do not know any more Kirigami apps (installable on Gentoo) here..
(In reply to Andrey from comment #2) > On a side note, do you think rates above 50 per second might be useful? Personally, I have set a repeat rate of 50 repeats/s/ because it become a bit uncontrollable for me at faster rats. I guess there are ppl loving it faster than me :). However, I guess this does only affect a very tiny fraction of the users as most of them will have much lower repeat rates.
I have narrowed the exact threshold down a little bit more by using longer keypresses for measurement, i.e., the measurement is less effected by my timing inconsistencies. It actually seems to top out at about 60 repeats/s, which is also my display refresh rate. Thus, I was wondering if these two rates might be related. Maybe the render loop with vsync only accepts one stroke at each pass or something like that. That would be perfectly testable if I could adjust the displays refresh rate of my display, but I cannot do so via systemsettings under wayland (only 60Hz selectable). Any Idea how I can adjust this setting under wayland with no xrandr?
(In reply to Till Schäfer from comment #5) > I have narrowed the exact threshold down a little bit more by using longer > keypresses for measurement, i.e., the measurement is less effected by my > timing inconsistencies. > > It actually seems to top out at about 60 repeats/s, which is also my display > refresh rate. Thus, I was wondering if these two rates might be related. > Maybe the render loop with vsync only accepts one stroke at each pass or > something like that. That would be perfectly testable if I could adjust the > displays refresh rate of my display, but I cannot do so via systemsettings > under wayland (only 60Hz selectable). Any Idea how I can adjust this setting > under wayland with no xrandr? Maybe there is somebody else with a display at with other refresh rates who can test this. If this is the indeed the limiting factor, it might be troublesome for vely low refresh rate displays (e.g., using a TV with only 25 Hz). I am also wondering what would happen at variable refresh rates.
There is another hint, that rendering / compositor is involved. When I select Latency "Force lowest latency (may cause dropped frames)" under systemsettings -> Compositor, the maximum repeat rate caps at about 30 repeats per second. Using the other extreme (prefere smoothest animations) i get 60 repeats/s. The other settings are in between. Furthermore, when using latency setting "prefer lower latendy", I get a wobbling fast to slow repeat rate effect. Thus, the repeat rate in inconsistent, which make it hard to predict.
With a system under stress and "Force lowest latency" setting, i can bring my system down to a repeat rate of about 20 repeats/s
Thus, this might become a problem for low performance computers (mine is quite ok). Operating System: Gentoo Linux KDE Plasma Version: 5.23.2 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 Kernel Version: 5.14.15-gentoo (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-4810MQ CPU @ 2.80GHz Memory: 15.5 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4600
Can you test on other compositors/desktops?
(In reply to Till Schäfer from comment #3) > Elisa (search albums) -> affected I tested on Gnome Wayland and didn't find any difference in max rates between Elisa and Terminal there. It's about 1000 per sec in both cases. So problem you described might be a KWin issue, can't test it yet.
I can reproduce the issue with fedoras live image (version 34-1.2) installing the package elisa-player. The settings page does not really give you a precise indication on how fast it is, but I got about 4300 repeats in 5 seconds in terminal and only 200 repeats in elisas album search.
(In reply to Till Schäfer from comment #12) > I can reproduce the issue with fedoras live image (version 34-1.2) > installing the package elisa-player. > > The settings page does not really give you a precise indication on how fast > it is, but I got about 4300 repeats in 5 seconds in terminal and only 200 > repeats in elisas album search. that is elisa 21.08.1 with frameworks 5.85 and qt 5.15.2 on gnome 40.0.0
Could you test Flathub version? It should be better chances we get similar results: https://flathub.org/apps/details/org.kde.elisa
(In reply to Andrey from comment #14) > Could you test Flathub version? It should be better chances we get similar > results: > https://flathub.org/apps/details/org.kde.elisa Hmm, the flatpack version does not seem to be affected. Weired. About says. elisa 21.08.2 frameworks 5.86 qt 5.15.3 I was wondering why qt 5.15.3 is used since this version is non-free. Maybe there is a qt fix upstream available?
(In reply to Till Schäfer from comment #15) > I was wondering why qt 5.15.3 is used since this version is non-free. Maybe > there is a qt fix upstream available? Where do you see this info? It uses org.kde.Platform runtime which AFAIK is opensource-only: https://github.com/flathub/org.kde.elisa/blob/master/org.kde.elisa.json It might include KDE Qt patches collection, though. Still it's interesting indeed how 5.15.3 has arose.. Anyway, do you think we should close this as not relevant to KDE?
(In reply to Andrey from comment #16) > (In reply to Till Schäfer from comment #15) > > I was wondering why qt 5.15.3 is used since this version is non-free. Maybe > > there is a qt fix upstream available? > Where do you see this info? In the about dialog of Elisa. > It uses org.kde.Platform runtime which AFAIK is opensource-only: > https://github.com/flathub/org.kde.elisa/blob/master/org.kde.elisa.json > It might include KDE Qt patches collection, though. Still it's interesting > indeed how 5.15.3 has arose.. > > Anyway, do you think we should close this as not relevant to KDE? No, this bug is happening on the normal KDE up to date stack and it is a wayland regression over X11 (both, the native as well as the flatpak version are running natively on wayland). We are not sure that, qt (i.e. out of control from KDEs point of view) is actually the cause. I was wondering if flatpak is tampering with something of the graphics or input stack. like vsync or so. I find an unpredictable (depending on system load, type of application) repeat speed of my keyboard annoying, since it makes input non-intuitive. I think for fast repeat speeds you o not really look precisely about the things happening, but predict the cause of your action. Thus, this makes high repeat speed unusable to me.
Still it might be a regression, so it's worth to test it maybe in VM with Neon (but not sure if such kind of test is correct on VMs). You could test first your distro on VM to make sure the issue happens there, then test a Neon.
(In reply to Till Schäfer from comment #17) > I was wondering if > flatpak is tampering with something of the graphics or input stack. like > vsync or so. From system POV it's just usual app but sandboxed. It speaks Wayland and runs with restricted permissions, so nothing unusual it can do system-wise..
Could you check with KDE's patched Qt, installing it manually instead or trying distros already shipped one? https://community.kde.org/Qt5PatchCollection
What else comes to mind is different libinput library versions maybe.. Anyway, from Elisa's flatpak manifest you can dig out every component version of properly working build: https://github.com/flathub/org.kde.elisa/blob/master/org.kde.elisa.json
(In reply to Andrey from comment #20) > Could you check with KDE's patched Qt, installing it manually instead or > trying distros already shipped one? > https://community.kde.org/Qt5PatchCollection For my main systen (and the original bug Report, see specs below), I am already using Gentoo with Qt5PatchCollection patches applied up to commit a4f9e56975fa6ab4a1f63a9b34a4d77b1cfe4acd of the qtbase patchset. I will install the live ebuilds, that apply HEAD of Qt5PatchCollection and report back. Operating System: Gentoo Linux KDE Plasma Version: 5.23.2 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 Kernel Version: 5.14.15-gentoo (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-4810MQ CPU @ 2.80GHz Memory: 15.5 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4600
(In reply to Andrey from comment #21) > What else comes to mind is different libinput library versions maybe.. > > Anyway, from Elisa's flatpak manifest you can dig out every component > version of properly working build: > https://github.com/flathub/org.kde.elisa/blob/master/org.kde.elisa.json I am a novice w.r.t. to flatpak and not very fammilar with the inclusion of libintput in projects. Is libinput bundled with qts flatpak bundle? Is the input not handled by the window manager / compitor? In the last case the libinput version should be the same for the flatpak version and the native one). Anyway, my original setup for this bug report is using: libinput 1.18.1
(In reply to Till Schäfer from comment #23) > (In reply to Andrey from comment #21) > > What else comes to mind is different libinput library versions maybe.. > > > > Anyway, from Elisa's flatpak manifest you can dig out every component > > version of properly working build: > > https://github.com/flathub/org.kde.elisa/blob/master/org.kde.elisa.json > > I am a novice w.r.t. to flatpak and not very fammilar with the inclusion of > libintput in projects. Is libinput bundled with qts flatpak bundle? Is the > input not handled by the window manager / compitor? In the last case the > libinput version should be the same for the flatpak version and the native > one). To clarify, I am talking about the Fedora Live image here, for which I have tested the native installation of elisa (affected) and the flatpak version (unaffected). > > Anyway, my original setup for this bug report is using: > > libinput 1.18.1 And my Gentoo main system here
(In reply to Andrey from comment #20) > Could you check with KDE's patched Qt, installing it manually instead or > trying distros already shipped one? > https://community.kde.org/Qt5PatchCollection I have patched qt to the latest Qt5PatchCollection here on my Gentoo box and the issue still persists.
We still need a way to reproduce it on unaffected distros (if any). Could you try to reproduce on VM?
(In reply to Andrey from comment #26) > We still need a way to reproduce it on unaffected distros (if any). > Could you try to reproduce on VM? Tested the following images inside a VM. neon-testing-20211102-1850 affected kubuntu-21.04-desktop-amd64 affected kubuntu-20.04.3-desktop-amd64 repeat speed is limit to 50 repeats in the keyboards kcm kubuntu-18.04.5-desktop-amd64 repeat speed is limit to 50 repeats in the keyboards kcm Is there a way to set a higher repeat rate for the older keyboards kcm, via dbus or so?
Err, sorry I didn't think of that VMs are just (X?)Wayland apps also, so the tests should depend on environment you test them on.. Any chance to test on real HW? Anyway, I'll test that VMs also, thanks.
(In reply to Andrey from comment #28) > Err, sorry I didn't think of that VMs are just (X?)Wayland apps also, so the > tests should depend on environment you test them on.. > Any chance to test on real HW? Well the issue was also reproducible there. Thus, the input stack should not have made a difference the (btw: tested on another computer with x11). Nevertheless, I repeated the test on real HW (same i7-4810MQ as in the other tests). I got the same results as in comment #27.