Windows 10 Pen input
Open, Needs TriagePublic

Description

System Information
Windows 10 Home build 17134
Toshiba convertible with touch/pen screen (Wacom 0x056A, 0x50A2, driver/utility 6.3.31-4 aka 7.3.4.48, wintab.dll 1.0.5.9)

Blender Version
Broken: 2.79b f4dc9f9d68b (2.80 alpha also)

Short description of error
Grease pencil stroke does not start on touch, but only after some time or distance (not clear)

Exact steps for others to reproduce the error
Start blender
Open default
Draw with any grease pencil (radial strokes from one starting point, or zig zag lines

Details
I have been digging around a little and found a few other reports of similar issues (also see further down, some blender issue reports):

https://blender.stackexchange.com/questions/118019/stylus-delay-in-grease-pencil
https://blender.stackexchange.com/questions/120009/painting-problem-when-using-pen-in-blender

The latter points to https://www.reddit.com/r/Windowsink/comments/8508fi/controlling_pen_behavior_in_windows_10/ from March 2018 where Microsoft inform about a Windows update where a registry "hack" can affect (revert?) the changed behaviour (LegacyPenInteractionModel).

Controlling Pen Behavior in Windows 10

Greetings to the Windows Ink Community!

In response to overwhelming feedback from our Windows Insiders, the Windows 10 Fall Creator’s Update changed how the pen behaves when it isn’t doing its primary function of laying down ink. The pen now scrolls/pans content, but the previous behavior of lasso/text selection is still accessible by depressing the barrel button before making contact with the screen.

To deliver a consistent experience we also changed the behavior for legacy Win32 applications that weren’t specifically designed for pen. These applications instead rely on Windows to convert pen input into another form of compatible input, such as mouse. While we try to test as many of the most popular applications used with pen before releasing, there is a chance that one of your favorite applications wasn’t covered as part of our validation, relies on input conversion, and may not function as intended after this change.

While we closely monitor application compatibility issues and work with our developer community to resolve them, we understand that in the interim you need to use that app. Starting with Windows 10 build 17110, we’re putting you in control of your pen experience with legacy applications.

By executing the following from an elevated command line, the next time any legacy application starts it will get the prior pen behavior from the Windows 10 Anniversary Update: “reg add HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Pen /v LegacyPenInteractionModel /t REG_DWORD /d 1 /f”

Anytime you want to switch legacy applications back to the behavior introduced in the Windows 10 Fall Creator’s Update, execute this: “reg add HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Pen /v LegacyPenInteractionModel /t REG_DWORD /d 0 /f”

The Windows Ink team is working on improving the UX for controlling this via our settings UI in a future flight and we’ll keep you posted as this progresses. We really appreciate your feedback and would love to receive more of it! For our Windows Ink fans, please check out the most natural way to enter text with your pen with inline handwriting in the latest insider builds. You can now handwrite directly in to the text boxes of UWP applications with your pen; simply tap in the text field and start writing!

 Thanks,  David

WindowsInk@microsoft.com

However, this did not work for me (in addition to disable some Flick and other Pen options as well as Blender's Continuous Grab and trying newer/older Wacom divers).
So I can't use the pen input I'd like to use very much for Grease Pencil (unless I boot Ubuntu and do it there...).

I found other reports that might be related, notably
https://developer.blender.org/T55589 Microsoft Surface pens does not send first events when moves
and others
https://developer.blender.org/T53601 Microlag on tablet pc.
https://developer.blender.org/T53621 Surface Book 2 pen pressure sensitivity issue
https://developer.blender.org/T57151 Graphics Tablet Problem

So it might be that Windows broke something, but blame is not helping, so I would like to ask if someone could revisit the pen input handling to figure out the current "state of the art" - whether this is really a bug by Microsoft and a workaround is available or maybe some API has changed that should be supported by Blender (WinTab apparently is at V1.0.5.9). Other programs seem to have no problem with the changes - are they using a workaround or new API?

Of course I'd be glad contribute mouse/touch/pen event logs etc. for my hardware if you let me know how (don't have a build environment).

I was not able to find a program to test mouse/touch/pen events, but came across some API links and further bug reports.

https://docs.microsoft.com/en-us/windows/desktop/tablet/system-events-and-mouse-messages

https://docs.microsoft.com/en-us/windows/desktop/tablet/listening-to-system-events

Applications can listen to system events by using the InkCollector object and listening for the SystemGesture event on it. You can set which events an application listens to. When a tablet pen action occurs, the corresponding SystemGesture event is sent to the application on its InkCollector object. An application can cancel the mouse message that corresponds to a given SystemGesture event when it receives the event. For details about canceling mouse messages, see SystemGesture event.

https://docs.microsoft.com/en-us/windows/desktop/tablet/flicks-gestures
https://github.com/Microsoft/vscode/issues/36492 Digital Pen input is interpreted as touch instead of mouse after Windows 1709 Fall Creator Update #36492

https://www.reddit.com/r/Windowsink/comments/8emum0/update_fix_now_available_unexpected_application/
https://www.reddit.com/r/Windowsink/comments/8gsjup/additional_control_for_pen_behavior_in_legacy/
https://phabricator.kde.org/D8801?id=23714 WinInk: Simulate native mouse events for handled pen events (Krita)

I will add a video/gif of the behaviour later when I get a chance.

Details

Type
Bug