Sorry warning : I probably don't have enough info to correctly fill this bug report, but the buggy behaviour is so annoying and I can't continue debugging without some guidance… I use Krita 3 Beta on Archlinux (Antergos distrib) build from AUR (git 8ff1a4c) on a new shiny (since a few months) Wacom Cintiq 27 Touch tablet, with Gnome 3.20, libwacom 0.18 and xf86-input-wacom 0.32 on an AMD gpu and OpenGL enabled… When Krita start, everything is fine : mouse events are correctly separated from pen events and touch events. Sometimes, and I can't figure out right now what is triggering the bug, the pen events are locked in a sort of "drag and drop" (or continuously clicking) with every interface element of Krita (dockers, popup palette, and so on…), but not the Canvas. So basically the interface become barely usable, and I must stop drawing. Please see the attached video. Additionally, changing window focus and coming back to Krita (see video at 1:14) directly on the canvas result in the system cursor not hiding. I can't figure out if it's linked or not to the continuous clicking behavior. Sometimes simply triggering a touch event resolve the issue. Sometimes I have to close an reopen Krita. Sometimes I even have to log off my session and log again. There is probably some upstream issue related, but this bug occur only in Krita 3 (not 2.9), and not in Gimp or Mypaint (opening both software at the same time prove it). This happen quite often, and I won't be able to use Krita 3 for long if this issue is not solved one way or another… This is happening since I'm testing Krita 3 from several weeks. I waited to know more, but I can't find out where to dig to be more precise. Is there some command line tool I can use to give you a better bug report ? what do you need me to provide ? Thanks again for you great work ! Reproducible: Sometimes
Video uploaded here (file was too large) : https://drive.google.com/open?id=0B-5J--XsvWh-LWFVM0pjRTdSa0E
For lsmod, xinput, and xinput list-props : https://paste.kde.org/pikypoadn a tablet log event where the strange behavior partially occured, and finished by a crash… : https://paste.kde.org/pvgt2lcra I'll try to provide a better log later…
Best attach the log files to the bug report -- paste.kde.org is not a stable location to refer to.
Created attachment 99092 [details] krita bug363225 better tablet log events So here is a more genuine tablet log where the bug occured from krita start. For the paste.kde.org I followed the Krita Faq advice : https://docs.krita.org/KritaFAQ logs before are published for one year, if needed I attach them back here.
Happen both with open source ati radeon drivers and amdgpu drivers (My card is a Radeon R9 290)
May be related to Bug 344415 (can't reproduce) Seem to happen when switching from pen to mouse or from mouse to pen.
I'm trying to reproduce… and I'm close to it but a partial behaviour can be obtained like this : 1/ pen away from the tablet, zoom or unzoom with a touch pinch 2/ holding the touch event, let the pen enter tablet detection HOVER THE INTERFACE (not the canvas) 3/ Most of the time the touch event is stopped, but the pen is left in this "drag and drog" state, clicking everywhere. Some times it doesn't happen... may be dependant on the exact input when the pen detection start or where the cursor appear on the interface, I can't define it more precisely now.
A variant without touch events : 1/ pan on the canvas with the middle mouse button 2/ while panning with the mouse, let the pen enter tablet detection over the interface 3/ pen cursor is locked in an "always panning" state until I trigger a right click or middle click with the pen So… my guess is that an extremely unusual behaviour with mouse and pen (pan with mouse + the pen enter detection on the interface), is now common with touch events now Krita use them on the canvas : for example it's easy to accidentally trigger a touch event with left hand while removing the pen from detection to grab the mouse, do some click, and come back to the tablet over the interface (because it's on borders) so pen enter detection while the canvas is slightly panning or zooming with left hand. Is it possible to stop any "hold" event (pan, zoom, drag) when the pen enter detection ?
I think that this bug and 363283 are actually the same thing. *** This bug has been marked as a duplicate of bug 363283 ***
No, no, sorry : I can't reproduce Bug 363283, I observed sometimes the system cursor over the brush outline (see video at 1:14), but for me it's both of them at the same time, and more importantly, it's not the same bug importance : In this case, Krita become almost UNUSABLE (because ALL buttons the interface are broken except the canvas) until input is correctly detected again, most of the time needing to close Krita or the system session. I can draw with a bad cursor in mirror + erase mode, I can't with an interface locked in an always clicking state. So I classified this bug as "Grave". Can you reproduce the steps I detailed before with a touch tablet ? But I admit my Qt version is 5.6, as probably the same as in the the other bug.
As if it's not awful enough, the bug occur even if I disable touch events with : xsetwacom set "Wacom Cintiq 27QHD touch Finger touch" Touch off confirmed with Krita 3 release too…
Can't reproduce the steps at comments 7 and 8 with a Wacom Cintiq Companion 2 under Windows 10. It's probably Linux only.
I installed the latest plasma desktop, tested Krita with it and the bug occurred, and the whole Plasma desktop became totally stuck in clicking state. So I was clicking everywhere by simply hovering any interface. This bug is driving me crazy, and basically I'll need to abandon Krita if this is not fixed a way or another… : I can't spend several hours a day rebooting because of this. I understand this is linked to some upstream bug, but can you PLEASE give me some advice on how to report this correctly and where in the QT/KDE maze ?
After a discussion on the Linux Wacom mailing list : https://sourceforge.net/p/linuxwacom/mailman/message/35151033/ Jason Gerecke, the Linux Wacom maintainer was able to reproduce on a Cintiq 24 HD Touch and confirmed it's probably a Qt bug. I just started a Qt bug report here : https://bugreports.qt.io/browse/QTBUG-54085 Any confirmation from others Krita users would be welcome though ;)
This might still be a bug in krita, since we handle tablet evens on Linux outside Qt. But we re-use the Qt code, so the bug might come from there. I haven't been able to reproduce the bug myself, though.
So, what can I do to help more ? Do you need more logs ? On which hardware did you try to reproduce ? What do you think of Jason Gerecke insight : "It almost sounds like Qt is dropping events from other devices once the pen comes in proximity, and doesn't always properly clean up their state by releasing any buttons that may have been pressed." Is Krita dropping events from other devices when the pen enter detection ? Thanks again for your hard work !
I can reproduce Comment8, too. But in my case, only a middle click can release Krita from the move lock state. Tested on Ubuntu Gnome Edition 16.04, Krita 3.0 from Krita Lime PPA, Intuos4. I don't have a touch sensitive tablet so I couldn't test comment7.
Thanks Tyson !
Another user (Jasper Mattsson) confirmed this is also happening with a Lenovo Thinkpad Yoga S13 : https://bugreports.qt.io/browse/QTBUG-54085 In a desperate attempt (because this is really annoying for my daily work), I wiped and reinstalled my Linux distribution (Antergos) entirely, reinstalling only the Gnome desktop environment and Krita and Scribus dependencies on the Qt side (attica-qt5, libdbusmenu-qt5, phonon-qt5, phonon-qt5-vlc, polkit-qt5, qt5-base, qt5-declarative, qt5-script, qt5-svg, qt5-tools, qt5-x11extras, qt5-xmlpatterns, sonnet). Interestingly, touch events aren't detected in Krita now (I can't pinch to zoom for example), but they are on the Gnome side. I suppose there is one (Qt) lib missing, I don't know which one. Any idea ? And after a week of daily work I can say the bug is not occurring without touch events. If something similar happen, any new click will "unlock" the clicking state. So this is happening, but no need to restart X to stop it. So this is really an upstream bug, do we close here ? At least it should be marked as confirmed (I can't do it)... Thanks again !
Hi, Camille! Did you try to run AppImage version of Krita? The point is, into AppImage we put a patched version of Qt, with some tablet-related bugs fixed. Does it also happen with AppImage?
Also related to this bug is Bug 363283. I'm using appimage 3.0.1 beta on Ubuntu Gnome 16.04.1. That bug still happens from time to time, although it doesn't feel as frequent as when I reported it, or it's just because I've found a very easy work around for it -- when it stuck to cursor mode, move the cursor out of the canvas and then move back -- it's free now.
@Dimitry I can't reproduce with the Appimage, because I didn't found which QT package is responsible for a real touch input since I reinstalled my whole distribution (I can't pinch to zoom in Krita now)... And I'm not really wanting to try… to be able to continue using Krita 3 ... But, if you can say to me which package or setting I should install or enabled, I'll try... ! In the meanwhile, I noticed a little note in the Input-wacom 0.32 release : https://sourceforge.net/p/linuxwacom/mailman/message/35257555/ " Fix a Cintiq 27QHD touch issue" So maybe it's fixed, I'm waiting for the package (linux kernel) to land stable on archlinux...
Hi, Camille! I didn't understood, were you able to to run the AppImage in the end? The point is that AppImage has a patched version of Qt, so it should work differently from what is compiled using the system library. Here is the link to the latest AppImage present: http://files.kde.org/krita/3/linux/devbuilds/krita-3.0.1-Alpha2-d33dbe0-x86_64.appimage
Hi Dimitry, sorry if I have been unclear. Yes, I ran the Appimage (and the Alpha 2 equally). they both work, as my packaged Krita. But none of these are actually correctly enabling touch events, so I can't reproduce the bug. Since I reinstalled my system (see comment 19), I lose touch events support, but the bug is not occuring. So my guess is that there is a library or setting missing to enable touch events in Qt or Krita, because they work in Gnome, but I don't know which one despite my blind tentatives with various packages to enable it again. Said in another way : before I was able to zoom in and out smoothly into Krita 3 with my fingers, now I can't (touch event are really rarely detected, and are really lagging), and I don't now how to enable it again, so I can't reproduce my own bug anymore.
Okay, this is related to allowing touch events on Linux. Now that that has been disabled, this can no longer happen...