Bug 463135 - Keyboard keys lose focus/stop working.
Summary: Keyboard keys lose focus/stop working.
Status: RESOLVED WORKSFORME
Alias: None
Product: krita
Classification: Applications
Component: General (show other bugs)
Version: 5.1.4
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-12-16 21:45 UTC by ryan
Modified: 2023-12-06 03:45 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ryan 2022-12-16 21:45:16 UTC
SUMMARY
Ever since the release of Krita 5, the keyboard keys will periodically stop responding. For instance, I will be painting and selecting a color or panning a canvas, and all of a sudden it won't work anymore. It's getting progressively worse with each new release. It seems to happen randomly, but it might be triggered when another app does something significant while painting, like a browser changing a song, or playing a new video automatically.

In 5.0.2, Krita would occasionally lose keyboard input, however, changing a brush or alt tabbing would regain focus. In the newer version of Krita, this solution to regain focus seems to be less effective and aggressive alt tabbing/program switching is required. Switching brushes doesn't seem to work anymore.

STEPS TO REPRODUCE
1. Start krita
2. Paint in krita

OBSERVED RESULT
Eventually, keyboard keys no longer work.

EXPECTED RESULT
Keyboard keys always respond.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Kubuntu 22.04
KDE Plasma Version: 5.24.7
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3

ADDITIONAL INFORMATION
I've reinstalled my operating system multiple times since version 5 of Krita has been released, and in every iteration this problem remains.
Comment 1 Halla Rempt 2023-01-05 13:40:39 UTC
Can you check whether this is also the case with the appimage, or only with your distribution packages?
Comment 2 ryan 2023-01-11 10:12:30 UTC
(In reply to Halla Rempt from comment #1)
> Can you check whether this is also the case with the appimage, or only with
> your distribution packages?

I've tested and found this issue with all versions, as I have been wanting to move beyond 5.0.2 for awhile now.

I believe I have found what triggers the issue. If I test the program with the default Canvas Input Settings, everything seems to work well. However, if I change the alternate invocation to 'alt+left button' (sample foreground color from merged image) and change primary setting to 'ctrl+alt+left button' (brush size), the issue starts. I also remove all other actions in alternate invocation that would conflict with this setup.

Basically I change the keys for resize brush and color picker away from defaults which trigger the issue.

All I did was change these settings and start painting. Within minutes of panning, selecting brushes, using the above hotkeys, and doing it in a random order, the problem manifests.
Comment 3 Bug Janitor Service 2023-01-12 05:19:08 UTC
Thanks for your comment!

Automatically switching the status of this bug to REPORTED so that the KDE team
knows that the bug is ready to get confirmed.

In the future you may also do this yourself when providing needed information.
Comment 4 ryan 2023-01-14 11:16:27 UTC
I may have isolated a part of the issue. While using the changes to the Canvas Input Settings that I've discussed already, press and hold the key to sample the canvas color (alt) and then select a brush from the brush preset window. While still holding the alt-key, left click on the canvas. You can now let go of alt. The effect will be that you can no longer use the alt-key. The default settings seem to not be affected by this bug.

While this is similar to the issue I am experiencing, this particular method still allows one to use other keys like the spacebar for panning the canvas. The problem I originally described doesn't even allow one to use the spacebar, so I'm still unsure of how that bug comes about, but the cause might be related.
Comment 5 ryan 2023-01-14 18:40:09 UTC
After further testing, I believe the subject of my last reply is the issue. I tested version 5.1.5 and I can see that I lose function of the keyboard until I select another brush. I'm unsure why I was still able to before.

It seems that the alt key is the only modifier that will cause the keyboard to lock-up. There is also no need to change any settings as I discovered that the alt key is what triggers the issue, regardless of what is bound to it.

Again, the steps to reproduce the bug is: while holding the alt key, select a different brush and then click the canvas window. Let go of the alt key and try to use the keyboard (also affects mouse). You can resolve the bug by selecting a new brush or by clicking on a different window (layers, toolbox, etc).

While I have discovered the problem, this bug is probably not something a lot of people experience because it takes human error to even bring it out (selecting a brush while holding a modifier key), and then it also takes someone who doesn't use the default bindings.
Comment 6 ryan 2023-01-14 21:13:57 UTC
In addition, there is a small window of time where if one presses the alt key after selecting a brush and then left clicks the canvas, that the same bug will appear. In my instance, since I often select color right after selecting a brush, I see this bug a lot. I actually think this is how I am triggering the bug rather than when pressing the alt key during brush selection.

There is one little bit information that may help, if you press the alt key after selecting a brush, and then wait for the color picker icon to appear, then it becomes safe to left click to sample a color. If done before the transition, the keyboard keys will become stuck.
Comment 7 Halcyoen 2023-02-21 19:51:01 UTC
i have what i think is the same issue on kde neon. the issue appears whenever i press ctrl+alt or ctrl+shift. after this my canvas input command for the color sampler (alt+left click) or resizing the brush (alt+right click) stops working. the quickest way to "unblock" my canvas inputs is by pressing ctrl again.

this only seems to happen in the version downloaded from the official repos though. i do not experience this issue on windows, not with the appimage version and not with the flatpak version. is it tied to plasma somehow?

as for the bug where you lose input after holding alt and selecting a new brush preset, it seems to go back quite some time. at least krita 4.2. the OS wouldnt let me open krita 4.0 for some reason.
Comment 8 ryan 2023-02-24 01:11:38 UTC
(In reply to Halcyoen from comment #7)
> i have what i think is the same issue on kde neon. the issue appears
> whenever i press ctrl+alt or ctrl+shift. after this my canvas input command
> for the color sampler (alt+left click) or resizing the brush (alt+right
> click) stops working. the quickest way to "unblock" my canvas inputs is by
> pressing ctrl again.
> 
> this only seems to happen in the version downloaded from the official repos
> though. i do not experience this issue on windows, not with the appimage
> version and not with the flatpak version. is it tied to plasma somehow?
> 
> as for the bug where you lose input after holding alt and selecting a new
> brush preset, it seems to go back quite some time. at least krita 4.2. the
> OS wouldnt let me open krita 4.0 for some reason.

The problem happens to me with a fresh Ubuntu install on a virtual machine. I have used Kde for roughly 3 years now, and the problem has been consistent with every version past krita 5.0.2. In 5.0.2, there appears to be some version of this bug, but like you described, the key locking disappears after a short period of time. It's annoying, but still usable.
Comment 9 wolthera 2023-11-06 10:53:27 UTC
Hi, this probably has been fixed by https://invent.kde.org/graphics/krita/-/merge_requests/1935

Can you test if this still happens with the latest nightly?
Comment 10 Bug Janitor Service 2023-11-21 03:45:43 UTC
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!
Comment 11 Bug Janitor Service 2023-12-06 03:45:48 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now 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

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