It came up after I updated my computer (Lenovo Yoga 520) to Windows 10, version 1709. Whenever I use the pen, while simultaneously pressing the keys (ctrl+z, spacebar, etc), it would not respond or simply stays in that function until I use a mouse to switch out of/use it. I've tried downgrading Krita from ver 3.3.1 to 3.2 and even installing older Wacom Feel drivers from version ISD_7.3.4-47 to 7.3.4-36, but it still shows the same problem. When I completely remove all instances of Wacom Feel driver; with my pen functioning as a bare minimum of a mouse pointer, the keys seems to behave normally. I suspect it could be the Windows 10 update causing all these problems. I do hope you could look into it, before I consider the option of rolling back my windows update. Thank you in advance.
I seem to see the same behaviour on Surface Pro 2017 with ver 1709 when using WinTab, but no such issues with Windows Ink, so it might not be a Wacom-WinTab-driver-specific bug. I'm not sure if this was working as expected before 1709, but this definitely needs some investigation.
Hi, would you mind testing these two configs? 1. In configure Krita, go to tablet settings and switch to Pointer Input (Windows Ink), then restart Krita and test it. 2. See if the Wacom Feel driver offers an option to disable "Windows Ink". If it does, disable it, go back to Krita tablet settings and switch back to WinTab, then restart Krita and test again.
Hi, thank you so much! Just carrying out the first step did the trick. Does this mean wintab is obsolete?
No. Can you test config 2? > 2. See if the Wacom Feel driver offers an option to disable "Windows Ink". If it does, disable it, go back to Krita tablet settings and switch back to WinTab, then restart Krita and test again.
So, I suspect that MS decided \it is a good idea to synthesize touch events from pen input... It goes like this: 1. Pen event is sent through WinTab and Windows Ink by the driver 2. Krita takes the pen event from WinTab 3. Windows sends pen pointer events to Krita (since no lower level Windows Ink APIs are in use), which are ignored 4. Something (I'd guess DefWindowProc) then synthesizes touch events, and then mouse events 5. This probably upsets KisInputManager in some way? I'll try to do a bit more digging...
Git commit 66bf329335dd9b8bbf23ca59e854e149b5ba112b by Alvin Wong. Committed on 22/10/2017 at 13:44. Pushed by alvinwong into branch 'krita/3.3'. Fix WinTab pen action not released on Windows ver 1709 Windows starts synthesizing touch events from "unhandled" Windows Ink pen events and causes the WinTab pen release event to be incorrectly ignored. This is known to affect certain non-Intuos Wacom tablets and N-Trig devices. (Pointer Input API is not affected.) M +0 -1 libs/ui/input/kis_input_manager.cpp https://commits.kde.org/krita/66bf329335dd9b8bbf23ca59e854e149b5ba112b
Git commit 74b771f12200cfa8653672f5bbfbd2ddf42972c1 by Alvin Wong. Committed on 22/10/2017 at 14:00. Pushed by alvinwong into branch 'master'. Fix WinTab pen action not released on Windows ver 1709 Windows starts synthesizing touch events from "unhandled" Windows Ink pen events and causes the WinTab pen release event to be incorrectly ignored. This is known to affect certain non-Intuos Wacom tablets and N-Trig devices. (Pointer Input API is not affected.) M +0 -1 libs/ui/input/kis_input_manager.cpp https://commits.kde.org/krita/74b771f12200cfa8653672f5bbfbd2ddf42972c1
*** Bug 386276 has been marked as a duplicate of this bug. ***