date:20190527

[Bug 151448] Re: Wacom pressure sensitivity lacking under Wine applications.

2019-05-27 Thread Sabs

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).

1 2 3 4 >

1 - 100 of 303 matches

Mail list logo