SUMMARY While running Krita with QT_QPA_PLATFORM=wayland, holding down the shortcut key for "Increase Brush Size" or "Decrease Brush Size" only triggers the action once; it does not repeat when the key is held down. This is different from how both 6.0.0-beta 2 in XWayland mode, and 5.2.15 function, where the Increase/Decrease brush size action is repeated when the key is held STEPS TO REPRODUCE 1. Open a canvas 2. Choose Freehand Tool brush 3. Press and hold shortcut key bound to "Increase Brush Size" or "Decrease Brush Size" OBSERVED RESULT Brush size only increases/decreases by one step, no matter how long key is held EXPECTED RESULT Brush size should continue to increase/decrease as long as key is held SOFTWARE/OS VERSIONS Arch Linux with kernel 6.18.9-arch1-2 KDE Plasma Version: 6.6.1 KDE Frameworks Version: 6.23.0 Qt Version: 6.10.2 ADDITIONAL INFORMATION Holding shortcut key also does not work with other actions like Rotate canvas right or left
Hi, Wemi! Could you please check this nightly build? https://cdn.kde.org/ci-builds/graphics/krita/master/linux/ I guess the problem should be fixed by this patch: https://invent.kde.org/dkazakov/qtwayland/-/commit/08f16cfc7c94ec49b8796c3f4fa94c3e8cded951 Though I'm not sure it was included into Beta2, I guess not.
(In reply to Dmitry Kazakov from comment #1) > Hi, Wemi! > > Could you please check this nightly build? > > https://cdn.kde.org/ci-builds/graphics/krita/master/linux/ > > I guess the problem should be fixed by this patch: > > https://invent.kde.org/dkazakov/qtwayland/-/commit/ > 08f16cfc7c94ec49b8796c3f4fa94c3e8cded951 > > Though I'm not sure it was included into Beta2, I guess not. Hi Dimitri, The problem is still happening for me with that nightly (git c7c49cc). Same as it was in Beta2
Hi, Wemi! What compositor you are using KWin?
Yes, KWin is my compositor. Version is kwin 6.6.1
🐛🧹 Thanks for your comment! Automatically switching the status to REPORTED so the team can perform further triage. In the future you may also do this yourself when providing needed information.
It is weird, because I cannot reproduce this issue on KWin 6.5.5. What shortcut do you use for testing? The default '[' and ']'?
And one more question, do you have any custom input methods active?
When I made the bug report, my setup was to have my Keyboard Layout set to Dvorak, which is what I normally type with. I also usually have fcitx5 enabled as a virtual keyboard in KDE Plasma, because I sometimes need to input Japanese characters. I have a set of shortcuts in Krita that remap a lot of things around the Dvorak layout and my own workflow. The shortcut I normally use for Increase/Decrease brush are number row 4 and 5, set as the alternate shortcut in Krita. Your last comment made me try setting everything related to input that I could think of back to stock, (Disable fcitx5, set only keyboard to English QWERTY, set Krita shortcuts to Default, then reboot), but the problem still persists for me while using '[' and ']'. It also does not register held key repeat for other shortcut actions like Zoom In/Zoom Out
As another note, I happen to have a Fedora 43 install on the same computer (I recently migrated from Fedora to Arch and haven't cleaned everything up yet). It is running KWin 6.5.5 and has the same setup with a Dvorak Keyboard and fcitx5. I tried running the current Krita nightly (git 2af78ff) with QT_QPA_PLATFORM=wayland on Fedora and it does not have this issue. Repeat keys work as expected. Meanwhile, on Arch with KWin 6.6.1 and the same nightly, Repeat keys do not work. Maybe this is helpful?
Ok I now realize that in KDE Plasma's settings, I had one of the Accessibility features turned on. Under Keyboard Filters, I had the "Bounce Keys" filter enabled with a 35ms delay. Disabling this filter makes the key repeat issue go away when running the wayland version of Krita (on Arch with KWin 6.6.1)
I can reproduce the same issue in Dolphin, it's definitely not a bug in Krita.
*** This bug has been marked as a duplicate of bug 513268 ***