It might be due to it not sending mouse down/up events when pen events are accepted... Not sure if I should have it always send mouse events or try to fix KisInputManager? (But any changes to KisInputManager might break some other tablet's WinTab handling...)
reminds me of https://bugs.kde.org/show_bug.cgi?id=387807 ...
Nah, it's different, even though both issues are somehow related to the mouse event blocking function.
Git commit b0dbfeb13c368ce262a2e959fd1ffa0bca32f099 by Alvin Wong. Committed on 12/12/2017 at 15:56. Pushed by alvinwong into branch 'master'. WinInk: Simulate native mouse events for handled pen events The code now simulates native mouse events with `SetCursorPos` and `SendInput` for pen pointer events whose QTabletEvents are handled by the widgets, so that the cursor position is updated to get correct results from QCursor::pos(). Related: bug 386475 Differential Revision: https://phabricator.kde.org/D8801 M +102 -15 libs/ui/input/wintab/kis_tablet_support_win8.cpp https://commits.kde.org/krita/b0dbfeb13c368ce262a2e959fd1ffa0bca32f099
Git commit 2ae618848b4fd9ca76bc71abd41a9f41fb328d5e by Alvin Wong. Committed on 12/12/2017 at 16:04. Pushed by alvinwong into branch 'krita/3.3'. WinInk: Simulate native mouse events for handled pen events The code now simulates native mouse events with `SetCursorPos` and `SendInput` for pen pointer events whose QTabletEvents are handled by the widgets, so that the cursor position is updated to get correct results from QCursor::pos(). Related: bug 386475 Differential Revision: https://phabricator.kde.org/D8801 (cherry picked from commit b0dbfeb13c368ce262a2e959fd1ffa0bca32f099) M +102 -15 libs/ui/input/wintab/kis_tablet_support_win8.cpp https://commits.kde.org/krita/2ae618848b4fd9ca76bc71abd41a9f41fb328d5e