@abrahams T959 still happens when there is a notification popup in the desktop, for a moment the problems comes back till the notification popup is shown. I am on kde plasma I don't know about other DE's . I have commented on the task, but since it is marked as resolved i am commenting here too, sorry for spamming.

@kamathraghavendra Is there any chance you could record a tablet log of this behavior? I actually removed the old fix 17ea12afc530e1bc5137880b91c99f07fa73e856 following dmitryK's rewrite of the tablet code since it didn't seem necessary anymore (and I think it broke something else), but now I don't know exactly how the input event sequence on your machine looks.

Hello @abrahams the tablet output is long so i am uploading a text file please have a look.

Ah, interesting, I think I see where the problem is coming from. There are a few places in the log like this. It seems the popup causes an extra "Enter" event, which messes things up.

(Apparently the enter event causes the tablet handler to stop ignoring mouse events. The MouseButtonPress event should be blocked, but it gets sent to the tool instead, and that will produce a full pressure splotch.)

krita.tabletlog: Stop ignoring mouse events.
krita.tabletlog: "[       ] TabletPress      btn: 1 btns: 1 pos:  639, 197 gpos:  666, 307 hires:  665.712, 307.108 prs: 0.129395 Stylus Pen id: 794761888230 xTilt: 38 yTilt: 23 rot: 0 z: 0 tp: 0 "
krita.tabletlog: Start ignoring mouse events.
krita.tabletlog: "[       ] Enter            "
krita.tabletlog: Stop ignoring mouse events.
krita.tabletlog: "[       ] MouseButtonPress btn: 1 btns: 1 pos:  638, 197 gpos:  665, 307 Source:0"
krita.tabletlog: "[       ] TabletMove       btn: 0 btns: 1 pos:  638, 197 gpos:  665, 307 hires:  665.455, 307.495 prs: 0.431152 Stylus Pen id: 794761888230 xTilt: 38 yTilt: 23 rot: 0 z: 0 tp: 0 "
krita.tabletlog: Start ignoring mouse events.
krita.tabletlog: "[       ] TabletMove       btn: 0 btns: 1 pos:  638, 198 gpos:  665, 308 hires:  664.896, 308.036 prs: 0.436035 Stylus Pen id: 794761888230 xTilt: 38 yTilt: 23 rot: 0 z: 0 tp: 0 "
krita.tabletlog: "[BLOCKED] MouseMove        btn: 0 btns: 1 pos:  637, 198 gpos:  664, 308 Source:0"

https://bugs.kde.org/show_bug.cgi?id=359561 < someone made a proper bugreport for it with tablet logs.

https://bugs.kde.org/show_bug.cgi?id=359171 < another bugreport with two-three tablet logs.

I am able to replicate Bug 359561 in Windows, hopefully it will be easy to solve.

Bug 359171 is a head scratcher, because I can't currently replicate it. The logs have an odd look to them, sort of like the logs where Qt's built in tablet support was still turned on. There are many tablet events with repeated coordinates and events where hires coordinates are whole numbers, both of which should be rare.

one more bug report stating similar findings , i have also added a video demonstrating it. i think this one and the notification popup bug is related too
https://bugs.kde.org/show_bug.cgi?id=349422

I think these two bugs are the same, and that D1174 is a reasonable workaround.
https://bugs.kde.org/show_bug.cgi?id=359561
https://bugs.kde.org/show_bug.cgi?id=349422

@kamathraghavendra: The bug that I tried to fix for those two only occurred on windows. The error you report in 349422 doesn't have to do with the tablet buttons changing function, but rather because Krita is ignoring some input events. I don't those Windows bug reports are related to the ones you're experiencing, though your missed stroke bug may be related to your popup splotch bug.

This bug is still mysterious.
https://bugs.kde.org/show_bug.cgi?id=359171

I did try to organize all tablet bugs in bugzilla :-)

Just wanted to update that with qt 5.6 I am not experiencing any issues related to tablet now, not the popup or button problem. I am going to test it thoroughly though.

The notification issue is also gone in 5.6 . and also the canvas hang when switching windows.

Thank goodness!

Here's the full list in bugzilla:

https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&component=tablet%20support&list_id=1350140&product=krita&query_format=advanced

The reports are basically about two things:

• broken button remapping
• broken monitor mapping

Hm, as for https://bugs.kde.org/show_bug.cgi?id=362933, the first tablet-related commit after the last version that was reported to work is immediately suspcious:

commit 23596b92c5f1ad05379ac4e7f65a1350a6e5f2ba
Author: Michael Abrahams <miabraha@gmail.com>
Date: Tue Mar 15 09:40:48 2016 -0400

Support DPI switching in Wintab coordinate scaling

Read current DPI from qApp->activeWindow->devicePixelRatio()

I'll look into this tomorrow.

If I look at https://bugs.kde.org/show_bug.cgi?id=362948 then this output sort of hints why the trust and similar tablets crash:

00000035 18.18015862 [3608] krita.tabletlog: # Getting current context data:
00000036 18.18021774 [3608] krita.tabletlog: lc.lcName = 0x23bef0
00000037 18.18025589 [3608] krita.tabletlog: lc.lcDevice = 0
00000038 18.18026352 [3608] krita.tabletlog: lc.lcInOrgX = 0
00000039 18.18029213 [3608] krita.tabletlog: lc.lcInOrgY = 0
00000040 18.18032265 [3608] krita.tabletlog: lc.lcInExtX = 65535
00000041 18.18035698 [3608] krita.tabletlog: lc.lcInExtY = 65535
00000042 18.18038940 [3608] krita.tabletlog: lc.lcOutOrgX = 0
00000043 18.18040848 [3608] krita.tabletlog: lc.lcOutOrgY = 0
00000044 18.18042564 [3608] krita.tabletlog: lc.lcOutExtX = 65535
00000045 18.18043900 [3608] krita.tabletlog: lc.lcOutExtY = -65535
00000046 18.18045235 [3608] krita.tabletlog: lc.lcSysOrgX = 0
00000047 18.18046379 [3608] krita.tabletlog: lc.lcSysOrgY = 0
00000048 18.18047714 [3608] krita.tabletlog: lc.lcSysExtX = 1600
00000049 18.18048859 [3608] krita.tabletlog: lc.lcSysExtY = 900
00000050 18.18050385 [3608] krita.tabletlog: Qt Desktop Geometry QRect(0,0 1600x900)

It looks like some drivers put the actual information int he SysExtX/Y fields, not the InExtX/Y fields