Wacom pressure sensitivity lacking under Wine applications.

Bug #151448 reported by gusdefrog
48
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Wine
Unknown
High
wine1.4 (Ubuntu)
Triaged
Low
Unassigned

Bug Description

Having done a great deal of searching and finding alot of "sometimes it works, sometimes it doesn't" information, I found out how to enable wacom tablet pressure sensitivity under Wine on my laptop. The wacom drivers were already preinstalled with Ubuntu Feisty so it already worked in native linux applications such as Gimp.

What almost worked was commenting out the Synaptics reference, as several places instructed, but then I lost some touch pad functionality. What worked instead and is so far allowing me full functionality in both was to edit the xorg.conf file and moving the synaptics touchpad above the wacom pen inputs.

Unless there is some obvious reason not to, it would be nice if they were installed in this order as a default.

I ran:
sudo cp /etc/X11/xorg.conf /etc/X11/xorg.oldconf
sudo gedit /etc/X11/xorg.conf

and modified the: Section "ServerLayout" from

Section "ServerLayout"
    Identifier "Default Layout"
    Screen "Default Screen" 0 0
    InputDevice "Generic Keyboard"
    InputDevice "Configured Mouse"
    InputDevice "stylus" "SendCoreEvents"
    InputDevice "cursor" "SendCoreEvents"
    InputDevice "eraser" "SendCoreEvents"
    InputDevice "Synaptics Touchpad"
EndSection

to

Section "ServerLayout"
    Identifier "Default Layout"
    Screen "Default Screen" 0 0
    InputDevice "Generic Keyboard"
    InputDevice "Configured Mouse"
    InputDevice "Synaptics Touchpad"
    InputDevice "stylus" "SendCoreEvents"
    InputDevice "cursor" "SendCoreEvents"
    InputDevice "eraser" "SendCoreEvents"
EndSection

Tags: wacom wine
Revision history for this message
Till Hartmann (tillux) wrote :

I am very upset with wine, as the announce for wine 0.9.52 reads: "Improved graphics tablet support.".
I updated wine, tried out different applications, but none of them is even recognizing the tablet, it acts like a normal mouse.
Maybe the "Improved support" did not mean the pressure to work, but that is what I have been hoping for, since the tablet already worked before version 0.9.52.

Revision history for this message
Vadim (zedzzz) wrote :

in WINE 0.9.54 Wacom Bamboo is still recognizes as a mouse.

Revision history for this message
In , Todor Eemreorov (blurymind-gmail) wrote :

tablet pressure sensitivity still not working on crucial graphic software that is made to be used with tablets.

I am not sure if thats due wintab32,because im not a developer.

Applications like SAI that are wonderfully small ,full featured and even better than photoshop for CG coloring (better brushes,other key features) work almost perfectly fine on wine, but their practically useless when tablet pressure doesnt work..
http://appdb.winehq.org/objectManager.php?sClass=version&iId=11044

another application that is a freeware and a fine substitute for painter is
http://appdb.winehq.org/objectManager.php?sClass=version&iId=7425&iTestingId=21659

tablet pressure works on photoshop and artrage,but not on many other key applications in the graphic world that crucially depend on it. This feature is very important,since there are absolutely no alternatives to these applications on linux (if you study their key features you'll see there arent any on windows too at the moment,especially Sai). The applications work almost perfectly on wine,but that lack of this feature stops people from taking advantage of that.

Another application is Open Canvas...

But especially Sai- If there is any hack or workaround to get pressure sensitivity working on sai, even a patch..i would gladly test it and report any progress on Sai on wine.

Revision history for this message
In , Dan Kegel (dank) wrote :

What tablet do you have?

Can you give us a +wintab32 log?

Revision history for this message
In , Todor Eemreorov (blurymind-gmail) wrote :
Download full text (7.3 KiB)

(In reply to comment #1)
> What tablet do you have?
>
> Can you give us a +wintab32 log?
>

wacom graphire 4- wine 0.9.57,on ubuntu

sai-1.0.1 --- TABLET EMULATION DOES NOT WORK

err:ole:CoGetClassObject no class object {4590f811-1d3a-11d0-891f-00aa004b2e24} could be created for context 0x1
fixme:mountmgr:harddisk_ioctl unsupported ioctl 7c088
fixme:mountmgr:harddisk_ioctl unsupported ioctl 90064
fixme:mountmgr:harddisk_ioctl unsupported ioctl 90064
fixme:wintab32:WTOverlap (0xc00, 1): stub
fixme:wintab32:WTSetA (0xc00, 0x7d1363ec): stub
fixme:wintab32:X11DRV_WTInfoW Unhandled Category 2
fixme:wintab32:WTOverlap (0xc00, 0): stub
fixme:wintab32:WTOverlap (0xc00, 1): stub
fixme:wintab32:WTSetA (0xc00, 0x7d1363ec): stub
fixme:wintab32:X11DRV_WTInfoW Unhandled Category 2
fixme:wintab32:WTOverlap (0xc00, 0): stub
fixme:wintab32:WTOverlap (0xc00, 1): stub
fixme:wintab32:WTSetA (0xc00, 0x7d1363ec): stub
fixme:wintab32:X11DRV_WTInfoW Unhandled Category 2
fixme:wintab32:WTOverlap (0xc00, 0): stub
fixme:wintab32:WTOverlap (0xc00, 1): stub
fixme:wintab32:WTSetA (0xc00, 0x7d1363ec): stub
fixme:wintab32:X11DRV_WTInfoW Unhandled Category 2
fixme:imm:ImmReleaseContext (0x1012c, 0x12e9e8): stub
fixme:imm:ImmAssociateContextEx (0x10134, (nil), 16): stub
fixme:wintab32:WTOverlap (0xc00, 0): stub
fixme:wintab32:WTOverlap (0xc00, 1): stub
fixme:wintab32:WTSetA (0xc00, 0x7d1363ec): stub
fixme:wintab32:X11DRV_WTInfoW Unhandled Category 2
fixme:wintab32:WTOverlap (0xc00, 0): stub
fixme:wintab32:WTOverlap (0xc00, 1): stub
fixme:wintab32:WTSetA (0xc00, 0x7d1363ec): stub
fixme:wintab32:X11DRV_WTInfoW Unhandled Category 2
fixme:wintab32:WTOverlap (0xc00, 0): stub
fixme:wintab32:WTOverlap (0xc00, 1): stub
fixme:wintab32:WTSetA (0xc00, 0x7d1363ec): stub
fixme:wintab32:X11DRV_WTInfoW Unhandled Category 2
fixme:imm:ImmAssociateContextEx (0x10198, (nil), 16): stub
fixme:wintab32:WTOverlap (0xc00, 0): stub
fixme:wintab32:WTOverlap (0xc00, 1): stub
fixme:wintab32:WTSetA (0xc00, 0x7d1363ec): stub
fixme:wintab32:X11DRV_WTInfoW Unhandled Category 2
fixme:wintab32:WTOverlap (0xc00, 0): stub
fixme:wintab32:WTOverlap (0xc00, 0): stub
fixme:shell:SHAppBarMessage msg=1, data={cb=36, hwnd=0x10026, callback=0, edge=0, rc=(0,0)-(0,0), lparam=0}: stub
fixme:shell:SHAppBarMessage ABM_REMOVE broken
fixme:htmlhelp:HtmlHelpW HH case HH_UNINITIALIZE not handled.
err:ole:CoUninitialize Mismatched CoUninitialize
theo@theo-desktop:~/sai-eng-1.0.1$

=======================
open canvas 4.5 - tested on same wine- tablet emulation WORKS on the last wine!!!!!!!!!, but there are other glitches,such as no layers preview or layer options showing up.Its wintab log:

fixme:wintab32:X11DRV_WTInfoW Return proper size
fixme:wintab32:WTSetA (0xc00, 0xad5b7d): stub
fixme:wintab32:WTSetA (0xc00, 0xad5b7d): stub
fixme:wintab32:WTSetA (0xc00, 0xad5b7d): stub
fixme:wintab32:WTSetA (0xc00, 0xad5b7d): stub
fixme:wintab32:WTSetA (0xc00, 0xad5b7d): stub
fixme:wintab32:WTSetA (0xc00, 0xad5b7d): stub
fixme:wintab32:WTSetA (0xc00, 0xad5b7d): stub
fixme:wintab32:WTSetA (0xc00, 0xad5b7d): stub
fixme:wintab32:WTSetA (0xc00, 0xad5b7d): stub
fixme:wintab32:WTSetA (0xc00, 0xad5b7d): stub
fixme:wintab32:WTSetA (0xc00, 0xad...

Read more...

Revision history for this message
In , Todor Eemreorov (blurymind-gmail) wrote :

same version of wine and tablet model, tested on freeware application artweaver 0.4.9:

wine: Call from 0x7ee4e4f0 to unimplemented function ntoskrnl.exe.IoAllocateIrp, aborting
wine: Call from 0x7ee4e4f0 to unimplemented function ntoskrnl.exe.IoAssignResources, aborting
fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for 8000000a
fixme:wintab32:X11DRV_WTInfoW Return proper size
fixme:wintab32:X11DRV_WTInfoW Unhandled Category 2

only wintab messages,right?

Revision history for this message
In , Dan Kegel (dank) wrote :

That's not quite what we wanted. Can you rerun with
  WINEDEBUG=+wintab32 wine sai.exe > log.txt 2>&1
and attach log.txt (do not put inline! Click 'Add an attachment' above.)
Thanks.

Revision history for this message
In , Dan Kegel (dank) wrote :

It looks like SAI has a trial mode and can be downloaded from
http://www.systemax.jp/sai/bin/sai-1.0.0.zip

Revision history for this message
In , Todor Eemreorov (blurymind-gmail) wrote :

Created an attachment (id=11411)
sai 1.0.1 wintab32 log file

 WINEDEBUG=+wintab32 wine sai.exe > log.txt 2>&1

wacom graphire 4 xl, sai 1.0.1, wine 0.9.57
feisty fawn

Revision history for this message
In , Todor Eemreorov (blurymind-gmail) wrote :

(In reply to comment #5)
> It looks like SAI has a trial mode and can be downloaded from
> http://www.systemax.jp/sai/bin/sai-1.0.0.zip
>

yes of course,i know about the trial, i am even thinking of buying Sai if tablet emulation works with wine some day

Revision history for this message
In , Dan Kegel (dank) wrote :

Thanks for the log! It looks like wintab32 is happy with
your device. I'm not sure why the pressure isn't coming through.

What model tablet are you using? Can you attach your /etc/X11/xorg.conf?

So to sum up, pressure works for you with Photoshop 7 and Artrage,
but not with Sai or OpenCanvas?

(I posted about the Sai trial not for your benefit, but for
anyone else looking at this bug.)

Revision history for this message
In , Dan Kegel (dank) wrote :

Sorry, I see you already said you have a wacom graphire 4 xl.
I'd still like to see your /etc/xorg.conf and
get confirmation that pressure works for you with Photoshop 7 and Artrage,
but not with Sai or OpenCanvas. (And it'd be nice to know
what versions of those apps you tried.)

Revision history for this message
In , Todor Eemreorov (blurymind-gmail) wrote :

Created an attachment (id=11427)
xorg.conf file- tablet settings- photoshop cs2 and artrage 2.5 work,but sai and artweaver dont work

my xorg.conf file under ubuntu. I can confirm that tablet pressure works in photoshop cs2 and in artrage 2.5 (latest) always- wine 0.9.57

Revision history for this message
In , Todor Eemreorov (blurymind-gmail) wrote :

(In reply to comment #9)
> Sorry, I see you already said you have a wacom graphire 4 xl.
> I'd still like to see your /etc/xorg.conf and
> get confirmation that pressure works for you with Photoshop 7 and Artrage,
> but not with Sai or OpenCanvas. (And it'd be nice to know
> what versions of those apps you tried.)
>

they work.I attached my xorg.conf. I am also sure that tablet pressure doesnt work in many other graphic applications and i am willing to help for testing and the such to help getting their compability.
But as of now,Sai is definetely the tastiest application for graphic artists with tablets out there. Also,i tested both its engish translated version and its japanese version.The engish translation of sai can be found here:
http://sai.detstwo.com/sai/

it does not have any hacks on its binaries (exe wasnt edited by a hex editor) ,only text files were edited.

Revision history for this message
In , Todor Eemreorov (blurymind-gmail) wrote :

(In reply to comment #9)
> Sorry, I see you already said you have a wacom graphire 4 xl.
> I'd still like to see your /etc/xorg.conf and
> get confirmation that pressure works for you with Photoshop 7 and Artrage,
> but not with Sai or OpenCanvas. (And it'd be nice to know
> what versions of those apps you tried.)
>
tablet pressure works in open canvas with the 0.9.57 version of wine! But opening oci and psd files in open canvas doesnt work,and also its layers box is blank...that makes OC unusable for serious work,but the bug is not related.Sorry for mentioning OC.

Revision history for this message
In , Dan Kegel (dank) wrote :

Thanks for the info. We'll try SAI here.

Revision history for this message
In , Lei Zhang (thestig-google) wrote :

please leave the version field alone.

Revision history for this message
In , Todor Eemreorov (blurymind-gmail) wrote :

(In reply to comment #13)
> Thanks for the info. We'll try SAI here.
>

thanks for the attention on the problem. I will continue to test Sai with every new version of wine and keep you updated. Is there an other way to help you out with bug tracking? Another log file? Anything. I'm very eager to have sai work on linux.

Revision history for this message
In , DOPing (harddoping) wrote :

I can confirm that pressure sensitivity does not work in SAI under wine 0.9.57 (which I built from source). I have Wacom Bamboo Fun A5.

Revision history for this message
In , Dan Kegel (dank) wrote :

Marking confirmed since 2nd user sees problem.

Does
http://www.winehq.org/pipermail/wine-patches/2008-March/051905.html
help, by any chance?

Revision history for this message
In , DOPing (harddoping) wrote :

(In reply to comment #17)
> Does
> http://www.winehq.org/pipermail/wine-patches/2008-March/051905.html
> help, by any chance?

I have to apologize it took me so long to reply. Anyway, here I am with new clean installation of ubuntu 7.04. I've installed updated version of linuxwacom driver -- 0.7.9.9.

Is this patch (winex11.drv: Indirection level fix) included in wine 0.9.58? If it is, then -- no luck, pressure sensitivity still does not work in Paint Tool SAI.

Revision history for this message
In , Xixsimplicityxix (xixsimplicityxix) wrote :

Created an attachment (id=12026)
Implementes WTSetA WTSetW for wintab32

I've yet to test this out on my ubuntu tablet machine but it builds ok.

If anyone is up for testing go for it. Should provide a minimum functioning of WTSetA and WTSetW.

Revision history for this message
In , Xixsimplicityxix (xixsimplicityxix) wrote :

I'm trying to reproduce the open canvas problems.

Can you illustrate a use case and the expected output and compare to actual output?
With the the patch I posted here on top of current git I can see the layers box and switch between them (hopefully this means blank layer box has been fixed). I'm not sure what you mean by layer options.

Revision history for this message
In , Xixsimplicityxix (xixsimplicityxix) wrote :

Well I've tested openCanvas as best I can on windows and on wine. The layering issues seem to have been fixed. It appears to run really well except for a windowing problem.

There isn't a window listed in the taskbar for opencanvas on ubuntu 7.10. This causes trouble I believe for instance when you are have the layer properities window open and then click off of it, it will disappear on ubuntu. On windows it is a modal dialog and can't become out of focus. Once out of focus on ubuntu you can no longer get it to reapper in the foreground. However it still has the input trapped to it so you can't input into the program either. You can work around this by restarting openCanvas.

I'm going to send in my WTSetA/W patches as they appear to have fixed the layering issues for me.

Revision history for this message
Scott Ritchie (scottritchie) wrote :

Please retest on the latest Wine in Ubuntu Hardy. Thanks.

Changed in wine:
status: New → Incomplete
Revision history for this message
In , Xixsimplicityxix (xixsimplicityxix) wrote :
Revision history for this message
In , Xixsimplicityxix (xixsimplicityxix) wrote :

I've looked into this sai business a bit further. SAI is different in how it captures the tablet messages. I believe that openCanvas and Photoshop grab packets by repeatedly using WTPacketsGet, the "active" way to get tablet info.

Based on my wintab32 logs SAI uses the "passive" way to get tablet info in that it expects to find tablet messages (WT_PACKET) coming through Windows Messaging channels. I think this is where our wintab breaks down as when I run +msg logs I don't see any WT_PACKETS coming through.

Of course this is just my theory and I can't confirm it for sure yet but in case I don't get back to this in a couple weeks it could maybe help someone out.

See the wintab spec[1] page 5, section 13 "Polling" for the two different ways of monitoring tablet info.

[1] http://www.wacomeng.com/devsupport/downloads/pc/wt1pt1.zip

Revision history for this message
In , Xixsimplicityxix (xixsimplicityxix) wrote :

Ahh my eyes bleed from all the logs. But ok I think I'm closer now. Sai uses child windows for the drawing contexts. We call into X11DRV_get_whole_window with the hwnd of the context. The call to x11drv fails because there are no valid x11 windows for our child windows afaict. I don't have time now but I think if we find the correct parent hwnd that links with a valid x11 window we should be able to connect the event queue to wintab.

AttachEventQueueToTablet is returning with 0 due to the failed x11drv call now which is why there are no events in any of the logs.

Maybe more tonight. hrmm

Revision history for this message
In , Todor Eemreorov (blurymind-gmail) wrote :

I'm following your progress John and believe you're on the right track to the problem,which is the reason not only sai,but a couple of other applications i know can't pick up tablet pressure sensitivity.

Anyways,seeing that this bug is worked on by smart people who understand all those logs that wine spills,i just wanna say that you guys are my heroes. Wine had made great leaps on some applications and is still making to fill the void of graphic software on the linux platform. =)

can i edit or erase some of my previous posts here,to omit the long log that i pasted hastily?

Revision history for this message
In , Xixsimplicityxix (xixsimplicityxix) wrote :

Thanks for the encouragement =) I don't know about the comment editing.

Well where I'm at now. SAI doesn't seem to have true parent x11 window. Right now in mainline wine we pass the hwnd of the tablet context to AttachEventQueueToTablet => x11drv_get_whole_window. This is not right as the hwnd of the context could be a child window and those don't have valid x11 windows associated with them so x11drv_get_whole_window will return 0 which prevents us from getting xInputEvents. I'm pretty sure that we should actually do something like this: AttachEventQueueToTablet( GetAncestor(hWnd, GA_ROOT) ) which would return a parent window for sure giving us an x11 window and then giving us those events.

Ofc this doesn't work or I'd just have posted a patch and not all this blather tonight. It seems that there is no valid parent window for the hwnd sai creates for the tablet context. So I'm not sure what that means....

My guess is that it just creates a child window to the root window. If that is the case then our code needs to be something like this:

if (!AttachEventQueueToTablet( GetAncestor(hWnd, GA_ROOT) )) AttachEventQueueToTablet( GetDesktopWindow() );

Which I've tried and that does get xinput events flowing (yay!) BUT pressure still doesn't work in sai. I'm not sure at this point if there is some problem elsewhere or if the problem is because the above isnt the right fix. Dunno when I'll check this out next going to be busy next week and me soo tired right now =P

Revision history for this message
azathothgr (azathothgr) wrote :

I can confirm on latest hardy (rc) with wine 0.9.59 from the repos, and an intuos 6x8
Pressure works under gimp, but not under wine in Artrage starter or full.
Stylus is properly recognized and works in absolute mode, but no pressure or tilt.

Revision history for this message
azathothgr (azathothgr) wrote :

I've got it to work :
First, in dlls/winex11.drv/wintab.c (from wine source), around line #623 , there's a check for 5 or more axes which according to a bug report was left there without any particular reason :
Code:

 if (!axis_read_complete && Val->num_axes >= 5 && cursor->TYPE == CSR_TYPE_PEN)

I changed this to :
Code:

if (!axis_read_complete && cursor->TYPE == CSR_TYPE_PEN)

It seems it checks for each axis anyway after that, so it's redundant.

Most importantly, however, I changed every instance of IsXExtensionDevice in that file with IsXExtensionPointer, which is what xsetpointer -l reports those devices as.

Revision history for this message
In , Xixsimplicityxix (xixsimplicityxix) wrote :

Created an attachment (id=12574)
Search harder for an x11 window when given an hwnd

Coming a bit closer now. I tried my best to get this in before 1.0 but I don't think we're gonna make it. Good news is that the problem is related to child window messaging. Before we simply dropped the packets if the root window wasnt used as the wintab context window. I have a patch that grabs either the x11 parent window OR the root window ensuring that we always ahve a source for those precious x11 tablet events.

The next step is to get the messages we generate from those events back to the child windows themselves. My 2nd patch does that, though I'm not sure if it is the proper way. It does work though.

It still doesn't make pressure work in sai though amazingly enough. The logs now show the tablet pressure events streaming to the child window and the corresponding context but still not a drop of pressure from sai. Puzzling... but closer.

Not going to be around for a bit now with it being learning crunch time around here so

Revision history for this message
In , Xixsimplicityxix (xixsimplicityxix) wrote :

Created an attachment (id=12575)
Support wintab messaging for child windows

Revision history for this message
In , Todor Eemreorov (blurymind-gmail) wrote :

thanks john... today i read on several forums reports of people running sai on linux,they all say that it works very well,but they get no pressure sensitivity...

======windows' sai's tablet driver======
people with graphire tablets and cintique have no problem,but i found that even on windows,curent Sai version has some issues with pressure sensitivity on bamboo tablets and some of Trust's tablets...
http://sai.detstwo.com/smf/index.php/topic,62.0.html

quote:
by default SAI uses it own internal tablet driver, and with some tablets this driver works incorrectly.
try to play with misc.ini - for example change TabletMouseSimulation to zero

another (solved) problem like yours -> http://sai.detstwo.com/smf/index.php/topic,39.0.html
================
Another thing to look to is that Sai originated from another drawing application,called Neko paint...im not sure if it uses the same internal tablet driver,but it has some of sai's basic tools (brushes,masking tools):
http://www2.tbb.t-com.ne.jp/neko_paint/

sadly,its in japanese and pretty unusable...i'll try to run it with wine and see...but its pretty much abandonware, Its developer is now working on Sai...

===================

I hope that atleast with investigation,i can help your progress..

Revision history for this message
gusdefrog (gusdefrog) wrote :
Download full text (12.5 KiB)

Since upgrading to Hardy Heron I can't get my wacom graphire tablet to have pressure sensitivity, eraser, or side buttons to work under Wine no matter what I try. I've tried the same xorg.conf I've tried the default Wine distribution and the updated 1.x distribution. I've downloaded and installed from source the 1.x distribution. Currently I'm running version 1.0-rc1

This always comes up in the terminal window if I start any of my windows graphics programs from the command line when I'm using the tablet to navigate.
fixme:wintab32:WTOverlap (0xc00, 1): stub

Here is my bug output for wintab:
frog@Frogpad:~/.wine/drive_c/Program Files/Pixia$ WINEDEBUG=+wintab32 wine pixia
wine: Unhandled page fault on write access to 0x00463000 at address 0x7bc44a1f (thread 001a), starting debugger...
Unhandled exception: page fault on write access to 0x00463000 in 32-bit code (0x7bc44a1f).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:7bc44a1f ESP:7ec1e910 EBP:7ec1e938 EFLAGS:00010202( - 00 - -RI1)
 EAX:00000ffe EBX:7bc88444 ECX:004701dc EDX:00462000
 ESI:00000132 EDI:00050000
Stack dump:
0x7ec1e910: 7ec1e9cc 0046ff70 7ec1e938 7b89be9a
0x7ec1e920: ffffffff 00462000 00000005 7eea48f4
0x7ec1e930: 0046ff70 00462000 7ec1e9e8 7eea2f0e
0x7ec1e940: 00462000 00000132 0046ff78 00050000
0x7ec1e950: 00110ef0 7ec1e9d4 00000000 00000130
0x7ec1e960: 00000026 7ec1e9cc 7ec1e9c4 f7dcfec9
Backtrace:
=>1 0x7bc44a1f LdrProcessRelocationBlock+0xbf(page=0x462000, count=0x132, relocs=0x4701dc, delta=0x50000) [/home/frog/Downloads/wine-1.0-rc1/dlls/ntdll/loader.c:2061] in ntdll (0x7ec1e938)
  2 0x7eea2f0e ServiceMain+0x55e(argc=0x0, argv=0x0) [/home/frog/Downloads/wine-1.0-rc1/programs/winedevice/device.c:96] in winedevice (0x7ec1e9e8)
  3 0x7ee4c529 service_thread+0x169(arg=0x1108d0) [/home/frog/Downloads/wine-1.0-rc1/dlls/advapi32/service.c:430] in advapi32 (0x7ec1ea38)
  4 0x7bc6bbbe call_thread_entry_point+0xe() in ntdll (0x7ec1ea48)
  5 0x7bc6c252 call_thread_func+0x42(rtl_func=<register EDI not in topmost frame>, arg=<register ESI not in topmost frame>) [/home/frog/Downloads/wine-1.0-rc1/dlls/ntdll/thread.c:386] in ntdll (0x7ec1eae8)
  6 0x7bc6c482 in ntdll (+0x5c482) (0x7ec1f3d8)
  7 0xf7dca4fb start_thread+0xcb() in libpthread.so.0 (0x7ec1f4c8)
0x7bc44a1f LdrProcessRelocationBlock+0xbf [/home/frog/Downloads/wine-1.0-rc1/dlls/ntdll/loader.c:2061] in ntdll: addl %edi,0x0(%eax,%edx,1)
2061 *(int *)((char *)page + offset) += delta;
Modules:
Module Address Debug info Name (29 modules)
PE 450000- 472000 Deferred sshdrv65.sys
ELF 7b800000-7b92d000 Deferred kernel32<elf>
  \-PE 7b820000-7b92d000 \ kernel32
ELF 7bc00000-7bca4000 Dwarf ntdll<elf>
  \-PE 7bc10000-7bca4000 \ ntdll
ELF 7bf00000-7bf03000 Deferred <wine-loader>
ELF 7eaa6000-7eb0f000 Deferred msvcrt<elf>
  \-PE 7eac0000-7eb0f000 \ msvcrt
ELF 7ec20000-7ec33000 Deferred libresolv.so.2
ELF 7ec49000-7ec67000 Deferred iphlpapi<elf>
  \-PE 7ec50000-7ec67000 \ iphlpapi
ELF 7ec67000-7ecc8000 Deferred rpcrt4<elf>
  \-PE 7ec70000-7ecc8000 \ rpcrt4
ELF...

Revision history for this message
In , gusdefrog (gusdefrog) wrote :

(In reply to comment #28)
> Created an attachment (id=12575) [details]
> Support wintab messaging for child windows
>

I could not apply this patch, using a different version of wine than it was created for I believe, or maybe just not understanding well enough how to apply it. I usually work through the package managers for software. However I do think that it is a child window problem. All of my windows painting programs that hold another window inside themselves as a canvas do not have pressure sensitivity under wine. Windows drawing programs that have the canvas as a part of the program window instead such as ArtRage 2.5 have full pressure sensitivity for me. I have tested out the default wine installation and the 1.0-rc3, Pixia, OpenCanvas, ArtRage and Corel Photopaint. I had not thought to look for that simaliarity before reading this bug.

I used to have pressure sensitivity in Pixia and OpenCanvas 1.1 in Ubuntu Feisty Fawn (when that installation package was new), but I hadn't been running any updates, and I had done some tweaking with the wine installation, I think I just compiled it from source, but I have forgotten. (Compiling (./configure, make, etc.) vs. package installation doesn't change the behavior of the current versions.) Unfortunately I upgraded to Hardy Heron, and broke it. I then assumed that the problem was with Ubuntu, however, I believe now that this bug is on a closer track with the problem.

Bug #151448 is one I created back when I found the last key that I believed fixed the problem when I was running Feisty. I think it should be closed or linked to this bug. I appologize for my poor bug ettiquette, I'm learning, but slowly.

Revision history for this message
In , Xixsimplicityxix (xixsimplicityxix) wrote :

(In reply to comment #30)
> (In reply to comment #28)
> > Created an attachment (id=12575) [details] [details]
> > Support wintab messaging for child windows
> >
>
> I could not apply this patch, using a different version of wine than it was
> created for I believe, or maybe just not understanding well enough how to apply

The patch needs to be updated.

> sensitivity for me. I have tested out the default wine installation and the
> 1.0-rc3, Pixia, OpenCanvas, ArtRage and Corel Photopaint. I had not thought to
> look for that simaliarity before reading this bug.
>
> I used to have pressure sensitivity in Pixia and OpenCanvas 1.1 in Ubuntu

I've never tried pixia but I know for certain that pressure sensitivity works for openCanvas 4.5e with wacom tablets. If you have a non wacom tablet see bugs 11699 or 12005.

> make, etc.) vs. package installation doesn't change the behavior of the current
> versions.) Unfortunately I upgraded to Hardy Heron, and broke it. I then

Broke what, your compiler? (you need to reinstall the dev packages, see the wiki) or Wine(explain in detail about what's broken).

> Bug #151448 is one I created back when I found the last key that I believed
> fixed the problem when I was running Feisty. I think it should be closed or
> linked to this bug. I appologize for my poor bug ettiquette, I'm learning, but
> slowly.
>

The following information would be great:

Tablet model:
OS version:
Program Name and Version:
Problem and steps to demonstrate the problem:

Revision history for this message
In , Todor Eemreorov (blurymind-gmail) wrote :

(In reply to comment #30)
> (In reply to comment #28)
> > Created an attachment (id=12575) [details] [details]
> > Support wintab messaging for child windows
> >
>
> I could not apply this patch, using a different version of wine than it was
> created for I believe, or maybe just not understanding well enough how to apply
> it. I usually work through the package managers for software. However I do
> think that it is a child window problem. All of my windows painting programs
> that hold another window inside themselves as a canvas do not have pressure
> sensitivity under wine. Windows drawing programs that have the canvas as a
> part of the program window instead such as ArtRage 2.5 have full pressure
> sensitivity for me. I have tested out the default wine installation and the
> 1.0-rc3, Pixia, OpenCanvas, ArtRage and Corel Photopaint. I had not thought to
> look for that simaliarity before reading this bug.
>
> I used to have pressure sensitivity in Pixia and OpenCanvas 1.1 in Ubuntu
> Feisty Fawn (when that installation package was new), but I hadn't been running
> any updates, and I had done some tweaking with the wine installation, I think I
> just compiled it from source, but I have forgotten. (Compiling (./configure,
> make, etc.) vs. package installation doesn't change the behavior of the current
> versions.) Unfortunately I upgraded to Hardy Heron, and broke it. I then
> assumed that the problem was with Ubuntu, however, I believe now that this bug
> is on a closer track with the problem.
>
> Bug #151448 is one I created back when I found the last key that I believed
> fixed the problem when I was running Feisty. I think it should be closed or
> linked to this bug. I appologize for my poor bug ettiquette, I'm learning, but
> slowly.
>

Sai's pressure sensitivity problem is still not resolved...Your report fits another bug report of wine- the one where when you upgrade to hardy heron,tablet pressure sensitivity gets borked. I had a simular problem (if not exactly the same) with wine on vector linux 5.9., which is the same as slackware 12.* (curent). Tablet pressure sensitivity in wine did not work.But somebody released a patch for an older version of wine that has it fixed on both slackware and the latest ubuntu:
http://ubuntuforums.org/showthread.php?t=745102

i had exactly the same issue under vectorlinux 5.9 and this patch on wine 0.9.61 fixed it. I can confirm that the patch has not been included in wine 1 rc2,as pressure sensitivity did not work there.

I hope they implement pressure sensitivity in sai soon.I see Sai as a worthy competator of Photoshop,its brushes are superior for cg.

Revision history for this message
In , gusdefrog (gusdefrog) wrote :

(In reply to comment #31)
> (In reply to comment #30)
> > (In reply to comment #28)
> > > Created an attachment (id=12575) [details] [details] [details]
> > > Support wintab messaging for child windows
> > >
> >
> > I could not apply this patch, using a different version of wine than it was
> > created for I believe, or maybe just not understanding well enough how to apply
>
> The patch needs to be updated.
>
> > sensitivity for me. I have tested out the default wine installation and the
> > 1.0-rc3, Pixia, OpenCanvas, ArtRage and Corel Photopaint. I had not thought to
> > look for that simaliarity before reading this bug.
> >
> > I used to have pressure sensitivity in Pixia and OpenCanvas 1.1 in Ubuntu
>
> I've never tried pixia but I know for certain that pressure sensitivity works
> for openCanvas 4.5e with wacom tablets. If you have a non wacom tablet see
> bugs 11699 or 12005.

I have a Wacom Graphire and a Wacom Intuous 3. I only have one of them pluged into a machine at a time, but have tried both of them with each version.

>
>
> > make, etc.) vs. package installation doesn't change the behavior of the current
> > versions.) Unfortunately I upgraded to Hardy Heron, and broke it. I then
>
> Broke what, your compiler? (you need to reinstall the dev packages, see the
> wiki) or Wine(explain in detail about what's broken).
>

Broke the tablet pressure sensitivity. I had it going in Feisty with Wine (but uncertain what version, sorry.)

>
> > Bug #151448 is one I created back when I found the last key that I believed
> > fixed the problem when I was running Feisty. I think it should be closed or
> > linked to this bug. I appologize for my poor bug ettiquette, I'm learning, but
> > slowly.
> >
>
> The following information would be great:
>

Tablet model: Wacom Graphire and Wacom Intuos 3
OS version: Hardy Heron
Program Name and Version: Does not work in: Pixia 3.0, Pixia 3.5 or the new APixia (but this is not a stable release yet), Corel Photopaint 6
Draws upside down and and with scribbles and errors in: Open Canvas 1.1
Works in: Artrage 2.5 trial.
Problem and steps to demonstrate the problem:
Tablet behaves like mouse in many, but not all graphic painting programs under wine. Installed Hardy Heron (On one computer, clean install, on the other upgrade. Wine automatically upgraded itself to the latest 9.59, tablet pressure stopped working in several programs. Haven't got it to work at all on the clean install for those programs. Tried Wine 1.0rc3. Same. Uninstalled Wine using "Mark for Complete Removal". Compiled from source. Same. Tried swapping tablets between computers and reinstalling Wacom drivers. On the upgraded system tried compiling the new 8.0 wacom drivers. This changed the default behavior of the tablets to relative navigation, and modified the strange output of Open Canvas 1.1, but did not fix it.

Both tablets work normally with native Linux painting and drawing applications in all installed versions.

Changed in wine:
importance: Undecided → Low
status: Incomplete → Confirmed
Changed in wine:
status: Unknown → Confirmed
Changed in wine:
status: Confirmed → Triaged
Changed in wine:
status: Confirmed → In Progress
Changed in wine (Ubuntu):
status: Triaged → Incomplete
Changed in wine:
importance: Unknown → High
affects: wine (Ubuntu) → wine1.4 (Ubuntu)
Changed in wine1.4 (Ubuntu):
status: Incomplete → Triaged
57 comments hidden view all 137 comments
Revision history for this message
In , Martin (c0rn3j) wrote :

>and while buntu 16 using POL's 1.5.5-SAI build "worked"

That's actually what I meant, not Lutris, sorry.

Could you explain how exactly you got it working?

>My current functional SAI method is sadly an XP vm in vbox. Setting the vm to use I/O APIC, PAE/NX, 4 cores, no 2d/3d acceleration and passing the tablet allows SAI to function perfectly.

I've tried a W10 KVM VM in virt-manager and pass through the tablet, which worked, but that's just either too slow (very bad framerate) or the cursor is gone (after installing spice guest tools) and it's still slightly slow.

Changed in wine:
status: In Progress → Unknown
Revision history for this message
In , Martin (c0rn3j) wrote :

Since this was just marked as staged, I compiled wine-staging from git (AUR package wine-staging-git - wine-staging-git 3.10.r14.g7c9f9bc0+wine.3.10.r149.g9ef8fa2a0b-1)

Set up latest SAI in a fresh wine prefix - https://www.systemax.jp/bin/sai-1.2.5-ful-en.exe

and neither with the default SAI config or with `AvoidOldWacomBug = 1` and `TabletMouseSimulation = 1` does the sensitivity work.

Am I missing something?

Revision history for this message
In , Martin (c0rn3j) wrote :

I forgot to add that I was trying to use Wacom Intuos Pen Small (CTL-480).

Pressure sensitivity works fine on Krita with it.

Revision history for this message
In , Alistair Leslie-Hughes (alesliehughes) wrote :

Created attachment 61661
+wintab32

Thanks for testing.

I've attached a log for wintab32 for reference.
At a guess, its one of these that needs to be handled correctly.
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 401
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 402
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 403
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 404
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 405
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 406
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 407
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 408
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 409
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 410
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 411
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 412
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 413
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 414
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 415
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 416
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 417
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 418
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 419
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 420
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 421
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 422
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 423
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 424
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 425
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 426
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 427
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 428
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 429
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 430
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 431
0034:fixme:wintab32:X11DRV_WTInfoW Unhandled Category 2

Can you please attached a +wintab32 log for comparison?

Revision history for this message
In , Martin (c0rn3j) wrote :

Created attachment 61665
+wintab32

Here you go, hopefully I did it correctly.

Changed in wine:
status: Unknown → Confirmed
Revision history for this message
In , Bob-mt-wya (bob-mt-wya) wrote :

Created attachment 62973
wine-vanilla-4.0_rc1-tablet_pressure_sensitivity_hack.patch

Patch (1.8 version) rebased for Wine 4.0-rc1.

This support was requested by a forum member: https://forum.winehq.org/viewtopic.php?f=8&t=31582

Revision history for this message
In , Alistair Leslie-Hughes (alesliehughes) wrote :

I've added Roberts patch to staging patchset, but no longer have access to a stylus to test it properly.

Can someone please confirm that every works correctly?

Revision history for this message
In , Martin (c0rn3j) wrote :

(In reply to Alistair Leslie-Hughes from comment #89)
> I've added Roberts patch to staging patchset, but no longer have access to a
> stylus to test it properly.
>
> Can someone please confirm that every works correctly?

Freshly compiled wine staging.

Trying on SAI 1.2.5 (trial downloaded from official website) with Wacom Intuos Pro M (PTH-660)

https://i.imgur.com/OluEyn2.png

Top is me drawing a line with mouse, bottom with a tablet. As you can see, it cuts off. That happens when I apply 'too much' pressure, and I can't draw anymore until I lift the pen off and try again.

So yeah, there finally is pen pressure, but it's buggy at least on my tablet after a certain pressure treshold. Native Krita works fine.

Nothing in terminal logs about this with normal logging levels.

Had to set TabletMouseSimulation = 1 in misc.ini for the mouse not to jump all over, but that seems to be a normal workaround for SAI under old patched WINE.

Changed in wine:
status: Confirmed → Unknown
Revision history for this message
In , Martin (c0rn3j) wrote :

@Alistair Is there anything else I can do to help this move? Some debug logs or something? It really seems to work perfectly up to a certain pressure point.

Revision history for this message
In , Alistair Leslie-Hughes (alesliehughes) wrote :

(In reply to C0rn3j from comment #91)
> @Alistair Is there anything else I can do to help this move? Some debug logs
> or something? It really seems to work perfectly up to a certain pressure
> point.

A +wintab32 log may help.

Revision history for this message
In , Martin (c0rn3j) wrote :

Created attachment 63430
staging 4.0 PTH-660 +wintab32

Wacom Intuos Pro M (PTH-660)
I drew 4 'lines' and made each cut off due to overpressure.
+wintab32, Wine staging 4.0

Revision history for this message
In , Matteo-mystral (matteo-mystral) wrote :

(In reply to C0rn3j from comment #93)
> Created attachment 63430 [details]
> staging 4.0 PTH-660 +wintab32
>
> Wacom Intuos Pro M (PTH-660)
> I drew 4 'lines' and made each cut off due to overpressure.
> +wintab32, Wine staging 4.0

Entirely a speculation without looking at the code at all, but from the log I get the feeling that maybe it's cutting off whenever pkNormalPressure goes above a certain threshold (32K?)

Revision history for this message
In , Federicosantamorena (federicosantamorena) wrote :

I recently moved to Linux after using Windows for two decades and I noticed this wintab32 problem, it's scary how it's more than 11 years that wintab32 is broken and it's still not fixed in 2019 for applications that ran on Windows XP.

It's nearly useless to have a Platinum running Photoshop when drawing tablets pressure is still broken.

I have a Huion H610 Pro and I decided to manage Paint Tool SAI as the super-maintainer after I noticed that the page was abandoned too.

I don't know the intricacies of Wine but you have my complete support for every type of testing purposes.

Also I tried every possible Wine version with PaintTool SAI and found a regression as explained in this bug:
https://bugs.winehq.org/show_bug.cgi?id=46827

Revision history for this message
In , Alistair Leslie-Hughes (alesliehughes) wrote :

(In reply to Matteo Bruni from comment #94)
> (In reply to C0rn3j from comment #93)
> > Created attachment 63430 [details]
> > staging 4.0 PTH-660 +wintab32
> >
> > Wacom Intuos Pro M (PTH-660)
> > I drew 4 'lines' and made each cut off due to overpressure.
> > +wintab32, Wine staging 4.0
>
> Entirely a speculation without looking at the code at all, but from the log
> I get the feeling that maybe it's cutting off whenever pkNormalPressure goes
> above a certain threshold (32K?)

No, the issue appears to be the pressure range difference between windows (0-1023 ) and Linux (0-64000).

I've updated the patchset to scale the values to range 0-1023, which makes gimp happy at least.

Revision history for this message
In , Martin (c0rn3j) wrote :

Today's wine-staging-git doesn't seem to work with the pressure at all.
Drawing in SAI seems to almost take place with max pressure.

WINEDEBUG=+wintab32 also doesn't give ANY output when drawing with the tablet in SAI, which is weird?

Keep in mind I don't have the PTH-660 anymore which I was testing with, so now testing on CTL-480.

Revision history for this message
In , Alistair Leslie-Hughes (alesliehughes) wrote :

(In reply to C0rn3j from comment #97)
> Today's wine-staging-git doesn't seem to work with the pressure at all.
> Drawing in SAI seems to almost take place with max pressure.
>
> WINEDEBUG=+wintab32 also doesn't give ANY output when drawing with the
> tablet in SAI, which is weird?
This would suggest that you have native wintab32.dll installed.

Running the following in directory wine/dlls/wintab32/tests
WINETEST_INTERACTIVE=1 make test

What is the pressure value that is displayed when pressure is applied?

Revision history for this message
In , Martin (c0rn3j) wrote :

Doesn't look like that works for pure git wine

c0rn3j@Luxuria ‹ master › : /tmp/wine/dlls/wintab32/tests
[0] % WINETEST_INTERACTIVE=1 make test
make: *** No rule to make target 'test'. Stop.

c0rn3j@Luxuria ‹ master › : /tmp/wine/dlls/wintab32/tests
[2] % cd ..

c0rn3j@Luxuria ‹ master › : /tmp/wine/dlls/wintab32
[0] % WINETEST_INTERACTIVE=1 make test
make: *** No rule to make target 'test'. Stop.

Revision history for this message
Sabs (sabslikesobs) wrote :
Download full text (3.9 KiB)

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

Read more...

Revision history for this message
In , Sobs (sobs) wrote :
Download full text (3.9 KiB)

Created attachment 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 under...

Read more...

Revision history for this message
In , Sobs (sobs) wrote :

A little more testing with DEBUGLEVEL=+msg,+win and sai.exe showed that the window registered to the tablet events differed from the window that was receiving mouse click events from clicking down with my stylus. Also, I couldn't figure out how to get a log of *all* input events (hoping to see Wine recognize that packets of some kind were coming from my tablet, somewhere), and the only events I could catch with +msg were those of normal mouse clicks from the pen. I thought it was odd that they were treated only as normal mouse clicks.

Maybe there's some kind of regression in finding the correct window. Many earlier patches in the thread dealt with this. Krita had a similar problem but I didn't thoroughly investigate it in the same way (it may also be useful to check easily accessible wintab-using programs like Gimp

My volatile testing environment ate my latest logs for this, but if you need any more than the ones in my last comment, I can re-create them.

Revision history for this message
In , oh (jigglywiggly) wrote :

Are any logs needed to get some progress on this? It's very disappointing that tablet support is completely broken.

Revision history for this message
In , oh (jigglywiggly) wrote :

I tried Photoshop CS2 in crossover 18.5.0 which uses Wine 4.0 and tablet support actually works just fine. I tried CS6 and that does not work. I tried Wine 4.12 staging in CS2 and tablet support there is broken.

Revision history for this message
In , oh (jigglywiggly) wrote :

I tried 4.14 and tablet support is still broken but at least is starting to work. There is some type of pressure support working in Photoshop CS6 but when the pressure works it is extremely laggy. You will only get about 3 points of pressure due to the lag. Also it doesn't pick up pressure a lot of the time. Also it does not seem to use all the pressure range, I have to press really light for it to not make a completely 100% pressure line.

Revision history for this message
In , Alistair Leslie-Hughes (alesliehughes) wrote :

(In reply to jigglywiggly from comment #104)
> I tried 4.14 and tablet support is still broken but at least is starting to
> work. There is some type of pressure support working in Photoshop CS6 but
> when the pressure works it is extremely laggy. You will only get about 3
> points of pressure due to the lag. Also it doesn't pick up pressure a lot of
> the time. Also it does not seem to use all the pressure range, I have to
> press really light for it to not make a completely 100% pressure line.

Since pressure is just working, I'm expecting it to be a scaling issue wrt to the pressure value returned.

Are you able to compile wine?

Can you provide a +wintab32 log?

Revision history for this message
In , oh (jigglywiggly) wrote :

Created attachment 65084
wintab32 logs wine 4.14

I am just using AUR to compile Wine's git. I take back the pressure sensitivity range, it does seem to use the whole range. I was mistaken as it is hard to tell with the very low sampling rate.

The log file is very large at 80 megabytes for only a few seconds of testing. Since most of it is redundant, I uploaded it as a zip so it would fit.
wintab32-4.14.zip

Revision history for this message
In , Federicosantamorena (federicosantamorena) wrote :

PaintTool SAI SuperMaintainer here

I want to notify you that with Wine 4.17 and Huion 610P 2048 tablet when starting PenPressureTest.exe (a simple test software in Huion Windows package) after installing the Windows drivers Pen Pressure finally works!!!

On Arch with 5.3.7-arch1-1-ARCH

Still NOT working on PaintTool SAI 1.2.5
Still NOT recognized as attached when starting TabletDriver.exe (a GUI with settings for the custom Huion buttons and stuff)

DOES NOT work with LTS 4.x kernel

Revision history for this message
In , Federicosantamorena (federicosantamorena) wrote :

Tested 4.18 staging, no improvements, but also no regressions.

And I want to add that pressure settings for Huion tablets seem to work well with no problems even in multi-monitor environments.

The only problem is that the GUI Huion settings application gets wrong values for multi-monitor sizes when setting the ratio of the active tablet area, but if you just stay with the default ratio pen pressure works with the bundled demo app.

Revision history for this message
In , John Chadwick (johnwchadwick) wrote :
Download full text (3.4 KiB)

Hey all, I hope you are doing well. It has been a while. It appears the first time I touched this issue was all the way back in 2015.

I am currently in the process of trying to get Painttool SAI 2 to work properly under mainline Wine. One patch is already in (https://source.winehq.org/patches/data/173932), the next is in flight (https://source.winehq.org/patches/data/174062), and I have a third change that should make everything work correctly that I will submit once the second fix is squared away. After that, SAI 2 should work properly in Wine without any need to mess with configurations.

This got me thinking back to SAI 1, and I think I finally fully understand the problem. With a little bit of tracing, I noticed that SAI 1 does some interesting Wintab magic. It creates a top-level, hidden window with the sfl_wintab_window class, and no geometry to speak of.

What's going on here? It appears SAI 1 uses this magic window to receive Wintab32 events. The thing is, Wintab32 events are not like mouse events. It seems that Wintab32 actually handles the contexts as a stack, and hidden top-level windows appear to be treated as covering the entire screen. Painttool SAI 1 uses the WTOverlap function to move its context to the top of the stack when the window is focused, and to the bottom of the stack when the window is unfocused.

Here's where things get tricky: In the Xinput code, XSelectExtensionEvent is called on the X11 window of hOwner (using X11DRV_get_whole_window.) This works in the case where the context == the window where you will be using the tablet. It does *NOT* work in the case of using top level hidden windows to receive Wintab32 events and manually shuffling them using WTOverlap. Even if we patch it to XSelectExtensionEvent on the root window, it won't be able to figure out what context it should send the events to.

The Wintab code should probably register for events in X11DRV_LoadTabletInfo, and it should do so on the X11 root window. X11DRV_AttachEventQueueToTablet should just map the hWnd to a context. But crucially, the way the event handlers work needs to change. Instead of sending the message directly to the hWnd that the event is matched with, the hWnd should be ignored, and we should iterate through a stack of windows, finding the first one that overlaps with the event coordinates. Then, WTOverlap should be implemented to manipulate this stack.

I suspect all of the information we need to determine if a context overlaps is the HWND. So, we already have most of the necessary information. However, we do need a way to propagate the WTOverlap calls back to winex11.drv, which will probably need to come in the form of new graphics driver functions. In the meantime, it's probably not a big deal to ignore WTOverlap since it probably only has an impact when working between different applications.

It's probably going to be valuable to also investigate the behaviors and interactions between various techniques in Windows. For example, what happens when you drag the tablet outside the window? It may not be sufficient to simply route events based on what the top most context matching the geometry is; some additional heuristics may be n...

Read more...

Revision history for this message
In , oh (jigglywiggly) wrote :
Download full text (3.6 KiB)

(In reply to John Chadwick from comment #109)
> Hey all, I hope you are doing well. It has been a while. It appears the
> first time I touched this issue was all the way back in 2015.
>
> I am currently in the process of trying to get Painttool SAI 2 to work
> properly under mainline Wine. One patch is already in
> (https://source.winehq.org/patches/data/173932), the next is in flight
> (https://source.winehq.org/patches/data/174062), and I have a third change
> that should make everything work correctly that I will submit once the
> second fix is squared away. After that, SAI 2 should work properly in Wine
> without any need to mess with configurations.
>
> This got me thinking back to SAI 1, and I think I finally fully understand
> the problem. With a little bit of tracing, I noticed that SAI 1 does some
> interesting Wintab magic. It creates a top-level, hidden window with the
> sfl_wintab_window class, and no geometry to speak of.
>
> What's going on here? It appears SAI 1 uses this magic window to receive
> Wintab32 events. The thing is, Wintab32 events are not like mouse events. It
> seems that Wintab32 actually handles the contexts as a stack, and hidden
> top-level windows appear to be treated as covering the entire screen.
> Painttool SAI 1 uses the WTOverlap function to move its context to the top
> of the stack when the window is focused, and to the bottom of the stack when
> the window is unfocused.
>
> Here's where things get tricky: In the Xinput code, XSelectExtensionEvent is
> called on the X11 window of hOwner (using X11DRV_get_whole_window.) This
> works in the case where the context == the window where you will be using
> the tablet. It does *NOT* work in the case of using top level hidden windows
> to receive Wintab32 events and manually shuffling them using WTOverlap. Even
> if we patch it to XSelectExtensionEvent on the root window, it won't be able
> to figure out what context it should send the events to.
>
> The Wintab code should probably register for events in
> X11DRV_LoadTabletInfo, and it should do so on the X11 root window.
> X11DRV_AttachEventQueueToTablet should just map the hWnd to a context. But
> crucially, the way the event handlers work needs to change. Instead of
> sending the message directly to the hWnd that the event is matched with, the
> hWnd should be ignored, and we should iterate through a stack of windows,
> finding the first one that overlaps with the event coordinates. Then,
> WTOverlap should be implemented to manipulate this stack.
>
> I suspect all of the information we need to determine if a context overlaps
> is the HWND. So, we already have most of the necessary information. However,
> we do need a way to propagate the WTOverlap calls back to winex11.drv, which
> will probably need to come in the form of new graphics driver functions. In
> the meantime, it's probably not a big deal to ignore WTOverlap since it
> probably only has an impact when working between different applications.
>
> It's probably going to be valuable to also investigate the behaviors and
> interactions between various techniques in Windows. For example, what
> happens when you drag the tablet outside the wind...

Read more...

Revision history for this message
In , Federicosantamorena (federicosantamorena) wrote :
Download full text (4.0 KiB)

(In reply to John Chadwick from comment #109)
> Hey all, I hope you are doing well. It has been a while. It appears the
> first time I touched this issue was all the way back in 2015.
>
> I am currently in the process of trying to get Painttool SAI 2 to work
> properly under mainline Wine. One patch is already in
> (https://source.winehq.org/patches/data/173932), the next is in flight
> (https://source.winehq.org/patches/data/174062), and I have a third change
> that should make everything work correctly that I will submit once the
> second fix is squared away. After that, SAI 2 should work properly in Wine
> without any need to mess with configurations.
>
> This got me thinking back to SAI 1, and I think I finally fully understand
> the problem. With a little bit of tracing, I noticed that SAI 1 does some
> interesting Wintab magic. It creates a top-level, hidden window with the
> sfl_wintab_window class, and no geometry to speak of.
>
> What's going on here? It appears SAI 1 uses this magic window to receive
> Wintab32 events. The thing is, Wintab32 events are not like mouse events. It
> seems that Wintab32 actually handles the contexts as a stack, and hidden
> top-level windows appear to be treated as covering the entire screen.
> Painttool SAI 1 uses the WTOverlap function to move its context to the top
> of the stack when the window is focused, and to the bottom of the stack when
> the window is unfocused.
>
> Here's where things get tricky: In the Xinput code, XSelectExtensionEvent is
> called on the X11 window of hOwner (using X11DRV_get_whole_window.) This
> works in the case where the context == the window where you will be using
> the tablet. It does *NOT* work in the case of using top level hidden windows
> to receive Wintab32 events and manually shuffling them using WTOverlap. Even
> if we patch it to XSelectExtensionEvent on the root window, it won't be able
> to figure out what context it should send the events to.
>
> The Wintab code should probably register for events in
> X11DRV_LoadTabletInfo, and it should do so on the X11 root window.
> X11DRV_AttachEventQueueToTablet should just map the hWnd to a context. But
> crucially, the way the event handlers work needs to change. Instead of
> sending the message directly to the hWnd that the event is matched with, the
> hWnd should be ignored, and we should iterate through a stack of windows,
> finding the first one that overlaps with the event coordinates. Then,
> WTOverlap should be implemented to manipulate this stack.
>
> I suspect all of the information we need to determine if a context overlaps
> is the HWND. So, we already have most of the necessary information. However,
> we do need a way to propagate the WTOverlap calls back to winex11.drv, which
> will probably need to come in the form of new graphics driver functions. In
> the meantime, it's probably not a big deal to ignore WTOverlap since it
> probably only has an impact when working between different applications.
>
> It's probably going to be valuable to also investigate the behaviors and
> interactions between various techniques in Windows. For example, what
> happens when you drag the tablet outside the wind...

Read more...

Revision history for this message
In , Shiro-3 (shiro-3) wrote :

Hello, just tested the latest patches from staging on PS 2018 and it seems like pressure sensitivity is working to some extend.

I observed 2 major bugs:
- 50% of the time when the brush tool is used, pressure sensitivity does not work at all, producing a line with 100% line thickness, seems to be random
- when a quick line is drawn, it either works or just draws a single dot

I recorded a quick video to illustrate: https://streamable.com/fz57b

The log from the demo including the debug wintab output is attached, hope this helps in any way.

Revision history for this message
In , D-john-j (d-john-j) wrote :

I've just noticed that another commit of mine has landed in master, and with that, pressure sensitivity should be basically functional in PaintTool SAI 2. Just tested the latest revision (ddec23013e39b563a3a50c0fe42c2ae8b518d538) with a freshly unzipped SAI 2 (sai2-20190812-32bit-en) and a new WINEPREFIX, and it appears to work.

There are still issues:

- At least on my setup, different kinds of cursors (like erasers) are treated the same as the pen.

- SAI 2 spits out a bunch of errors when you first start drawing (but seems to function anyways.)

- SAI 1 is still broken without additional patches. As mentioned before, the way Wine handles Wintab contexts is not accurate. However, the behavior is different than I thought and has nothing to do with what position on the screen the tablet is at. (Playing with Wacom Wintab, it actually appears that it has more to do with what window is in the foreground as to what contexts receive events.)

>Hello, just tested the latest patches from staging on PS 2018 and it seems like pressure sensitivity is working to some extend.
>
>I observed 2 major bugs:
>- 50% of the time when the brush tool is used, pressure sensitivity does not work at all, producing a line with 100% line thickness, seems to be random
>- when a quick line is drawn, it either works or just draws a single dot

I have not looked into your problems yet, but since a lot of stuff is changing it might help to periodically check and see if anything has improved. I suspect the issues in PS2018 are probably a lot different from the issues in SAI. I don't have a modern copy of Photoshop, so I have been testing with a very old version (which does not seem to have this problem.)

Revision history for this message
In , Shiro-3 (shiro-3) wrote :

Problem still persists with the latest patches. Nevertheless it is amazing to see this going forward, PS being usable under Wine seems so close now! Great work.

Revision history for this message
In , Layif52204 (layif52204) wrote :

Hi there, I'm not quite sure if this is directly related or not, but I thought I'd check just in case before submitting a new bug report.

I'm having issues in Clip Studio Paint where if the tablet is set to relative mode input is completely lost if the lines are perfectly vertical, while the terminal outputs "002c:fixme:wintab32:motion_event Negative orAltitude detected" for each motion event.

Pressure on the other hand works perfectly.

Video of the problem, recorded using Clip Studio Paint Pro v1.9.4 running on the latest Wine 4.21 staging from Manjaro repository:
https://streamable.com/jxi6u

A download for Clip Studio Paint (v1.9.5) can be found at:
https://www.clipstudio.net/en/dl

(Although recorded in v1.9.4, the issue has been present for a number of releases, and is still present in the latest release v1.9.5.)

Revision history for this message
In , Alistair Leslie-Hughes (alesliehughes) wrote :

(In reply to amiire from comment #115)
> Hi there, I'm not quite sure if this is directly related or not, but I
> thought I'd check just in case before submitting a new bug report.
>
> I'm having issues in Clip Studio Paint where if the tablet is set to
> relative mode input is completely lost if the lines are perfectly vertical,
> while the terminal outputs "002c:fixme:wintab32:motion_event Negative
> orAltitude detected" for each motion event.
>
Please file a new bug report, against wine-staging as the patch isn't upstream.

Revision history for this message
In , Layif52204 (layif52204) wrote :

(In reply to Alistair Leslie-Hughes from comment #116)
> (In reply to amiire from comment #115)
> > Hi there, I'm not quite sure if this is directly related or not, but I
> > thought I'd check just in case before submitting a new bug report.
> >
> > I'm having issues in Clip Studio Paint where if the tablet is set to
> > relative mode input is completely lost if the lines are perfectly vertical,
> > while the terminal outputs "002c:fixme:wintab32:motion_event Negative
> > orAltitude detected" for each motion event.
> >
> Please file a new bug report, against wine-staging as the patch isn't
> upstream.

Sure thing, thanks for the help.

Revision history for this message
In , Dough-mean (dough-mean) wrote :

It seems that there are a decent amount of successes in the past when it comes to running sai v1 with pressure. But how? What exactly that made it stop working? And why can't it be replicated in newer Wine setups?
I'm trying out the ancient 1.5.5-SAI patch on a new Ubuntu system, and it *almost* works. As you draw, you won't be able to see your brush stroke. But once you've released your pen, a semi-straight stroke is generated between the initial contact and the final release. But you can still control the pressure somewhat, based on how hard you initially pressed your pen.
While it's great that sai2 is fully functional, I miss a lot of stuff from the good old sai v1. Such as the superior stabilizer feel, max dens prs, the 0-255 HSV slider range, etc.

Revision history for this message
In , Devil-tamachan (devil-tamachan) wrote :

pkButtons is always 2.

https://www.winehq.org/pipermail/wine-devel/2007-December/061414.html
> That is, in X, our devices come out as 1 based (not 0 based), and
> on Windows, they report as 0 based. iow, with this patch, pkButtons is always 2;
> on Windows, it's always 1.

patch

https://github.com/wine-mirror/wine/blob/master/dlls/winex11.drv/wintab.c#L906

wintab.c - motion_event()

    gMsgPacket.pkNormalPressure = motion->axis_data[2];
- gMsgPacket.pkButtons = get_button_state(curnum);
+ gMsgPacket.pkButtons = get_button_state(curnum)-1;
    gMsgPacket.pkChanged = get_changed_state(&gMsgPacket);

Revision history for this message
In , Ztirfe Elgnid (z-figura12) wrote :

*** Bug 50746 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Alastair-trackermail (alastair-trackermail) wrote :

This issue is still occuring in 6.15 staging

Displaying first 40 and last 40 comments. View all 137 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.