I am currently experiencing an issue under Krita 5.1.5 on Linux; I’ve been using the program with no problems during the week, but at some point I must have done something and now no matter how many times I restart Krita, ctrl-* shortcuts like ctrl-z and ctrl-q do not work.
unplugging tablet in case it was a stuck hardware key - tablet remained unplugged for the rest of the tests
restarting Krita (ensuring process is killed)
removing Krita related dotfiles inder .config/ and also .local/share/krita*, killing Krita processes then reopening
installing the latest successful Krita nightly build (#1870), removing files under .config for a fresh start, starting Krita
restarting my computer, retrying item above
but problem persists.
The ctrl-z combination works in other programs and I do not have stuck keys per xinput query-state.
Given that this happens across two Krita versions built independently both with stock user configuration, this has to be either something environmental on my machine or a program bug.
Happy to provide more info and/or create a bug in the tracker; posting this here for visibility.
In ~/.local/share, the resources folder is called krita. It has some configuration files in it.
With the application not running, rename that folder to krita-previous and then start the application and see if that fixes the problem.
I see that you tried a nightly appimage. It’s always better to use the appimage instead of a repository build.
(Hello @Michelist )
I first noticed the issue late yesterday (2023-06-16) and all of these upgrades happened very early local time so all of the above happened before the issue started. Doesn’t look like there’s anything Qt related in there though.
Hello @AhabGreybeard, then a Linux expert has already joined, and I can pack my half-knowledge again.
@ldmosquera : But I still have a tip, it is recommended to use only the AppImages for Krita, instead of the versions from the repositories or wherever, because it is the only official version of Krita for Linux.
Oh, by the way, maybe a second one too. Have you possibly tried pressing the escape key to see if it unlocks the keyboard? Doesn’t have to help, but might with luck. I seem to remember that it helped another user in a similar situation.
Hi I’ve been using Krita for fine grained photography retouching for years and I absolutely love it.
Got it! I’ll make sure to use recent AppImages from now on.
Nope, esc does not help.
BUT, progress! I tried another Qt based application, Qutebrowser, and it turns out that I can’t use ctrl-* shortcuts there either, but I can in another machine with a different Debian version and thus probably very different Qt base libraries.
ctrl-tab works both in Krita and Qutebrowser but ctrl-LETTER doesn’t do anything in either.
So given this:
This is 99% likely the environmental issue: Qt got somehow busted on this machine. I really doubt it’s a Krita specific issue now.
That is one of the reasons to use the AppImage. Krita uses some patched libraries those it needs to work properly, the AppImages have them, most repo-maintainers believe it would be okay to have the current Qt-libraries on your system installed, that is one reason for support-requests in the forum. But your issue seems to sit somewhere else, because it is an OS-Independent issue.
The plot thickens; I just tried both the AppImage and Qutebrowser on an LXC container with Debian Bullseye (the previous version to the one on my machine, with corresponding older Qt libraries), and the problem is ALSO present.
Another Qt program (qterminal) has similar issues in this machine vs another one.
So yes, maybe it’s not Qt libraries but something else environmental like my window manager or X11 setup or the like.
In ~/.config is a file called QtProject.conf
Try some combination of deleting (or renaming) that, restarting the PC, or vice versa to see if that fixes the problem.
There may be other config files that could be involved, I don’t know where.
I had tried that as part of step 3 in my first post, but no luck.
OK, I found the issue, and it’s bizarre.
I hate the Capslock key and over time I’ve tried a few things to make sure it’s automatically disabled whenever my keyboard gets detected. Because for some reason it disconnects/reconnects recurrently, anything done with xmodmap gets lost so I have to redo it. I should use a udev rule for this, but it’s a longer story.
Among the things I tried over time, some weeks ago I found the /etc/default/keyboard file (description), from which Debian reads some variables to set some things via setxkbmap.
This seems to interact with Qt in surprising ways; as said above, this broke keyboard shortcuts based on Control for Qt applications, for both Debian Bookworm and Debian Bullseye versions of Qt. Clearly the issue in my machine is not the specific Qt version but something else, and this was it.
After reverting the above setting in /etc/default/keyboard to the default and restarting, the issue is gone Note that I had restarted before and that didn’t fix it, so a restart alone didn’t do it.
Anyways, thanks a lot for the troubleshooting help; I hope all this helps someone in the future.
@ldmosquera I’m glad you found the answer. I took the liberty of marking your last post as the solution so others coming here can find it right away if they have the same issue.
I don’t know if that was the best option since the person who started the post has windows, which is different from Linux, so the solution is not exactly the same.
@ldmosquera Your post has been moved into its own topic as the OP was asking about a Windows system issue, not Linux. Please feel free to create a new topic anytime you have an issue.
)
then a Linux expert has already joined, and I can pack my half-knowledge again. 
I’ve been using Krita for fine grained photography retouching for years and I absolutely love it.
Note that I had restarted before and that didn’t fix it, so a restart alone didn’t do it.