Bug 368351

Summary: [UGEE] Pen cursor lags behind/doesn't respond when pen is hovering above tablet screen
Product: [Applications] krita Reporter: FramedInBlue
Component: Tablets (tablet issues are only very rarely bugs in Krita!)Assignee: Krita Bugs <krita-bugs-null>
Status: RESOLVED UPSTREAM    
Severity: normal CC: bashteem1, duminil, halla, johnsonkashe
Priority: NOR    
Version First Reported In: 3.0   
Target Milestone: ---   
Platform: Other   
OS: Microsoft Windows   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: I replicated the problem for a few seconds using Krita 3.0 and recorded the activity using DebugView

Description FramedInBlue 2016-09-06 18:30:30 UTC 
Created attachment 100957 [details]
I replicated the problem for a few seconds using Krita 3.0 and recorded the activity using DebugView

The pen's cursor will lag behind the pen's movement, on the canvas. The cursor will not lag while it is over any tool-bars, or anywhere outside the canvas itself. As long as I am constantly pressing my pen down on the canvas, the cursor moves at the pen's pace, with no lag. If I lift up the pen slightly above the tablet's screen, the cursor freezes, and when contact is made by the pen on the screen, it will draw a line connecting the two places; where I lifted and pressed the screen. None of the above affects the pressure-sensitivity of the tablet; it's working fine. 

Reproducible: Always

Steps to Reproduce:
1. Make sure your UGEE 2150 Tablet is able to open Krita 3.0
2. Open a new, blank canvas (canvas dimensions, canvas colour, etc do not matter)
3. Once the canvas has loaded, place the tip of the pen on the screen, and attempt to draw a straight line (without the tip leaving the screen)
4.  Now lift the pen slightly above the screen as you continue to move

Actual Results: 
The cursor stops following the pen's movement

Expected Results:
The cursor should continue to follow the pen's movement

Additional Information:
I first attempted to install a new UGEE 2150 driver, here: http://ugee.net/download.asp
but it wouldn't solve the problem. I have also tried using older versions of Krita, namely 2.99.89 and 2.8.79.22, but that didn't solve it either. I have made a file using DebugView, and attached below.
Comment 1 Emily 2016-10-19 22:58:01 UTC 
I'm having this same problem with a Ugee M100L. The only other thing I can find about this issue is another thread from 6 months ago that was abandoned unsolved ( http://kde-bugs-dist.kde.narkive.com/DIqohI3b/krita-bug-361515-new-brush-cursor-doesn-t-follow-ugee-tablet-pen-on-hover ). Did you ever fix this or does anyone have a solution?
Comment 2 Halla Rempt 2016-10-20 09:36:15 UTC 
No, I did not fix this. We don't have Ugee hardware to test with. Until Ugee or someone else donates the hardware, we cannot fix Ugee-specific bugs.
Comment 3 Halla Rempt 2016-10-20 09:36:43 UTC 
Let me rephrase that: we cannot code workarounds for bugs in the wintab drivers provided by Ugee.
Comment 4 Julien Duminil 2016-12-01 00:04:13 UTC 
Hello,

I bought a XP-Pen Star 03 and I am experiencing the same kind of problems.
My guess is that this bug is related to bugs 363284 and 367618.

To be more precise on what's happening to me:

The *outline shape* on the canvas stops to follow the *cursor shape* when I lift up the pen slightly above the tablet, even after putting down the pen near the tablet surface. Note that the *cursor shape* still follows the pen!
I have enabled *outline shape* and *cursor shape* in general settings to actually see the desync, so those who have not enabled *cursor shape* see the *outline shape* as freezed (as in bug 367618). The brush starts to sync again with the cursor when the pen touch the tablet (making strokes as in bug 363284), or when the cursor goes out of the canvas, or when I press a pen button, or when I move the mouse. Note that the *cursor* is *always* moving well with the pen, inside Krita and outside of Krita.

From what I'm understanding by reading the related bug reports, it may be related to the wintab driver not handling very well the proximity notifications. Are there reasons for the brush to not follow the cursor position? (precision?) Maybe you can try to reproduce the bug by introducing in the code some fake random TabletLeaveProximity (if it is the culprit)? Or maybe we could have an option to process TabletMove whatever TabletEnterProximity/TabletLeaveProximity said (if it's not already the case, I've not seen the code actually, just the logs from another thread)? Or an option to always use the mouse position instead of the tablet position?

I hope this brings you some useful informations. Tell me if I can be of any more help to solve this issue.

Additional Information:
I am on MS Windows and I reproduced the bug with latest stable Krita 3.0 and with Krita 3.1 Release Candidate. I did not tried any Krita 2.9.

PS:
Thanks for the great works you've done with Krita!
Comment 5 Halla Rempt 2017-03-03 08:59:45 UTC 
Please check the latest drivers: https://www.reddit.com/r/krita/comments/5x5ick/ugee_users_a_new_driver_was_released_covering/

In general, we don't support ugee because we haven't got the hardware -- and in cases for other non-wacom tablets where we do have the hardware, it often turns out that the drivers are bad enough that some things just cannot be implemented.
Comment 6 Halla Rempt 2017-03-03 10:50:51 UTC 
Given that we have had a "no issues anymore" report in that link, I'm closing this report. We cannot work around all broken drivers anyway...