SUMMARY Krita will occasionally stop recognizing that spacebar and ctrl are held down when panning and zooming around the canvas. STEPS TO REPRODUCE 1. hold down spacebar to pan or spacebar and ctrl to zoom 2. pan and/or zoom with tablet stylus OBSERVED RESULT Krita will occasionally stop recognizing that spacebar and ctrl are held down when panning and zooming around the canvas. this results in the last selected tool being activated (in my case, usually the brush tool). EXPECTED RESULT Panning and zooming should not stop working when spacebar and ctrl are held down. SOFTWARE/OS VERSIONS Windows: 10 2004 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION Log viewer docker output: WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Space, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(ControlModifier) d->matcher.debugPressedKeys() = QVector() WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(ControlModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Space) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Space, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Space, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Space, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(ControlModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Space) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Space, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(ControlModifier) d->matcher.debugPressedKeys() = QVector() WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Space, Qt::Key_Control)
Can't reproduce on 4.4.3, Gentoo Linux.
This is discussed in more detail here: https://krita-artists.org/t/krita-is-dropping-keyboard-inputs-or-its-something-else/26585 and here: https://krita-artists.org/t/unresponsive-keyboard-input-once-again/26639 With the 4.4.5 appimage on Debian 10, I can't reproduce this after lots of key mashing of the Ctrl or Shift keys, with the Space key held down. I can reproduce it on Windows 10 with the 4.4.5 installation and the July 23 5.0.0-prealpha (git 73473a8d27) portable .zip. Rapidly mashing the Ctrl/Shift key while the Space key is held down at the same time as making swipes across the tablet surface with a stylus will induce the condition. It doesn't happen if the stylus is not used to make swipes. I can't induce it when using the mouse and that may be because I can't operate and use the mouse fast enough. Log viewer output: WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Space, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Shift) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Shift) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Space, Qt::Key_Control) The condition remains while the Space key is held down. While the Space key is held down, it is ignored and the selected tool is used. If Ctrl is pressed, the magnifying glass icon is shown but is replaced by the selected tool icon when the stylus is used to draw and the selected tool is used. If the Shift key is pressed then the line tool cursor is shown and is activated as seen on the canvas drawing and the Toolbox docker icon. If the Space key is then released, operation goes back to normal until the next Ctrl/Shift mashing with Space held down.
This bug is still present in Krita 5 Beta 1. Updating.
I can confirm that I have observed this multiple times as well in both Krita 4.4.7 and Krita 5 Beta 1. It affects zooming (Space+Ctrl+LMB) and rotate canvas (Space+Shift+LMB). Windows 10 Huion Kamvas 22 plus
*** Bug 432446 has been marked as a duplicate of this bug. ***
Ah, please don't update the version -- the version field should be for the version the bug was originally reported for.
*** Bug 442547 has been marked as a duplicate of this bug. ***
this bug is still present in krita 5.0 beta 5.
Tested in 5.0 stable (download from KDE server) on Win10 20H2 I found this bug only happened when I enable Windows Ink, using mouse or WinTab the bug will not occurr to me.
(In reply to Protoniv from comment #9) > I found this bug only happened when I enable Windows Ink, using mouse or WinTab the bug will not occurr to me. After some more test, the Windows Ink is actually from my tablet driver "Use Digital Ink" (XP Pen), if "Use Digital Ink" in tablet driver is off then Windows Ink/WinTab setting in Krita won't occur the bug, at least for me.
(In reply to Protoniv from comment #10) > (In reply to Protoniv from comment #9) > > I found this bug only happened when I enable Windows Ink, using mouse or WinTab the bug will not occurr to me. > After some more test, the Windows Ink is actually from my tablet driver "Use > Digital Ink" (XP Pen), if "Use Digital Ink" in tablet driver is off then > Windows Ink/WinTab setting in Krita won't occur the bug, at least for me. Still occurs even with windows ink turned off in the driver for me. Huion Kamvas 13
A message to the developers: This bug occurs since the 4.3 version. Maybe you can check the 4.2.9 version (which I'm currently using as it doesn't have the bug) and compare it with the 4.3 to see the code differences and spot what causes the bug. I'm on Windows 10 with a Huion INSPIROY H1161.
Very reproducible on my Surface Pro 2017. Some quick notes after experimenting: - Press down Spacebar, press stylus to pan, release stylus, press down Shift, press stylus to rotate, release stylus, THEN release Shift, press stylus to pan works normally - Press down Spacebar, press stylus to pan, release stylus, press down Shift, press stylus to rotate, release Shift, THEN release stylus, press stylus and it starts painting instead
Still present in 5.0.2. Modifier keys just spaz out when I pan, rotate and zoom quickly. Can reproduce it on my main rig (Win10 / Huion WH1409 v2) and my Surface Book 2 (Win10 / Wacom Bamboo Ink).
I can reproduce the issue following the instructions from KA thread [0]. Steps to reproduce: 1) Hold Space key 2) Start quickly pressing and releasing Ctrl key very quickly 3) Start quick brush strokes with the stylus. It should alternate between zoom and pan actions Eventually, Krita gives up and forgets that Space key has been pressed. [0] - https://krita-artists.org/t/krita-is-dropping-keyboard-inputs-or-its-something-else/26585/2
Git commit 58392a1f9ae446da3f48c632f2bfe68d10a60ee4 by Dmitry Kazakov. Committed on 08/01/2022 at 14:20. Pushed by dkazakov into branch 'master'. Fix Krita forgetting about pressed keys when tapping Ctrl too quickly Under some circumstances, KeyPress/KeyRelease event comes **after** a tablet move event with already updated state. It is not very clear how that happens, but it is surely not impossible. Qt fills modifiers event property by reading some global storage, so it is possible that this state is not entirely in sync with the events queue. The patch does two fixes: 1) KisShortcutMatcher::recoveryModifiersWithoutFocus() used RecursionNotifier incorrectly, causing keyReleased() and keyPressed() to reset the state. 2) KisShortcutMatcher::keyReleased() now doesn't reset the state when discovering inconsistent key release. This change is a bit scary, because it may lead to longer recovery time when Krita faces a real trouble with events. But in general it looks "correct". M +5 -4 libs/ui/input/kis_shortcut_matcher.cpp https://invent.kde.org/graphics/krita/commit/58392a1f9ae446da3f48c632f2bfe68d10a60ee4
Git commit d2b028c9fc8dbe427d944f26b34b833607614e4d by Dmitry Kazakov. Committed on 08/01/2022 at 14:21. Pushed by dkazakov into branch 'krita/5.0'. Fix Krita forgetting about pressed keys when tapping Ctrl too quickly Under some circumstances, KeyPress/KeyRelease event comes **after** a tablet move event with already updated state. It is not very clear how that happens, but it is surely not impossible. Qt fills modifiers event property by reading some global storage, so it is possible that this state is not entirely in sync with the events queue. The patch does two fixes: 1) KisShortcutMatcher::recoveryModifiersWithoutFocus() used RecursionNotifier incorrectly, causing keyReleased() and keyPressed() to reset the state. 2) KisShortcutMatcher::keyReleased() now doesn't reset the state when discovering inconsistent key release. This change is a bit scary, because it may lead to longer recovery time when Krita faces a real trouble with events. But in general it looks "correct". (cherry picked from commit 58392a1f9ae446da3f48c632f2bfe68d10a60ee4) M +5 -4 libs/ui/input/kis_shortcut_matcher.cpp https://invent.kde.org/graphics/krita/commit/d2b028c9fc8dbe427d944f26b34b833607614e4d
*** Bug 440352 has been marked as a duplicate of this bug. ***