Question: Not planning on Wintab support?

[thehappycheese]

Hi Fuzzyzilla :)

I saw your notes, but I wanted to ask, is the fact that wintab is proprietary the reason that you aren't planning support? Would you potentially accept a PR?

Windows (wintab, proprietary) Not planned

Only Tablets and Tools - Pads and associated hardware are not exposed by the Ink API. The status of pad hardware on windows is dire, often reported as emulated mouse/keyboard events! ↩

The dire status is quite a frustrating state of affairs :/

I have tried all different ways and for my Windows 11 + Huion tablet, the only hope of stable behaviour seems to be wintab 😞 See my experiments here if you are interested: https://github.com/thehappycheese/windows_pen_tablet_rust I got wintab working... my current code is a quick hack... but it seems basically doable.

I found that rust does not make it easy to use dynamic linking though. Very painful experience. I could not get the extern fns attached using lazy_static.

Anyway thanks for the project so far I am excited for the future potential ❤️

[Fuzzyzilla]

Haiya! Thank you for the interest :D

is the fact that wintab is proprietary the reason that you aren't planning support?

The note that it's proprietary is not the reason I'm not planning support, I should probably make that more clear in the readme! I understand that, prior to the Ink API and even to this day, it is the lingua franca of graphics tablets even though it's a wacom-owned API.

I chose to dedicate my effort towards Ink over Wintab as it seems generally more modern, and being a platform API rather than a driver-defined API makes it a little more portable, even allowing some devices to be used without drivers installed. Every driver I have personally seen (wacom, huion, and XP-PEN) provides Ink support, so I thought I wasn't losing any device coverage by doing so. I had also heard that there were some limitations to using Wintab, such as substantially lower resolutions on some axes, but I cannot find my source for that information.

Would you potentially accept a PR?

By all means, wintab support would be accepted here! Being such a platform abstraction, casting as wide a net as possible is very quite desirable so that it works for everyone :3

I have tried all different ways and for my Windows 11 + Huion tablet, the only hope of stable behaviour seems to be wintab 😞

I am curious, is the Pad support the reason for wintab use, or is it fundamentally broken under the Ink implementation provided here? (And if so, is Ink mode enabled in the Huion driver settings?)

octotablet only provides access via the RealTimeStylus api which is documented as "Legacy User Interaction Features - ... Windows 7 and Earlier".

Oh no.. I did not catch that this was a legacy api... I knew it was originally implemented all the way back in XP Tablet PC, but I thought support was still maintained. It is tested and working under Win 10, but that's probably just because of the absurd commitment to backwards compat under windows lol. That's a bit of a shame, I thought I was implementing the "canonical" way to receive tablet input under Windows :<

I guess the modern "right" platform API is the Windows (Winuser.h Pointer API) that is also marked as "not planned" - I gave it an afternoon of tinkering, but it requires very invasive access to the user's HWND and would probably require gross hacks to get working under existing windowing abstractions. But that also doesn't provide Pad support, so it wouldn't help you if that's what you're looking for D:

[thehappycheese]

Hi @Fuzzyzilla thanks for your detailed response! :)

Yes Windows Ink is enabled in my Huion drivers. Although honestly the checkbox does not appear to do much. I only had the patience to do a few reboots to check the settings were actually taking effect. I could not detect a meaningful difference in behaviour.

I am not sure 'Legacy' is a problem... no sign that it is deprecated :) dont fix what isnt broke.

Nice, I will try to work towards a PR. I have updated my repo with another subcrate called wintab_lite which is just a types lib crate at this stage. Possibly i could publish it or possibly it could be merged into octotablet.

I have a proof of concept with winit... Currently it is only sortof working... I am having trouble with the alignment of the Packet struct. Rust wants to put end-padding on it, and I think this might make it incompatible with some of wintabs bulk-Packet fetching methods like WTDataGet.

[thehappycheese]

I made a crate :) https://crates.io/crates/wintab_lite Just defines types basically, and is a lot of work to use. Would still be good and I may still work on a PR to get octotab to wrap it.

[Fuzzyzilla]

Awesome work! Very quick, exciting to see :D

Working on getting your examples set up to compile on my machine through cross-rs so that I may help test with extra hardware and assist with integration if need be! But no luck so far :<

[thehappycheese]

cross-rs so that I may help test with extra hardware

Ah damn thats tricky if you arent able to test with windows :/ It is also a bit of a hinderance that github actions wont have Wintab32.dll avaliable either. I'm only just realising how hard this will be to test nicely :S

[thehappycheese]

Hi @Fuzzyzilla, so it turns out my setup was suffering from a conflict with some logitech driver as disucssed here on reddit. As much as I still fantasize about the sheer thrill of implementing wintab support into octotab, my motivation has evaporated because now octotab and the whole windows ink interface has started working again. Thanks again for your awesome work on this library :)

[Fuzzyzilla]

I am glad you found a solution! Hadn't heard of that weird driver interaction myself, very good to know though. Perhaps I should put the multitudinous Ink driver bugs and their workarounds somewhere in this repo, because I too have had no shortage of strange behavior caused by driver bugs...