If I lift the pen away from the screen (beyond hovering range) while the cursor is on the canvas, when I put it back down on the canvas, the brush stays frozen where it is and does not move until I move the pen over another part of the screen (other than the canvas). If I lift the pen away while the cursor is anywhere other than the canvas, it works normally when I put it back down. This problem appeared after upgrading from version 2.8.1 to 2.8.2 Reproducible: Always Steps to Reproduce: 1.Hover pen over tablet so that cursor is anywhere on the canvas. 2.Lift pen away completely. 3.Put pen down straight back onto canvas and try to paint. The brush stays where it was. Actual Results: The brush stays where it was when the pen was lifted away and will not move. Expected Results: It should jump to wherever the pen comes back down and keep following it. X60 tablet with built in wacom digitizer
Hi, Thanks for your report. Could you start Krita on the command line like this: krita 2>tabletevents.log Then create an image, press ctrl-shift-t to enable tablet-logging, reproduce the bug, close Krita. And then check that tabletevents.log has a line like vvvvvvvvvvvvvvvvvvvvvvv START TABLET EVENT LOG vvvvvvvvvvvvvvvvvvvvvvv And if so, attach to this bug report?
Created attachment 86436 [details] tablet events log
Git commit df71665b3b19c19600ad9b854a4202a14d9cbc34 by Dmitry Kazakov. Committed on 12/05/2014 at 18:19. Pushed by dkazakov into branch 'master'. Added more extensive tablet debugging on X11 M +1 -0 krita/ui/CMakeLists.txt M +28 -90 krita/ui/input/kis_input_manager.cpp A +224 -0 krita/ui/input/kis_tablet_debugger.cpp [License: GPL (v2+)] A +53 -0 krita/ui/input/kis_tablet_debugger.h [License: GPL (v2+)] M +30 -4 krita/ui/input/wintab/kis_tablet_support_x11.cpp http://commits.kde.org/calligra/df71665b3b19c19600ad9b854a4202a14d9cbc34
I'm having the same problem. At times it also happens if the mouse is moved accidentally while moving the stylus. I'm using the 2.9 pre Alpha ( 2+git20140607+r75540-46-dk~ubuntu13.10.1 ) build from Lime, Built on 07-06-2014. My linux distro is Mint 16 KDE 64bit. My tablet is Wacom Intuos4. I have also attached my tablet events log.
Created attachment 87068 [details] tablet events log from aniruddha
Bug can be reproduced with same steps in the 'krita-testing 2+git20140620+r74942-47-dk~ubuntu13.10.1' build from lime as well. My apologies if this update wasn't necessary. Linux Mint 16 KDE 64bit, Wacom intuos4
I should add that I have openGL disabled (my Thinkpad tablet PC has no GPU).
Starting krita in terminal somehow rectfies this behaviour. :D
Having the exact same behavior, opening krita in terminal solve nothing for me. Happens either when openGL enabled or disabled. I am using: Krita 2.8.3-3 Wacom tablet Intuos4 xset-wacom fully functional This behavior doesn't happen in any other program/simple cursor use.
Created attachment 87530 [details] tablet events log for florax Here is my log. A lot of event lines starts with "BLOCKED" within square brackets
Since krita designed for natural painting like with the hand, I really think that this bug fits the "Major" importance... I forgot: a. I'm using updated Arch Linux, i686, my krita package is: calligra-krita 2.8.3 b. Thank you developers!! Krita is amazing!
As I had reported earlier, running krita from terminal solved it for me, however I looked more into it, and it turns out that removing the %U from the .desktop file linking to krita has the same effect. I suppose this pushes it more towards being a local installation issue than a proper bug, as Boudjewin had anticipated. Hope this helps. This also rectifies issues reported (by me in a hurry) in bugs 336806 and 336807. Could they be local too? Build: krita-testing (2+git20140707+r72759-49-dk~ubuntu14.04.1) OS: Linux Mint 17 x64 KDE
My apologies, there is a minor but important correction in my earlier comment. "This also SOMETIMES rectifies issues reported (by me in a hurry) in bugs 336806 and 336807."
I encountered such problem only with Krita 2.9 alpha. Krita 2.8 seems to work just fine. I can confirm the bug on Trisquel 6 (Ubuntu 12.04 derivative) and Trisquel 7 (Ubuntu 14.04 derivative). DE is Gnome Flashback 3.6/3.8. Hardware: Wacom Intuos 4, Wacom Intuos 4 Wireless USB connected, Wacom ISDv4E6. My first encounter of this bug happened in April 2014, back then I was too busy to do a research and I went back to 2.8. I thought it was a DE bug because I was using Trisquel 7 alpha. I recently switched back to Trisquel 6 and did not even use any major PPAs like Kubuntu-backports PPA for better stability. I am using the official LTS backport kernels and X.org from the main repository, though. I had used Krita 2.9 alpha for a week. In the beginning, it did not hit me with the same problem. I thought it was gone. But after I cleared the .kde folder and krita setting file on 20140712 to eliminate a setting corruption, this bug struck again. This bug does not aways happen. I couldn't figure out what triggers the difference. I've captured two tablet event logs: one when the problem did not occur, the other when the problem occured. Two tests were done in the same DE session, the regular one first, the irregular one second. Total 5 tests were done in that session, the results were: 1) Had problem 2) Had no problem 3) Had no problem 4) Had no problem (captured) 5) Had problem (captured) Hardware was Wacom Intuos 4 M. I will attach the tablet event logs later.
Created attachment 87708 [details] Tablet event log from Tyson Tan 20140712A This is a copy of the tablet event log when the bug does not happen.
Created attachment 87709 [details] Tablet event log from Tyson Tan 20140712B This is a copy of the tablet event log when the bug happened.
Both Krita Lime PPA, compiled from git source has this problem.
Hi, Tyson! Do I understand it right that the freeze goes away as soon as you leave the mouse out of the canvas widget and moves it back? What is the condition that unfreezes the stylus?
> Comment 18 Hi Dmitry, Yes, 1) Freeze happens, cursor cannot be seen on canvas. 2) Move cursor out of canvas, probably unfreeeze canvas by doing this. 3) Move cursor back in and everything works When I was using Trisquel 6 (Ubuntu 12.04 base), Krita 2.8 did not have this bug, only Krita 2.9 alpha had. I tried Trisquel 7 early alpha, it also had this bug. I used Saucy backport X.org and kernel on 12.04. Those were probably the only things I changed on system level. However, now I am using a near-final-version of Trisquel 7 (Ubuntu 14.04 base), I can't reproduce this bug anymore.
Hi, All! Can anyone still reproduce the bug? Tyson said the bug disappeared after an update of his Ubuntu, so I tend to think it is some distribution/driver issue... I will mark the bug as NEEDSINFO. If you still see the bug, please reopen the bug as UNCONFIRMED or REOPENED again.
I'm still getting the problem in Krita 2.9 pre-alpha on Kubuntu 14.04 32bit.
Ignore that last comment, I tried purging and deleting all my config files and brushes; removing krita, rebooting and reinstalling krita and the problem seems to be fixed. It must have been something left over from a previous version or something. Thanks for the help.
Git commit 91f14b1a33f05adfdad8c39fc98a309edc10f1f7 by Dmitry Kazakov. Committed on 12/05/2014 at 18:19. Pushed by dkazakov into branch 'calligra/2.8'. Added more extensive tablet debugging on X11 M +1 -0 krita/ui/CMakeLists.txt M +28 -90 krita/ui/input/kis_input_manager.cpp A +224 -0 krita/ui/input/kis_tablet_debugger.cpp [License: GPL (v2+)] A +53 -0 krita/ui/input/kis_tablet_debugger.h [License: GPL (v2+)] M +30 -4 krita/ui/input/wintab/kis_tablet_support_x11.cpp http://commits.kde.org/calligra/91f14b1a33f05adfdad8c39fc98a309edc10f1f7
I guess the bug has been fixed in the meantime. If you still encounter this bug, please add your comment and reopen the report by setting it to REOPENED state
OK, Thank you Dmitry!
Hello. I'm having the same problem with my wacom intuos art medium tablet (CTH-690AK) on Linux Mint 17.3. This line of tablets doesn't seem to be recognized by Linux yet. Mine works but when I open Graphics Tablet it says 'No tablet detected' so maybe the bug is related to the wacom model.
Perhaps the next version of mint will solve this problem. I think Mint ships with libwacom, however any new devices added to libwacom libraries aren't added until a new version of Mint is released. Also, waocm has notoriously released too many new devices recently.
I'm having this problem as well. The brush works fine while in brush settings using the preview window, but when I go back to the canvas to pain the pressure sensitivity just isn't there. The pressure may start working for a moment, but then the brush immediately freezes. If I take the brush out of the canvas then try to go back in, it'll freeze on the edge. Here is my system info: Tablet: wacom intuos 4 Operating System: Windows 10 Krita version: 3.0.1.1
Hi Catherine, Does it help if you disable opengl? If not, could you make a tablet log and create a new bug with the information (https://docs.krita.org/KritaFAQ#Tablets). This bug was specific for 2.8 and Linux, so your issue is different.
I’m having the same issue, with some differences. 1)I’m using a Wacom Intuos CTL-490 2) I’m running krita on a 32-bit operating system and a x64-based processor. I’m not sure if those two points have anything to do with my problem, but if anyone has any idea on how I can fix it i’d appreciate
Aaaa: "a 32 bits operating system" -- which one? If it's not Linux, you do not have "the same issue". Which version of Krita are you using?