New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows Ink support #562

Closed
callaa opened this Issue Feb 14, 2018 · 18 comments

Comments

Projects
None yet
7 participants
@callaa
Member

callaa commented Feb 14, 2018

There is now an experimental version with support for Windows Ink (requires Windows 8 or newer): https://drawpile.net/files/win/drawpile-2.0.8-ink.zip

(The Windows Ink event handler module came from Krita, which added it in the recent 3.3 version.)

Edit: An alternative version: https://drawpile.net/files/win/drawpile-2.0.8-ink2.zip
This version includes both Wintab and Ink support. If the first version works for you, does the second version work also?

Edit 2: Another alternative version, this time with Ink and improved Wintab support: https://drawpile.net/files/win/drawpile-2.0.8-ink3.zip
This version includes the Wintab code from Krita as well, which should work better than the standard Qt tablet handler.

Please give this version a try and report if it works or breaks something that used to work.
Remember to uncheck the "bug workaround mode" if you've had that enabled previously, since it shouldn't be needed anymore. You should also be able to re-check the "scroll with finger" option.

Unless this horribly breaks something, I plan on enabling Windows Ink support for the 64 bit build. The 32 bit build will continue to use the old Wintab API for those who are still running Windows 7 or have tablets that lack Ink drivers.

If the new Wintab handler works, I'll include both Ink and Wintab support in the next version.

@NGMZero

This comment has been minimized.

NGMZero commented Feb 14, 2018

I tested it in a Surface book 2, with windows 10 Fall Creator update.
note: (I uninstalled wintab driver and disabled bugs work around)

Pressure is working with out wintab drivers.
Pen's Eraser is now working as expected and the program switch back and forth between pen and eraser accordingly.
Drawing with pen no longer trigger dragging with touch.

Thank you!

@tincancrab

This comment has been minimized.

tincancrab commented Feb 14, 2018

Looks like I'll either have to update or use 32-bit. I still use 7. Ill see if my eraser error still exists, as it may just be a Qt error we may have to live with.

@ParisGreen

This comment has been minimized.

ParisGreen commented Feb 14, 2018

Running windows ink appears to disable the other tablet methods completely; I'm not sure if this is an issue or meant to happen. Also, The windows ink version appears to force the annoying "holding the cursor in one place is considered a right click" which makes fine control of the pen or making small changes to setting sliders almost impossible. It even appears to override the windows ink settings while drawpile is running. screenshot 2018-02-14 17 32 50

Edit: This might actually be an issue with windows's godawful implementation of press and hold, but if there's anything that can be done to solve this on the application end, it's probably easier than telling everyone with the 64 bit version which registry codes to enter.

@Miumix

This comment has been minimized.

Miumix commented Feb 15, 2018

Sadly, pressure isn't working with this version 8 n 8
I Disabled/Enabled back "bug workarounds" but no success so far

pressurelost

@ParisGreen

This comment has been minimized.

ParisGreen commented Feb 15, 2018

Miumix, do you have "use windows ink" or "tablet pc support" enabled in your tablet settings?

@callaa

This comment has been minimized.

Member

callaa commented Feb 15, 2018

@ParisGreen Disabling wintab is intentional. Krita enables either method, but never both at the same time. However, I don't know if it's actually necessary. I made an alternative version that includes both.

The version version with both methods is here: https://drawpile.net/files/win/drawpile-2.0.8-ink2.zip

If the Ink only version worked on your computer, can you also try the alternative version? If it also works without breaking anything, that would mean I don't need to disable Wintab for the 64 bit version. I would still have to add a toggle to disable Ink mode, since it's possible that for some people Wintab mode would work better.

@ParisGreen

This comment has been minimized.

ParisGreen commented Feb 15, 2018

Just tried it out, it appears to work smoothly either way I set it. That said, without an obvious toggle I can't really tell which pointer it's actually using. I'm attaching some logs, in the hopes that you can read them better than I can. Sorry if they're redundant, I don't exactly grok how the logging for drawpile works.
Windows ink.log
wintab.log
screenshot 2018-02-15 11 21 22
screenshot 2018-02-15 11 18 24

@kai22

This comment has been minimized.

kai22 commented Feb 16, 2018

Working well on my system! On 2.0.3, when I checked "windows ink" in the tablet driver, drawpile would make a hard "dot" anytime the pen touched the tablet (but wasn't dragged) - it must have been interpreting it as a mouse-click.

drawpile-windows-ink

@Miumix

This comment has been minimized.

Miumix commented Feb 17, 2018

@ParisGreen Yes, I did. However, pressure is working by using the alternative version.
Unfortunately, This brings my previous issue back though.
thisissueagain

@callaa

This comment has been minimized.

Member

callaa commented Feb 17, 2018

I managed to get Krita's improved Wintab code workin in Drawpile. Here's a new experimental version: https://drawpile.net/files/win/drawpile-2.0.8-ink3.zip

This one has both Ink and Wintab support. If Ink is not available (or has been explicitly deactivated via the settings dialog,) the Wintab code is loaded. It should work at least a little better than Qt's built-in wintab support.

@Miumix

This comment has been minimized.

Miumix commented Feb 17, 2018

Working pretty well at last! I don't need "bug workarounds" to draw smoothly anymore.
Disabling "windows ink option" here since my pen lost pressure with it. Other than that works awesome so far!

fixedatlast

Thanks for your hard work as always, Calla~

@ParisGreen

This comment has been minimized.

ParisGreen commented Feb 17, 2018

It appears to work pretty well both ways for me, so long as I disable the bug workarounds. I did notice that I get a slight "tail" to my lines where the program considers it a mouse click even though the pressure has gone down to 0%, but that might just be the smoothing. (This is more visible in the tablet tester than in the canvas :P) The windows ink check is still doing that thing where it forces press and hold on right clicks, but with the ability to disable it, it's kind of a lot less of a problem. I'm attaching logs, hope they help, and thanks for putting in the work!

drawpile-2.0.8-2018-02-17.log

screenshot 2018-02-17 16 48 10

screenshot 2018-02-17 16 42 41

@Wade821

This comment has been minimized.

Wade821 commented Feb 17, 2018

Drawpile 2.0.8 version 2 works with both Windows Ink on using pen mode and switching over to Mouse Mode with pen pressure. The only oddity here is that although I'm set to using mouse mode, when Drawpile has focus my cursor acts like Pen mode still. The moment I click out of Drawpile, it resumes Mouse mode. But both work more or less just fine.

Drawpile 2.0.8 version 3 also works with both Windows Ink as expected in Pen Mode. While Windows Ink is enabled in Drawpile, Mouse mode does not give any pen pressure (nor does Pen mode IF the Windows Ink checkbox is unchecked as expected). While Windows Ink is disabled in Drawpile, Pen Mode still works with Drawpile pressure it seems (at least for me, regardless of having Windows Ink on or off in my tablet settings). Mouse mode pressure also works once Windows Ink is turned off in Drawpile. The big issue here is that there is a desync of cursor icons as displayed below. I'm not sure what I need to do to show this to you since I don't think a session recording would help in this particular case. It may be worth mentioning that the desync issue doesn't happen right away, but usually within a few brush strokes.

drawpile-2.0.8-2018-02-17.log

image

image

Stylus press X=50.31 Y=40.11 B=1 P=32.5%
Mouse press X=42 Y=94 B=1
Stylus move X=50.31 Y=41.69 B=1 P=32.6% (DRAW)
Mouse move X=42 Y=96 B=1
Stylus move X=50.31 Y=43.85 B=1 P=33.0% (DRAW)
Mouse move X=42 Y=98 B=1
Stylus move X=50.31 Y=46.75 B=1 P=36.0% (DRAW)
Mouse move X=42 Y=102 B=1
Stylus move X=50.56 Y=50.50 B=1 P=38.5% (DRAW)
Mouse move X=42 Y=104 B=1
Stylus move X=53.01 Y=55.22 B=1 P=40.1% (DRAW)
Mouse move X=42 Y=108 B=1
Stylus move X=57.01 Y=61.06 B=1 P=41.0% (DRAW)
Mouse move X=44 Y=114 B=1
Stylus move X=62.80 Y=68.13 B=1 P=41.5% (DRAW)
Mouse move X=46 Y=120 B=1
Stylus move X=70.54 Y=76.52 B=1 P=41.6% (DRAW)
Mouse move X=48 Y=128 B=1
Stylus move X=80.46 Y=86.07 B=1 P=41.9% (DRAW)
Mouse move X=50 Y=136 B=1
Stylus move X=92.57 Y=96.89 B=1 P=41.9% (DRAW)
Mouse move X=54 Y=144 B=1
Stylus move X=106.74 Y=108.87 B=1 P=41.9% (DRAW)
Mouse move X=58 Y=154 B=1
Stylus move X=122.20 Y=121.82 B=1 P=41.5% (DRAW)
Mouse move X=60 Y=164 B=1
Stylus move X=138.31 Y=135.50 B=1 P=40.1% (DRAW)
Mouse move X=64 Y=174 B=1
Stylus move X=154.93 Y=149.34 B=1 P=37.3% (DRAW)
Mouse move X=68 Y=184 B=1
Stylus move X=170.65 Y=163.45 B=1 P=34.9% (DRAW)
Mouse move X=70 Y=194 B=1
Stylus move X=185.21 Y=177.25 B=1 P=31.7% (DRAW)
Mouse move X=74 Y=204 B=1
Stylus move X=198.09 Y=190.51 B=1 P=31.9% (DRAW)
Mouse move X=76 Y=212 B=1
Stylus move X=209.56 Y=203.11 B=1 P=31.7% (DRAW)
Mouse move X=78 Y=222 B=1
Stylus move X=219.61 Y=214.71 B=1 P=31.9% (DRAW)
Mouse move X=80 Y=230 B=1
Stylus move X=228.50 Y=225.45 B=1 P=32.3% (DRAW)
Mouse move X=82 Y=236 B=1
Stylus move X=236.49 Y=234.88 B=1 P=32.9% (DRAW)
Mouse move X=84 Y=242 B=1
Stylus move X=243.71 Y=243.04 B=1 P=33.3% (DRAW)
Mouse move X=86 Y=248 B=1
Stylus move X=250.28 Y=249.92 B=1 P=33.1% (DRAW)
Mouse move X=86 Y=252 B=1
Stylus move X=255.95 Y=255.37 B=1 P=32.3% (DRAW)
Mouse move X=88 Y=254 B=1
Stylus move X=260.46 Y=259.51 B=1 P=30.3% (DRAW)
Mouse move X=88 Y=256 B=1
Stylus move X=263.55 Y=262.44 B=1 P=28.2% (DRAW)
Mouse move X=88 Y=258 B=1
Stylus move X=265.35 Y=264.26 B=1 P=23.7% (DRAW)
Stylus move X=265.61 Y=265.07 B=1 P=16.4% (DRAW)
Stylus move X=265.61 Y=265.07 B=1 P=3.6% (DRAW)
Stylus release X=264.71 Y=265.07 B=0 P=0.0%
Mouse release
@Wade821

This comment has been minimized.

Wade821 commented Feb 18, 2018

Enabling Bug Workarounds in preferences does seem to largely solve the issue, however there are still issues with it desyncing. Just not as bad as it was before. Most of the time on the tester I just get a red line, occasionally though I get both lines again. It does appear though that in Drawpile itself that it isn't desynced so I'm not sure what to make of it.

image

Stylus press X=229.53 Y=232.06 B=1 P=38.5%
Mouse press X=275 Y=350 B=1
Stylus move X=228.50 Y=230.01 B=1 P=38.6% (DRAW)
Stylus move X=228.50 Y=230.01 B=1 P=38.9% (DRAW)
Mouse move X=275 Y=348 B=1
Stylus move X=226.44 Y=225.80 B=1 P=41.1% (DRAW)
Mouse move X=275 Y=346 B=1
Stylus move X=225.80 Y=223.37 B=1 P=44.3% (DRAW)
Mouse move X=275 Y=344 B=1
Stylus move X=225.54 Y=220.50 B=1 P=46.5% (DRAW)
Mouse move X=275 Y=342 B=1
Stylus move X=225.54 Y=217.03 B=1 P=48.1% (DRAW)
Mouse move X=275 Y=338 B=1
Stylus move X=225.54 Y=212.58 B=1 P=50.1% (DRAW)
Mouse move X=275 Y=334 B=1
Stylus move X=225.80 Y=206.78 B=1 P=52.1% (DRAW)
Mouse move X=275 Y=328 B=1
Stylus move X=228.50 Y=199.32 B=1 P=53.5% (DRAW)
Mouse move X=275 Y=322 B=1
Stylus move X=232.37 Y=189.74 B=1 P=54.4% (DRAW)
Mouse move X=277 Y=312 B=1
Stylus move X=237.39 Y=177.95 B=1 P=54.9% (DRAW)
Mouse move X=277 Y=302 B=1
Stylus move X=243.45 Y=164.03 B=1 P=54.9% (DRAW)
Mouse move X=279 Y=290 B=1
Stylus move X=250.28 Y=148.30 B=1 P=54.9% (DRAW)
Mouse move X=281 Y=278 B=1
Stylus move X=257.88 Y=130.98 B=1 P=54.5% (DRAW)
Mouse move X=283 Y=264 B=1
Stylus move X=266.00 Y=112.54 B=1 P=53.5% (DRAW)
Mouse move X=285 Y=250 B=1
Stylus move X=274.50 Y=93.53 B=1 P=53.1% (DRAW)
Mouse move X=287 Y=236 B=1
Stylus move X=283.01 Y=74.31 B=1 P=52.1% (DRAW)
Mouse move X=289 Y=222 B=1
Stylus move X=291.64 Y=55.18 B=1 P=47.8% (DRAW)
Mouse move X=291 Y=208 B=1
Stylus move X=300.40 Y=36.39 B=1 P=44.0% (DRAW)
Mouse move X=293 Y=196 B=1
Stylus move X=309.03 Y=18.42 B=1 P=39.8% (DRAW)
Mouse move X=295 Y=182 B=1
Stylus move X=317.54 Y=1.22 B=1 P=34.5% (DRAW)
Mouse move X=297 Y=172 B=1
Stylus move X=325.78 Y=-14.71 B=1 P=27.9% (DRAW)
Mouse move X=297 Y=160 B=1
Stylus move X=333.77 Y=-29.16 B=1 P=15.4% (DRAW)
Mouse move X=299 Y=152 B=1
Stylus release X=340.86 Y=-41.96 B=0 P=0.0%
Mouse release
@callaa

This comment has been minimized.

Member

callaa commented Feb 18, 2018

One more test release:https://drawpile.net/files/win/drawpile-2.0.8-ink4.zip

This one makes a small change to the bug workaround mode: the stylus down flag is now cleared on both stylus and mouse up events. For some reason, it's possible that a stylus release event is not sent when the stylus is lifted. In bug workaround mode, this causes the last pressure value (0%) to effectively get stuck, as the program still thinks the stylus is gently touching the surface. When you try to draw with a device that doesn't send pressure events (mouse or touch,) all the strokes get zero pressure. This change tries to work around that.

@ParisGreen

This comment has been minimized.

ParisGreen commented Feb 19, 2018

Getting good behavior out of both, at least on my end, but I really appreciate the ability to choose. Thanks again for making that a toggle, rather than separate exes.

drawpile-2.0.8-2018-02-19.log
screenshot 2018-02-19 00 19 18
screenshot 2018-02-19 00 21 35

callaa added a commit that referenced this issue Feb 19, 2018

@Wade821

This comment has been minimized.

Wade821 commented Feb 23, 2018

Windows Ink has a peculiar issue that is unrelated to Drawpile at all. This can be easily confirmed by doing this on the Windows Desktop (or anywhere else for that matter) provided Windows Ink is enabled in your tablet settings. Simply hold either control, shift, alt, or some combination of all three to get a pop up appearing underneath. If anyone knows of a fix for this, it'd be greatly appreciated to be communicated here so we can share it with other users.

image

I don't use Windows Ink myself, but for the sake of others it might bother, I've tried doing a number of things to remove this annoying feature without disabling Windows Ink as is suggested by many users. For reference, I'm running Windows 10 Pro, Creator's Update, version 1709 (OS Build 16299.248).

Attempted Fixes (None of which work):

  • Tablet PC Input Service doesn't exist on my computer. (Source)
  • The Windows Pro or higher option to use gpedit: "User Configuration > Administrative Templates > Windows Components > Tablet PC > Cursor, then click "Turn off pen feedback" and ENABLE it." (Source)
  • Registry Edit to add in DWORD values UIButtonMode and UIModKeyMode (Source)
  • Disable Windows Flicks (Control panel, pen and touch, flicks tab) (Source)
  • Checked to see if I could uninstall the Windows specific tablet features (no such option exists) (Source)
  • Tried increasing the delay that Windows displays said tooltips (source )
  • Using Windows Settings panel, devices, Pen & Windows Ink menu. (turned off Show visual effects & show cursor)
@callaa

This comment has been minimized.

Member

callaa commented Feb 25, 2018

The new release which includes these changes is now out. Thank you everyone for helping me test them!

@callaa callaa closed this Feb 25, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment