[Bug 11846] tablet pressure sensitivity not working in Sai and many other key graphic applications

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=11846

Sabs <sobs at sobs.moe> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sobs at sobs.moe

--- Comment #100 from Sabs <sobs at sobs.moe> ---
Created attachment 64583
  --> https://bugs.winehq.org/attachment.cgi?id=64583
Logs for Sabs's comment

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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.