You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Wintab API sometimes generates bogus information with gpWTInfoA(..., CSR_PHYSID, ...) and gpWTInfoA(..., CSR_TYPE, ...) queries if the tablet has recently been plugged in but has not yet been used. When this happens, the Windows TurboVNC Viewer cannot properly verify the cursor type of the stylus and eraser, so it has no choice but to ignore those cursors, which effectively disables the Wacom/GII interface (the console version of the viewer will report "No extended input devices.")
The workaround seems to be clicking the stylus somewhere on the screen prior to launching the TurboVNC Viewer. There doesn't seem to be any other workaround, as far as I can tell. The TurboVNC Viewer is dynamically loading and calling functions from the closed-source Wintab DLL, so we have no control over the behavior of those functions.
The text was updated successfully, but these errors were encountered:
The description above applies to the Intuos Pro S PTH-451 that I used when developing the Wacom feature for the Windows TurboVNC Viewer. I was sent newer Intuos tablets for testing: an Intuos Pro S PTH-460 and an Intuos Pro M PTH-660. I can confirm that neither of those works properly with Wintab (or, by extension, with the Windows TurboVNC Viewer) at all. They fail in exactly the same way that the PTH-451 fails if I don't first click the stylus on the desktop prior to launching the TurboVNC Viewer. More specifically:
CSR_ACTIVE returns 0 for all tablet cursors.
CSR_PHYSID returns 0 for all tablet cursors.
CSR_TYPE returns 0x0018 for all tablet cursors.
However, the workaround (clicking the stylus on the Windows desktop) does not always work with the newer tablets. Also, even when that workaround does work, the mouse cursor does not move with the pen, and no tablet events are generated when the pen is moved. Thus, the tablet effectively cannot be used either with Windows or with the TurboVNC Viewer.
I'm looking at the Blender source code right now, and it seems as if that application uses Wintab only for older tablets and the Windows Ink API for newer ones, so that might be the appropriate way forward for us (probably in conjunction with #146.)
The Wintab API sometimes generates bogus information with
gpWTInfoA(..., CSR_PHYSID, ...)
andgpWTInfoA(..., CSR_TYPE, ...)
queries if the tablet has recently been plugged in but has not yet been used. When this happens, the Windows TurboVNC Viewer cannot properly verify the cursor type of the stylus and eraser, so it has no choice but to ignore those cursors, which effectively disables the Wacom/GII interface (the console version of the viewer will report "No extended input devices.")The workaround seems to be clicking the stylus somewhere on the screen prior to launching the TurboVNC Viewer. There doesn't seem to be any other workaround, as far as I can tell. The TurboVNC Viewer is dynamically loading and calling functions from the closed-source Wintab DLL, so we have no control over the behavior of those functions.
The text was updated successfully, but these errors were encountered: