Bug 424319

Is it possible that you for example switch to another program just before those keys stops working?

I cannot reproduce it on Linux and I don't remember anyone with that issue on reddit, but there are sometimes some issues with input after switching focus to another application, hence the question.

Hi, I noticed there is bug 423404 that says it only happens when they open a particular PSD file, is it possible that it also happens to you only in those circumstances?

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

*** Bug 423404 has been marked as a duplicate of this bug. ***

Please provide more information

* In which language are you using Krita?
* Which keyboard layout?
* Does this happen, like we asked before, after you open a certain psd file?

(In reply to Boudewijn Rempt from comment #5)
> Please provide more information
> 
> * In which language are you using Krita?
> * Which keyboard layout?
> * Does this happen, like we asked before, after you open a certain psd file?

My keyboard layout is French Azerty. 
But Krita runs in English. 
I provided a psd file to one of you for inspection.
But this bug never happened again since last time. Maybe it was fixed.
Right now, I'm using an early Krita stable build, version 4.4.0 alpha...

(In reply to Boudewijn Rempt from comment #5)
> Please provide more information
> 
> * In which language are you using Krita?
> * Which keyboard layout?
> * Does this happen, like we asked before, after you open a certain psd file?

(In reply to stephen from comment #6)
> (In reply to Boudewijn Rempt from comment #5)
> > Please provide more information
> > 
> > * In which language are you using Krita?
> > * Which keyboard layout?
> > * Does this happen, like we asked before, after you open a certain psd file?
> 
> My keyboard layout is French Azerty. 
> But Krita runs in English. 
> I provided a psd file to one of you for inspection.
> But this bug never happened again since last time. Maybe it was fixed.
> Right now, I'm using an early Krita stable build, version 4.4.0 alpha...

Using Krita 4.4.0 alpha stable build(git ed74e2a), the bug started again on a random way. But all I can tell is, it happens when I switch between my Internet Browser and the application(Krita). On random occasion, all modifier keys including tool invocation shortcuts like Space, will temporarily disable themselves and there's no way to activate them back if you don't restart Krita or wait a long long time.

Switching back to REPORTED. 
See Comment #7

There were some time ago lots of people reporting problems with tablet pressure after doing something like that...

Hi, Stephen and Dummsaccs!

Could you clarify tho things for me: 

1) When the modifiers stopped working, what did your stylus do, did it paint with the brush or just did nothing? If painted, did pressure-sensitivity work correctly in this stroke?

2) When you pressed the modifier, did the cursor change?

And one more question:

3) Did you use tablet or mouse? If tablet, what API you have activated in Preferences->Tablet, WinTab or WinInk?

Created attachment 131710 [details]
attachment-29636-0.html

1) Pen pressure still works when it happens and you can paint with the
stylus.

2) Modifier keys do nothing when the issue occurs and no, the brush cursor
doesn't change.

3) As for the API I was using WinTab.

On Sep 16, 2020 20:50, "Dmitry Kazakov" <bugzilla_noreply@kde.org> wrote:

https://bugs.kde.org/show_bug.cgi?id=424319

--- Comment #11 from Dmitry Kazakov <dimula73@gmail.com> ---
And one more question:

3) Did you use tablet or mouse? If tablet, what API you have activated in
Preferences->Tablet, WinTab or WinInk?

Hi, Stephen and Dummsaccs!

From the symptoms you describe it looks like Krita gets a KeyPress event for some key and never gets a KeyRelease for it. It makes Krita think that the key is pressed forever, which blocks all actions other than painting.

If my guess is right then switching to another app and then back to Krita should exit this locked state (Krita resets its internal key-tracking state on every FocusIn event).

I have found a small bug in the key processing code, but I'm not sure it is related to this bug. Could you do some tests for me?

1) Download 'dk1-failing' package from here: https://yadi.sk/d/wO9UmqtHIs-nIw
2) Remove existing 'krita.log' file (it is placed in %LOCALAPPDATA% folder)
3) Work with the package for some time until the problem appears
4) As soon as the problem appear go to Help->Show Krita Log For Bugreports
5) Save the log into some file, e.g. 'dk1-failing.log', and attach to this bug

6) Download 'dk2-fixed' package: https://yadi.sk/d/h5F3FJ6pbBTcuA
7) Remove existing 'krita.log' file (it is placed in %LOCALAPPDATA% folder)
8) Work with the package for some time trying to reproduce the problem
9) If the problem appears, go to Help->Show Krita Log For Bugreports
10) Save the log into some file, e.g. 'dk2-fixed.log', and attach to this bug

These packages are basically Krita 4.4 Beta1, which is not yet released, but with extra logging added. I don't think this logging will affect performance in any way.

Btw, what tablets do you use? 

I noticed that when using Huion and switching back from Chrome (only this exact combination is affected), the first stroke is interrupted after about 0.5 sec by a spurious focus-lost event. The problem doesn't happen if I switch from any application that is not Chrome or if I use Wacom tablet. The problem doesn't appear if Krita is switched into WinInk, only WinTab is affected.

Here is a related thread: 

https://krita-artists.org/t/modifiers-stop-working-after-some-time-how-to-make-krita-remember-the-brush-size/10401/8

Git commit 040261e2bb7ede3d11359c27190a0208a949bf44 by Dmitry Kazakov.
Committed on 17/09/2020 at 22:17.
Pushed by dkazakov into branch 'krita/4.3'.

Fix mapping of Alt key on Windows

Windows' mnemonic for Alt key is rather confusing, isn't it? :)

M  +1    -1    libs/ui/input/kis_extended_modifiers_mapper.cpp

https://invent.kde.org/graphics/krita/commit/040261e2bb7ede3d11359c27190a0208a949bf44

Hi, Stephen and Dummsaccs!

Could you please test the packages I added in this comment? :)

https://bugs.kde.org/show_bug.cgi?id=424319#c13

(In reply to Dmitry Kazakov from comment #17)
> Hi, Stephen and Dummsaccs!
> 
> Could you please test the packages I added in this comment? :)
> 
> https://bugs.kde.org/show_bug.cgi?id=424319#c13

Oh, ok.
I'll do tests.

Did you manage to do the testing? This is one of the last bugs blocking our 4.4.0 release, and we haven't been able to reproduce it ourselves.

(In reply to Boudewijn Rempt from comment #19)
> Did you manage to do the testing? This is one of the last bugs blocking our
> 4.4.0 release, and we haven't been able to reproduce it ourselves.

Alright. I did tests. Wasn't able to reproduce the issue. 
However, on random occasions, when I get back to the app, cursor behavior is confused with space. As a result, even without pressing space, the hand tool is like, in use, and moving the pen around leads to panning the canvas. Doesn't happen with mouse. 
When this happens, I restart a service from my tablet driver to stop it. And for a while, even after I lose focus or get krita in focus, the issue doesn't occur.

Stopping my tablet driver service doesn't fix non-responsive modifier keys though. For this one, I must either press Tab key once at least then avoid losing focus again, or restart Krita.

Hi, stephen!

Could you tell me, what tablet do you use?

Created attachment 132045 [details]
attachment-18531-0.html

Hi Dmitry. I'm using a Huion H610 Pro.

On Oct 1, 2020 11:33, "Dmitry Kazakov" <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=424319
>
> --- Comment #21 from Dmitry Kazakov <dimula73@gmail.com> ---
> Hi, stephen!
>
> Could you tell me, what tablet do you use?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

Switch back to REPORTED

Okay, Bollebib reported a bug like that:

Tablet: yiynova 22 inch
API: WinTab

I seem to have an issue that is similar to this one



I was told to say i have Azerty keyboard

Git commit 86cc68ea0db64258b3ed8e9257b5f14f59509d34 by Dmitry Kazakov.
Committed on 27/11/2020 at 21:32.
Pushed by dkazakov into branch 'master'.

Another attempt to fix the locked modifiers state on Windows

It looks like Windows drops some key events when the user presses
Windows' window manager shortcuts, e.g. Alt+Space.

Steps to reproduce:
1) Press Alt+Space, see window title menu appeared
2) Click on the canvas to hide it
3) Now Krita is in a locked state. Press Alt key to unlock it.

M  +26   -0    libs/ui/input/kis_input_manager.cpp
M  +14   -10   libs/ui/input/kis_input_manager_p.cpp
M  +1    -0    libs/ui/input/kis_input_manager_p.h
M  +20   -0    libs/ui/input/kis_shortcut_matcher.cpp
M  +14   -0    libs/ui/input/kis_shortcut_matcher.h

https://invent.kde.org/graphics/krita/commit/86cc68ea0db64258b3ed8e9257b5f14f59509d34

Git commit 59c60f7ea94a4a0d97e3c1935902285f51ba4268 by Dmitry Kazakov.
Committed on 27/11/2020 at 21:34.
Pushed by dkazakov into branch 'krita/4.3'.

Another attempt to fix the locked modifiers state on Windows

It looks like Windows drops some key events when the user presses
Windows' window manager shortcuts, e.g. Alt+Space.

Steps to reproduce:
1) Press Alt+Space, see window title menu appeared
2) Click on the canvas to hide it
3) Now Krita is in a locked state. Press Alt key to unlock it.

M  +26   -0    libs/ui/input/kis_input_manager.cpp
M  +14   -10   libs/ui/input/kis_input_manager_p.cpp
M  +1    -0    libs/ui/input/kis_input_manager_p.h
M  +20   -0    libs/ui/input/kis_shortcut_matcher.cpp
M  +14   -0    libs/ui/input/kis_shortcut_matcher.h

https://invent.kde.org/graphics/krita/commit/59c60f7ea94a4a0d97e3c1935902285f51ba4268

Hi, Dummsaccs, Stephen and Bollebib!

I think I have finally fixed the problem of this bug. Could you please test the new package?

This package is from my local branch:
https://yadi.sk/d/f7TRMrYAWa48lQ

And tomorrow there will be a package with what is going to become Krita 4.4.2 (you need build #950 or later):
https://binary-factory.kde.org/job/Krita_Stable_Windows_Build/

@Dmitry can bug 428080 be a duplicate of this bug (except that it happens on Linux)? That would mean it needs a patch on Linux as well...

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

(In reply to Dmitry Kazakov from comment #28)
> Hi, Dummsaccs, Stephen and Bollebib!
> 
> I think I have finally fixed the problem of this bug. Could you please test
> the new package?
> 
> This package is from my local branch:
> https://yadi.sk/d/f7TRMrYAWa48lQ
> 
> And tomorrow there will be a package with what is going to become Krita
> 4.4.2 (you need build #950 or later):
> https://binary-factory.kde.org/job/Krita_Stable_Windows_Build/

Hello Dmitry and everyone.
So the issue still persists when I switch from browser to Krita some times(input stuck on panning).

Now, to quickly get rids of this annoying state, I've found another solution.
All you have to do is go to your browser, do a right click til context menu appears, and next, ignore the context menu and switch back to Krita.

Doing so will unlock the pan mode. I don't know why that happens tho.

Hi, Stephen!

What browser do you use? Is it Chrome/Chromium?

And did you test the packages I linked?

(In reply to Dmitry Kazakov from comment #32)
> Hi, Stephen!
> 
> What browser do you use? Is it Chrome/Chromium?
> 
> And did you test the packages I linked?

Hi Dmitry.

So after testing the packages, it turns out that the in cursor gets locked and can't be moved anymore

Not sure if it's the same issue, but I can reproduce this behavior in 4.4.2 simply by hitting Ctrl + Tab. Hitting tab again or switching windows fixes it.

The above behavior I described only happens if you have one document open. Otherwise, it switches to another document. Perhaps it's trying to switch to a document that doesn't exist and that's causing some sort of lockup?

I can reproduce the Ctrl+Tab issue

Git commit 32da056571250a376e131ebfced58f138e4d225a by Dmitry Kazakov.
Committed on 13/02/2021 at 13:57.
Pushed by dkazakov into branch 'master'.

Fix unbalanced KeyPress/Release events in children of QMdiArea

When the user presses Ctrl+Tab, QMdiArea is supposed to switch
the active child window. When doing so, it eats the event. The
problem is that is doesn't eat the ShortcutOverride event,
which is kept unbalanced with the absent KeyRelease event.

We have to patch Qt to fix this issue

A  +43   -0    3rdparty/ext_qt/0111-Fix-unbalanced-KeyPress-Release-events-in-children-o.patch
M  +5    -0    3rdparty/ext_qt/CMakeLists.txt

https://invent.kde.org/graphics/krita/commit/32da056571250a376e131ebfced58f138e4d225a

Hi, Stephen and TomTomTom!

Could you please test if this package fixes the problem for you? I have fixed a bug in Qt that caused the Ctrl+click lockdown.

Windows 64(ZIP): https://disk.yandex.ru/d/amqm_kwi8_WZWQ

Please make sure that you have done a backup of your configuration and resources before testing this package, it is based on Krita 5.0, which can make your configuration incompatible with 4.4 after the first run.

Hi Dmitry, I was able to test your changes with the nightly appimage. I tested six cases:
Case 1: Single tabbed document, ctrl+tab, successful!
Case 2: Multiple tabbed documents, ctrl+tab, successful!
Case 3: Single tabbed document after closing other documents, ctrl+tab, successful!
Case 4: Single subwindowed document, ctrl+tab, successful!
Case 5: Multiple subwindowed documents, ctrl+tab, regressive behavior - color picker preview visually stays on previous document. Switching back to it by clicking on it sometimes leaves on the color picker invocation, but doesn't seem to have its functional effect, only visual.
Case 6: Single subwindowed document after closing other documents, ctrl+tab, successful!

Git commit 049d7c639d7376ab9662087a5cd79585626f54dc by Dmitry Kazakov.
Committed on 19/02/2021 at 12:34.
Pushed by dkazakov into branch 'master'.

Fix deactivation of the color picker when the user presses Ctrl+Tab

The action should be deactivated on the lost focus event. Since the
recent changes the Ctrl+Tab shortcut will be completely eaten be Qt,
so we cannot rely on it.

M  +2    -0    libs/ui/input/kis_shortcut_matcher.cpp

https://invent.kde.org/graphics/krita/commit/049d7c639d7376ab9662087a5cd79585626f54dc

Hi, TomTomTom!

Please check tomorrow's nightlies, the color picker bug should be fixed now :)

Everything seems to work fine now, from what I can tell.