SUMMARY I lost pressure sensitivity at first stroke after switching from float docks (I use brush preset, history of brushes, artistic color picker) . It doesn’t happen each time, about 2/3 or 2/4. Screenshot: https://krita-artists.org/uploads/default/original/2X/e/e10a7fc50393190be95545ff60c1284afa648105.jpeg Video: https://youtu.be/6X9kABr41Zw The same effect if I switching from other program e.g. browser or video player back to Krita. In attached dock mode all OK except switching from other programs. It happens only in WinTab mode. WinInk doesn't have such bug (but alas have other) The current “First stump” issue is only Krita “feature” (other painting software is ok). I and other users tested it with the same result on various systems: Ryzen 1600 + GTX960 Athlon 200GE + internal GPU I3 6100 + internal GPU i3 4030 + internal GPU i7 9700K + RTX 2070 Intuos5, Cintiq 13hd + ProPen (KP-503E stylus) Systems used with Single Display and with Two displays. Windows 7, 8, 10 It seems concern only senior series of wacom tablets (Intuos 4, 5, Pro, Pro2 and Cintiqs). Wacom Intuos Draw ("Bamboo" types) doesn't have that issue. STEPS TO REPRODUCE 0. Need Wacom Intuos (from 4 up to Pro2) or any Cintiq 1. Be sure using WinTab mode 2. Undock (make float) color selector 3. Make a brush stroke, change color 4. Repeat №3 several times ADDITIONAL INFORMATION forum discussion link: https://krita-artists.org/t/no-pressure-at-first-stamp-in-floating-dock-mode/1847
Could you please make a tablet log, too? I'm afraid that it'll turn out to be a driver problem (because behaviour differs from tablet to tablet) and that we cannot do much, but a tablet log would show whether we get tablet events at all when the main window get focus. See https://docs.krita.org/en/contributors_manual/user_support.html#gathering-information
Changing status
(In reply to Boudewijn Rempt from comment #1) > Could you please make a tablet log, too? I'm afraid that it'll turn out to > be a driver problem (because behaviour differs from tablet to tablet) and > that we cannot do much, but a tablet log would show whether we get tablet > events at all when the main window get focus. See > https://docs.krita.org/en/contributors_manual/user_support.html#gathering- > information Log: https://invent.kde.org/uploads/-/system/user/983/a32e3b1523e13b830a4442380bdc7fbc/tablet_log2 Screenshot with strokes during logging: https://invent.kde.org/uploads/-/system/user/983/8d55a8e2fa16a9c3d60cb2ffe15fd424/tablet_log2_strokes.jpg
Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information.
I'm sorry, but those links are broken :-(
(In reply to Boudewijn Rempt from comment #5) > I'm sorry, but those links are broken :-( Hmm, log is opened without problem, only image has a problem. I reuploaded files to "yandex" https://yadi.sk/d/N0Nvg1auErvLgg
You don't need to update the version field; the version field indicates the version of Krita when the the bug was first discovered. Until the bug is fixed, it's assumed that it exists in all subsequent versions, too.
The relevant part of the tablet log: ################## "[BLOCKED 2:] MouseMove btn: 0 btns: 0 pos: 932, 463 gpos: 2852, 546 hires: 2852, 546 Source:0" "[ ] TabletMove btn: 0 btns: 0 pos: 928, 462 gpos: 2848, 545 hires: 2847.93, 545.185 prs: 0.000000 Stylus Pen id: 8805681213932 xTilt: 36 yTilt: 11 rot: 0 z: 0 tp: 0 " "[ ] TabletMove btn: 0 btns: 0 pos: 928, 462 gpos: 2848, 545 hires: 2848.18, 544.691 prs: 0.000000 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 " "[ ] TabletMove btn: 0 btns: 0 pos: 928, 461 gpos: 2848, 544 hires: 2848.3, 544.252 prs: 0.000000 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 " "[BLOCKED 2:] MouseMove btn: 0 btns: 0 pos: 933, 462 gpos: 2853, 545 hires: 2853, 545 Source:0" "[ ] TabletPress btn: 1 btns: 1 pos: 928, 461 gpos: 2848, 544 hires: 2848.42, 543.868 prs: 0.147526 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 " Accessing uninitialized random source! "[ ] TabletMove btn: 0 btns: 1 pos: 928, 461 gpos: 2848, 544 hires: 2848.42, 543.703 prs: 0.147526 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 " "[ ] Enter " "[ ] FocusIn " Stop blocking mouse events "[BLOCKED 1:] MouseButtonPress btn: 1 btns: 1 pos: 933, 462 gpos: 2853, 545 hires: 2853, 545 Source:0" "[ ] MouseMove btn: 0 btns: 1 pos: 933, 461 gpos: 2853, 544 hires: 2853, 544 Source:0" "[ ] TabletMove btn: 0 btns: 1 pos: 928, 461 gpos: 2848, 544 hires: 2848.42, 543.594 prs: 0.174383 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 " Start blocking mouse events "[ ] TabletMove btn: 0 btns: 1 pos: 928, 460 gpos: 2848, 543 hires: 2848.42, 543.484 prs: 0.179754 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 " "[ ] TabletMove btn: 0 btns: 1 pos: 929, 460 gpos: 2849, 543 hires: 2848.54, 543.484 prs: 0.188055 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 " "[ ] TabletMove btn: 0 btns: 1 pos: 929, 460 gpos: 2849, 543 hires: 2848.54, 543.484 prs: 0.197821 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 " "[ ] TabletMove btn: 0 btns: 1 pos: 929, 460 gpos: 2849, 543 hires: 2848.54, 543.484 prs: 0.239845 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 " "[ ] TabletMove btn: 0 btns: 1 pos: 929, 461 gpos: 2849, 544 hires: 2848.54, 544.087 prs: 0.255470 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 " "[BLOCKED 2:] MouseMove btn: 0 btns: 1 pos: 933, 462 gpos: 2853, 545 hires: 2853, 545 Source:0" "[ ] TabletMove btn: 0 btns: 1 pos: 929, 462 gpos: 2849, 545 hires: 2848.54, 545.404 prs: 0.269173 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 " "[BLOCKED 2:] MouseMove btn: 0 btns: 1 pos: 933, 463 gpos: 2853, 546 hires: 2853, 546 Source:0" "[ ] TabletMove btn: 0 btns: 1 pos: 928, 465 gpos: 2848, 548 hires: 2848.42, 547.654 prs: 0.287729 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 " ################## Basically when it changes focus out of Krita's window (and a floating docker probably is one), Krita stops blocking mouse events (since in Wintab Krita always gets both of them). The next window is of course also Krita, so Krita doesn't know yet that there is tablet involved: there was no "tablet is getting near the surface" event. So Krita gets both a mouse event and a tablet events. Since the mouse event is first, Krita create a stamp with 100% pressure. Then a tablet event comes and Krita starts blocking mouse events, but it's too late already... I bet that in the different app -> Krita it works the same way - Krita doesn't block mouse events because it doesn't know yet that there is tablet somewhere. Since this behaviour is most probably implemented by Qt, I'm not sure if Krita can do anything. I don't know which component is at fault here either.
Note: wintab only
Yes, I can reproduce the problem (even with a Huion tablet).
Git commit 4f98a20fbf2e64858b28ad22ca809d95c40a00be by Dmitry Kazakov. Committed on 04/09/2020 at 20:16. Pushed by dkazakov into branch 'krita/4.3'. Fix full-pressure blobs when using floating dockers On Windows tablet events may arrive asynchronously to the mouse events (in WinTab mode). The problem is that Qt generates Enter/Leave and FocusIn/Out events via mouse events only. It means that TabletPress may come much before Enter and FocusIn event and start the stroke. In such a case we shouldn't unblock mouse events. PS: Ideally, we should fix Qt to generate Enter/Leave and FocusIn/Out events based on tablet events as well, but it is a lot of work. M +0 -5 libs/ui/input/kis_input_manager.cpp M +0 -3 libs/ui/input/kis_input_manager.h M +21 -0 libs/ui/input/kis_input_manager_p.cpp https://invent.kde.org/graphics/krita/commit/4f98a20fbf2e64858b28ad22ca809d95c40a00be
Git commit 081c38c8763c94c79b132aafc99f1b087b88d421 by Dmitry Kazakov. Committed on 04/09/2020 at 20:27. Pushed by dkazakov into branch 'master'. Fix full-pressure blobs when using floating dockers On Windows tablet events may arrive asynchronously to the mouse events (in WinTab mode). The problem is that Qt generates Enter/Leave and FocusIn/Out events via mouse events only. It means that TabletPress may come much before Enter and FocusIn event and start the stroke. In such a case we shouldn't unblock mouse events. PS: Ideally, we should fix Qt to generate Enter/Leave and FocusIn/Out events based on tablet events as well, but it is a lot of work. M +0 -5 libs/ui/input/kis_input_manager.cpp M +0 -3 libs/ui/input/kis_input_manager.h M +21 -0 libs/ui/input/kis_input_manager_p.cpp https://invent.kde.org/graphics/krita/commit/081c38c8763c94c79b132aafc99f1b087b88d421