c0rn3j, you probably need to run /tmp/wine/configure and build dependencies before running the test.

I'm testing based on Arch linux's AUR wine-staging-git package. I'm not familiar with building WINE, so my workflow has been coupled with trizen, an AUR wrapper:

1. mkdir -p /tmp/wine; cd /tmp/wine
2. trizen -Gl wine-staging-git  # download the package locally
3. vim wine-staging-git/PKGBUILD  # add "bash" to the end of the "build()" function, after the second "make"; this keeps the files around so I can mess with them
4. trizen -Sl wine-staging-git --noinstall --noconfirm

After a long build, there are 32-bit and 64-bit wine directories that can run tests, and they're present as long as the bash session doesn't terminate (so you can copy the directory, etc.)

Alistair, I built and ran the tests in dlls/wintab32/tests but it doesn't seem to have an interactive variant (the code seems to reflect this, although I'm not very familiar with it -- I can't find reference to winetest_interactive in dlls/wintab32). If I run:

WINEDEBUG=+wintab32 WINETEST_INTERACTIVE=1 make test

Some binary appears to run and quit without awaiting input, a different result from executing the test manually with: 

WINETEST_INTERACTIVE=1 WINEDEBUG=+wintab32 ../../../wine wintab32_test.exe.so

...which still isn't interactive, but does print some output. I've attached logs of both. Wine is version wine-4.9-46-g3139727a97 (Staging).

I'm using xsetwacom's automatic Wacom configuration for my Wacom Bamboo Fun CTE-650. Here's the output of xsetwacom --list:

Wacom BambooFun 6x8 Pad pad             id: 11  type: PAD       
Wacom BambooFun 6x8 Pen stylus          id: 12  type: STYLUS    
Wacom BambooFun 6x8 Pen eraser          id: 26  type: ERASER    
Wacom BambooFun 6x8 Pen cursor          id: 27  type: CURSOR

I also included a log of "xinput list-props" for those devices if it helps.

I suspect that c0rn3j and I have a similar problem: Paint Tool SAI and Krita (windows) both output no tablet activity. wintab32 appears to find my tablet (and its 4 devices) just fine but only reports window changes afterwards -- no input activity at all while the tablet is in use. It acts exactly like a mouse does for both the STYLUS and ERASER pressures, and SAI doesn't seem to notice the difference between the two (usually the eraser is treated as a different tool). My attachment includes a +wintab32 log of SAI where I opened the program, drew a few lines, flicked the mouse in and out of the window to generate the window events, and then closed it.

Native linux Krita does have a working pressure curve. I checked with "xsetwacom set {id} ToolDebugLevel 6", and both the STYLUS and ERASER send pressure events to Arch's /var/log/Xorg.0.log that aren't reflected in wintab32's debug logs. The events are present in the X logs while wine is running. I've included a log of a few stylus and eraser clicks with ToolDebugLevel set to 12 (the max) in case it helps (I can see pressure changing on the z axis).

Is it possible that there's an incompatibility with X's perceived order of my devices and with Wine's? It looks like Wine loads each of the 4 devices into their own stream, so (although I don't really understand how this code works) if the driver expects tablet device index 0 to be the real tablet device and it happens to set the pad as index 0, it may not get any touch events if the pad doesn't send any. This seems unlikely, since both the stylus and eraser are supposed to get passed through (I expect) with their own pressure values, and there was no change when I re-plugged my tablet and the stylus was the first device. xsetwacom's hotplug ordering switches between PAD STYLUS ERASER CURSOR and STYLUS ERASER CURSOR PAD for some reason (also relevant?: I am using hotplugging only; I do not have any static Xorg rules configured for these devices; they appear dynamically thanks to xsetwacom. See https://wiki.archlinux.org/index.php/Wacom for Arch Linux documentation).

I can run more tests if you need anything checked.