[Bug 11846] New: tablet pressure sensitivity not working in Sai and many other key graphic applications
http://bugs.winehq.org/show_bug.cgi?id=11846
Summary: tablet pressure sensitivity not working in Sai and many other key graphic applications Product: Wine Version: 0.9.56. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wintab32 AssignedTo: wine-bugs@winehq.org ReportedBy: blurymind@gmail.com
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&iT...
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.
http://bugs.winehq.org/show_bug.cgi?id=11846
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #1 from Dan Kegel dank@kegel.com 2008-03-13 10:38:58 --- What tablet do you have?
Can you give us a +wintab32 log?
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #2 from theodore eemre blurymind@gmail.com 2008-03-15 11:49:08 --- (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, 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, 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, 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, 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, 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, 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, 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, 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, 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, 0xad5b7d): stub fixme:wintab32:WTSetA (0xc00, 0xad5b7d): stub fixme:wintab32:WTSetA (0xc00, 0xad5b7d): stub fixme:wintab32:WTSetA (0xc00, 0xad5b7d): stub
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #3 from theodore eemre blurymind@gmail.com 2008-03-15 11:56:10 --- 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?
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #4 from Dan Kegel dank@kegel.com 2008-03-15 11:59:24 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #5 from Dan Kegel dank@kegel.com 2008-03-15 12:02:11 --- It looks like SAI has a trial mode and can be downloaded from http://www.systemax.jp/sai/bin/sai-1.0.0.zip
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #6 from theodore eemre blurymind@gmail.com 2008-03-15 15:10:34 --- Created an attachment (id=11411) --> (http://bugs.winehq.org/attachment.cgi?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
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #7 from theodore eemre blurymind@gmail.com 2008-03-15 15:12:12 --- (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
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #8 from Dan Kegel dank@kegel.com 2008-03-15 16:05:27 --- 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.)
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #9 from Dan Kegel dank@kegel.com 2008-03-15 16:06:49 --- 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.)
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #10 from theodore eemre blurymind@gmail.com 2008-03-16 04:13:39 --- Created an attachment (id=11427) --> (http://bugs.winehq.org/attachment.cgi?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
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #11 from theodore eemre blurymind@gmail.com 2008-03-16 04:17:25 --- (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.
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #12 from theodore eemre blurymind@gmail.com 2008-03-16 04:21:02 --- (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.
http://bugs.winehq.org/show_bug.cgi?id=11846
theodore eemre blurymind@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|0.9.56. |0.9.57.
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #13 from Dan Kegel dank@kegel.com 2008-03-16 08:29:43 --- Thanks for the info. We'll try SAI here.
http://bugs.winehq.org/show_bug.cgi?id=11846
Lei Zhang thestig@google.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://www.systemax.jp/sai/b | |in/sai-1.0.0.zip Keywords| |download Version|0.9.57. |0.9.56.
--- Comment #14 from Lei Zhang thestig@google.com 2008-03-16 11:22:09 --- please leave the version field alone.
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #15 from theodore eemre blurymind@gmail.com 2008-03-21 05:55:28 --- (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.
http://bugs.winehq.org/show_bug.cgi?id=11846
Dmitry P harddoping@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |harddoping@gmail.com
--- Comment #16 from Dmitry P harddoping@gmail.com 2008-03-22 06:05:46 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=11846
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #17 from Dan Kegel dank@kegel.com 2008-03-22 07:07:19 --- Marking confirmed since 2nd user sees problem.
Does http://www.winehq.org/pipermail/wine-patches/2008-March/051905.html help, by any chance?
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #18 from Dmitry P harddoping@gmail.com 2008-04-03 14:15:29 --- (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.
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #19 from John Klehm xixsimplicityxix@gmail.com 2008-04-09 19:10:21 --- Created an attachment (id=12026) --> (http://bugs.winehq.org/attachment.cgi?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.
http://bugs.winehq.org/show_bug.cgi?id=11846
John Klehm xixsimplicityxix@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xixsimplicityxix@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #20 from John Klehm xixsimplicityxix@gmail.com 2008-04-10 01:56:02 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #21 from John Klehm xixsimplicityxix@gmail.com 2008-04-10 15:27:51 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #22 from John Klehm xixsimplicityxix@gmail.com 2008-04-14 17:48:04 --- WTSetA/W committed: http://www.winehq.org/pipermail/wine-cvs/2008-April/042462.html
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #23 from John Klehm xixsimplicityxix@gmail.com 2008-04-16 03:15:20 --- 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
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #24 from John Klehm xixsimplicityxix@gmail.com 2008-04-18 12:32:59 --- 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
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #25 from theodore eemre blurymind@gmail.com 2008-04-18 16:20:26 --- 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?
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #26 from John Klehm xixsimplicityxix@gmail.com 2008-04-19 02:55:26 --- 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
http://bugs.winehq.org/show_bug.cgi?id=11846
John Klehm xixsimplicityxix@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #12026|0 |1 is obsolete| |
--- Comment #27 from John Klehm xixsimplicityxix@gmail.com 2008-04-29 14:22:42 --- Created an attachment (id=12574) --> (http://bugs.winehq.org/attachment.cgi?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
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #28 from John Klehm xixsimplicityxix@gmail.com 2008-04-29 14:23:45 --- Created an attachment (id=12575) --> (http://bugs.winehq.org/attachment.cgi?id=12575) Support wintab messaging for child windows
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #29 from theodore eemre blurymind@gmail.com 2008-05-08 08:17:13 --- 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..
http://bugs.winehq.org/show_bug.cgi?id=11846
Kathi gusdefrog@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gusdefrog@yahoo.com
--- Comment #30 from Kathi gusdefrog@yahoo.com 2008-06-02 14:02:55 --- (In reply to comment #28)
Created an attachment (id=12575)
--> (http://bugs.winehq.org/attachment.cgi?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.
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #31 from John Klehm xixsimplicityxix@gmail.com 2008-06-02 19:00:47 --- (In reply to comment #30)
(In reply to comment #28)
Created an attachment (id=12575)
--> (http://bugs.winehq.org/attachment.cgi?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:
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #32 from theodore eemre blurymind@gmail.com 2008-06-03 05:15:11 --- (In reply to comment #30)
(In reply to comment #28)
Created an attachment (id=12575)
--> (http://bugs.winehq.org/attachment.cgi?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.
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #33 from Kathi gusdefrog@yahoo.com 2008-06-05 18:03:00 --- (In reply to comment #31)
(In reply to comment #30)
(In reply to comment #28)
Created an attachment (id=12575)
--> (http://bugs.winehq.org/attachment.cgi?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.
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #34 from John Klehm xixsimplicityxix@gmail.com 2008-06-05 19:31:38 --- (In reply to comment #33)
(In reply to comment #31)
(In reply to comment #30)
(In reply to comment #28)
Created an attachment (id=12575)
--> (http://bugs.winehq.org/attachment.cgi?id=12575) [details] [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.
Kathi, thanks for the info. If you can file a new bug with the above info that would be great. This bug is long enough as it is and is going to focus on issues with sai.
Kathi, if you can in addition to the info above, also attach the output of (when run from a terminal) xsetpointer -l and xidump -l and a debug log for pixia when run in wine from a terminal: WINEDEBUG="+wintab32" wine pathtopixia.exe
where pathtopixia is the actual program path.
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #35 from John Klehm xixsimplicityxix@gmail.com 2008-06-05 19:33:02 --- oops the actual command for the debug log should be this:
WINEDEBUG="+wintab32" wine pathtopixia.exe &> pixia.log
and then add pixia.log as an attachment to the bug.
Thanks!
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #36 from Kathi gusdefrog@yahoo.com 2008-06-09 13:56:06 --- Here you go: http://bugs.winehq.org/show_bug.cgi?id=13808
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #37 from Caius "kaio" Chance caio@dejieshi.com 2008-09-16 21:31:20 --- Created an attachment (id=16132) --> (http://bugs.winehq.org/attachment.cgi?id=16132) Re-gen patch based on comment# 28.
This patch is based on comment #28. I just did the labor job: manually copied from previous patch and pasted into latest git check out.
===== $git log | head
commit d943ffa6f798f106bc7e4b398bab9622f97a85b7 Author: Hans Leidekker hans@codeweavers.com Date: Tue Sep 16 12:32:11 2008 +0200 =====
Please kindly test if this work.
(I have Intuos3 and SAI 1.0.1 also doesn't work on wine 1.1.4. ArtRage 2.5.13 works for me on wine 1.1.4. My OS is Fedora 9.)
http://bugs.winehq.org/show_bug.cgi?id=11846
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=11846
Caius "kaio" Chance caio@dejieshi.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |caio@dejieshi.com
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #38 from Caius "kaio" Chance caio@dejieshi.com 2008-09-18 07:38:29 --- Tested with re-based patch on the last comment. It doesn't work with the followings messages:
$ ~/src/wine/wine/wine sai.exe fixme:htmlhelp:HtmlHelpW HH case HH_INITIALIZE not handled. fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETSTATE): stub fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETAUTOHIDEBAR, hwnd=(nil), edge=0): stub fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETAUTOHIDEBAR, hwnd=(nil), edge=2): stub fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETAUTOHIDEBAR, hwnd=(nil), edge=1): stub fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETAUTOHIDEBAR, hwnd=(nil), edge=3): stub fixme:wintab32:WTOverlap Not moving context to top of overlap order fixme:wintab32:X11DRV_WTInfoW Unhandled Category 2 fixme:wintab32:WTOverlap Not moving context to bottom of overlap order fixme:wintab32:WTOverlap Not moving context to top of overlap order fixme:wintab32:X11DRV_WTInfoW Unhandled Category 2 fixme:wintab32:WTOverlap Not moving context to bottom of overlap order fixme:wintab32:WTOverlap Not moving context to bottom of overlap order fixme:htmlhelp:HtmlHelpW HH case HH_UNINITIALIZE not handled.
http://bugs.winehq.org/show_bug.cgi?id=11846
Salvatore Iovene salvatore.iovene@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |salvatore.iovene@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11846
John Klehm xixsimplicityxix@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #12574|0 |1 is obsolete| | AssignedTo|wine-bugs@winehq.org |xixsimplicityxix@gmail.com Status|NEW |ASSIGNED
--- Comment #39 from John Klehm xixsimplicityxix@gmail.com 2008-10-03 00:00:58 --- Created an attachment (id=16438) --> (http://bugs.winehq.org/attachment.cgi?id=16438) Try even harder to find an x11 window for the tablet
Tries to attach to just about every window that could be its parent or owner.
http://bugs.winehq.org/show_bug.cgi?id=11846
John Klehm xixsimplicityxix@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #12575|0 |1 is obsolete| | Attachment #16132|0 |1 is obsolete| |
--- Comment #40 from John Klehm xixsimplicityxix@gmail.com 2008-10-03 00:05:03 --- Created an attachment (id=16439) --> (http://bugs.winehq.org/attachment.cgi?id=16439) A much better way to get x11 event messages to child windows
Though the other patch worked it was very inefficient and cpu intensive.
This patch provides a much better way of connecting the x11 events to a child window by storing the child window and then double posting the message to both parent and child (or owner and client, whatever it may be).
http://bugs.winehq.org/show_bug.cgi?id=11846
John Klehm xixsimplicityxix@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|xixsimplicityxix@gmail.com |
--- Comment #41 from John Klehm xixsimplicityxix@gmail.com 2008-10-03 00:14:33 --- Well after playing around for an hour today I've concluded that the only way to move on is to write a wintab test program of my own to see what wine's wintab isn't doing. Using my two most recent patches sai generates plenty of tablet packets and it even collects them for processing with WTPacket. It just doesn't seem to get the signal to start um doing its pressure thing.
Pretty odd, my current hope is that we aren't sending some kind of simple enabled message or something. Only a test program will tell though.
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #42 from John Klehm xixsimplicityxix@gmail.com 2008-10-03 00:33:15 --- Created an attachment (id=16440) --> (http://bugs.winehq.org/attachment.cgi?id=16440) Log after child window x11 events support and try harder to attach patches
Log of running sai and then drawing a stroke with the pen. You can see the pressure in the tablet packets, and that sai picks them up with WTPacket. It doesn't seem to use the info though, so we're still missing something.
http://bugs.winehq.org/show_bug.cgi?id=11846
billstei billstei@hbci.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |billstei@hbci.com
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #43 from billstei billstei@hbci.com 2008-11-01 11:05:59 --- Tested Wine 1.1.7 with both patches applied "Try even harder..." and "A much better way...", and using ArtWeaver 0.5.5 I have pressure working.
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #44 from Caius "kaio" Chance caio@dejieshi.com 2008-11-01 11:14:06 --- (In reply to comment #43)
Tested Wine 1.1.7 with both patches applied "Try even harder..." and "A much better way...", and using ArtWeaver 0.5.5 I have pressure working.
Could you test with Paint-Tool SAI please?
ArtRage works before any patches mentioned here. Hence, this bug only affects *some* graphic applications.
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #45 from billstei billstei@hbci.com 2008-11-01 14:32:01 --- Tested SAI with comment #43 setup and pressure did not work (not conclusive though as I am not familiar with SAI brushes/setup to be sure). I am getting wintab packets with (some) pressure info like this:
trace:wintab32:DUMPPACKET pkContext: 0xc00 pkStatus: 0x0 pkTime : 0x2b202 pkChanged: 0x0 pkSerialNumber: 0x2006 pkCursor : 1 pkButtons: 2 pkX: 0 pkY: 0 pkZ: 0 pkNormalPressure: 564 pkTangentPressure: 0 pkOrientation: (1596,355,0) pkRotation: (0,0,0)
where pkNormalPressure is changing for each packet.
Also tried changing GA_PARENT to GA_ROOT on line #459 in dlls/wintab32/context.c and still fails ( see Wine bug #15443 ).
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #46 from billstei billstei@hbci.com 2008-11-01 14:55:34 --- Regarding differences between ArtWeaver (working) and Sai (not working) with comment #43 setup, both wintab32 traces typically begin with a "motion_event" and end with a "WTPacket Returning 1", however in the case of ArtWeaver these additional calls are made after WTPacket Returning 1 and before the next motion_event (typical example shown):
trace:wintab32:WTInfoT (100, 15, 0x32fd10, 0) trace:wintab32:X11DRV_WTInfoW (100, 15, 0x32fd10) trace:wintab32:WTInfoT returns 16 trace:wintab32:WTInfoT (100, 15, 0x32fd00, 0) trace:wintab32:X11DRV_WTInfoW (100, 15, 0x32fd00) trace:wintab32:WTInfoT returns 16
http://bugs.winehq.org/show_bug.cgi?id=11846
John Klehm xixsimplicityxix@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #16438|0 |1 is obsolete| | Attachment #16439|0 |1 is obsolete| |
--- Comment #47 from John Klehm xixsimplicityxix@gmail.com 2008-12-03 11:25:08 --- Created an attachment (id=17616) --> (http://bugs.winehq.org/attachment.cgi?id=17616) Fixes the bad assumption that the hwnd frm the generated x11 event is the context owner
This patch should just work(tm) for all the programs that had to manaully choose GA_PARENT, GA_ROOT or whatnot.
It's a much cleaner fix than my previous two patches. So no more manual hacking just apply the patch and it should work.
Please test if you can of course.
I'm going to send it in to mainline just as soon as I have a few people review it.
Keep in mind that this patch and my previous patches do NOT fix paint tool sai. This partially fixes it and probably completely fixes at least a few other tablet programs.
I'm convinced now that Sai needs NCHITTEST messages which wine doesnt support currently. I'm still plugging away on it.
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #48 from billstei billstei@hbci.com 2008-12-03 19:21:30 --- Tested Wine 1.1.9 with 2008-12-03 patch and pressure is working okay in ArtWeaver 0.5.6
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #49 from Caius "kaio" Chance caio@dejieshi.com 2009-01-12 07:13:05 --- Tested wine 1.1.9 with SAI 1.1.0 full release.
Pressure sensitivity doesn't work.
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #50 from Caius "kaio" Chance caio@dejieshi.com 2009-02-10 21:48:39 --- Hi, any news?
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #51 from John Klehm xixsimplicityxix@gmail.com 2009-02-11 00:07:17 --- (In reply to comment #50)
Hi, any news?
I emailed Alexandre about the last patch I have here. He told me that it was fine except that it doesn't handle the case in which the X11 Window isn't created yet. It is not acceptable to fall back to the desktop window like my patch does here. I haven't had the time to investigate how and when exactly X11 Windows are created for the corresponding hwnds.
So essentially it's close but not quite.
3 things have to happen before this will be fixed:
1) X11 Window not created yet fall back behavior for wintab32 (the desktop fall back in the patch I have here needs to be changed to something better) 2) tests to determine the appropriate behavior of child window mouse messages 3) correct or implement the missing mouse message behavior in wine
I've become really poor lately so I havent had much time for wine. Hopefully that will change soon. For now I have no further progress than what I've posted here except for some really hacky mouse message code.
http://bugs.winehq.org/show_bug.cgi?id=11846
John Klehm xixsimplicityxix@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maddox.br@gmail.com
--- Comment #52 from John Klehm xixsimplicityxix@gmail.com 2009-07-14 19:35:13 --- *** Bug 19250 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=11846
rusivi rusivi1@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rusivi1@gmail.com
--- Comment #53 from rusivi rusivi1@gmail.com 2010-09-13 17:52:50 CDT --- Does this issue occur in newest WINE?
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #54 from billstei billstei@hbci.com 2010-09-13 19:37:47 CDT --- Tested ArtWeaver Plus 1.52 with Wine 1.3.2 and the problem is still present.
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #55 from Dario Ernst winebugs@nebuk.de 2010-09-24 07:41:11 CDT --- Created an attachment (id=30943) --> (http://bugs.winehq.org/attachment.cgi?id=30943) Sai log with wine git 24-sep-2010
sai with misc.ini setting on default (let sai handle), wine-git from 24-sep-2010 and patch http://bugs2.winehq.org/attachment.cgi?id=17622 applied.
http://bugs.winehq.org/show_bug.cgi?id=11846
Dario Ernst winebugs@nebuk.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #30943|Sai log with wine git |Sai log with wine git description|24-sep-2010 |24-sep-2010 and patch | |http://bugs2.winehq.org/att | |achment.cgi?id=17622
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #56 from Dario Ernst winebugs@nebuk.de 2010-09-24 07:44:43 CDT --- i've just manually patched the current wine-git with http://bugs.winehq.org/attachment.cgi?id=30943 and tried with sai english 1.10 with both misc.ini settings (tablet stuff handled by sai, handled by wintab) - both do not work. I've attached the log where the stuff is handled by sai. I've also tried various other methods such as changing GA_PARENT to GA_ROOT as suggested in http://bugs.winehq.org/show_bug.cgi?id=11846#c45 - none worked.
Is there any way to get this running? I'm willing to do anything - such as excessive patch orgies by now...
Thanks for all your work!
http://bugs.winehq.org/show_bug.cgi?id=11846
Kaetemi kaetemi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaetemi@gmail.com
--- Comment #57 from Kaetemi kaetemi@gmail.com 2012-03-24 17:32:42 CDT --- 1. The HWND passed to X11DRV_AttachEventQueueToTablet does not have a Window, which causes the WT_PACKET messages not to be passed to the window procedure of the "sfl_wintab_window" window. Workaround in the diff that is attached gets the messages flowing.
2. For some unknown reason SAI calls WMOpen with OutExtX and OutExtY set to 0. This causes AddPacketToContextQueue/ScaleForContext to set the pkX and pkY of the WMPACKET to 0. SAI interprets packets with these values as invalid and does not handle the packet, causing it to be handled as mouse input (and thus no pressure). Hacking false values into these does make SAI register it as pen input, however the input is not properly registered as SAI is reinterpreting the position data as 0 again, presumably due to the actual reason why it set the values in the WMOpen call as 0.
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #58 from Kaetemi kaetemi@gmail.com 2012-03-24 18:35:12 CDT --- 2. (Update) Hack to get positioning working:
Below if(wCategory == WTI_DEFSYSCTX && nIndex == 0) { ... } in context.c add: if (wCategory == WTI_DDCTXS && nIndex == 0) { buf.lcOutExtY = GetSystemMetrics(SM_CYSCREEN); buf.lcOutExtX = GetSystemMetrics(SM_CXSCREEN); }
With this everything works, but when the pen is pressed down and not moving the position randomly shoots around (similar behaviour also occured before in other applications running under wine that did not require these changes to the code).
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #59 from Kaetemi kaetemi@gmail.com 2012-03-24 18:57:21 CDT --- 3. Random pen movement is stopped by not forwarding events where (gMsgPacket.pkOrientation.orAltitude < 0) in wintab.c.
Pressure works fine with above fixes.
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #60 from Dan Kegel dank@kegel.com 2012-03-24 19:08:57 CDT --- Cool - can you attach or submit a patch?
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #61 from Jan Boon kaetemi@gmail.com 2012-03-24 19:54:57 CDT --- Created attachment 39527 --> http://bugs.winehq.org/attachment.cgi?id=39527 Workaround for hWnd with no Window to use parent and ignore negative orAltitude packets
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #62 from Jan Boon kaetemi@gmail.com 2012-03-24 19:55:42 CDT --- Created attachment 39528 --> http://bugs.winehq.org/attachment.cgi?id=39528 Workaround for applications that don't set lcOutExtX and lcOutExtY correctly
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #63 from Jan Boon kaetemi@gmail.com 2012-03-27 14:54:07 CDT --- Additionally, the side button is not behaving correctly compared to when running the application under windows. It's like they're switched, or one is not working or something.
http://bugs.winehq.org/show_bug.cgi?id=11846
RBRat3@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |RBRat3@gmail.com
--- Comment #64 from RBRat3@gmail.com 2012-04-30 03:45:54 CDT --- Well being a slight newb with linux I was able to pull off the workaround, I was only able to get pressure working with wintab setting inside SAI's misc.ini "TabletMouseSimulation = 1". Default option "0" caused the mouse to glitch around (take this lightly im still new at this) my only guess to the cause is SAI & input driver settings are both trying to do absolute positioning with the pen and I havent a clue where the config file is for the wacom to tell it to stop. This isnt directly related to this bug but its an honorable mention, After building from git-wine source wine refuses to fully close SAI out. I usually have to kill it from terminal or system monitor.
http://bugs.winehq.org/show_bug.cgi?id=11846
RBRat3@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|RBRat3@gmail.com |
http://bugs.winehq.org/show_bug.cgi?id=11846
arithosa@mailinator.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |arithosa@mailinator.com
--- Comment #65 from arithosa@mailinator.com 2012-06-03 14:52:39 CDT --- I also got pressure to work using the patches in comment #61 & 62 with wine 1.5.5. I also had to set "TabletMouseSimulation = 1" in misc.ini. Eraser does not seem to work though -- no pressure sensitivity/stabilization and SAI does not switch to eraser tool.
http://bugs.winehq.org/show_bug.cgi?id=11846
Antonia turnip.face@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |turnip.face@gmail.com
--- Comment #66 from Antonia turnip.face@gmail.com 2013-01-11 14:45:13 CST --- I have been looking for alternatives to SAI, as there hasn't been a reliable fix yet, and I found another very similar Japanese painting program <a href="http://www.4paint.net/">4paint</a>.
It must also be run in Wine, but the pressure sensitivity does work with my Wacom Bamboo Pen. Unfortunately the program is entirely in Japanese, and most of the Japanese is garbled within the program.
I am not a developer, but I wonder if it's possible to find a solution to the pressure bug by looking into this program. 4paint appears to be very similar to PaintTool SAI. (You should note that 4paint has pen settings that simulate pressure, even with a mouse, which can be misleading. However I can confirm that the pen pressure worked to control the opacity. I have yet to test the other settings, as I can't read it.)
http://bugs.winehq.org/show_bug.cgi?id=11846
haarp liquitsnake@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |liquitsnake@gmx.net
http://bugs.winehq.org/show_bug.cgi?id=11846
Michael Kamensky stavdev@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stavdev@mail.ru
--- Comment #67 from Michael Kamensky stavdev@mail.ru 2013-04-08 02:23:05 CDT --- Patches in posts 61 and 62 no longer work with the latest versions of Wine (e.g. 1.5.27). They did work back in the 1.5.5 days (just tested by patching 1.5.5 - pressure works fine after setting TabletMouseSimulation to 1), but now despite patching the 1.5.27 sources and setting the proper mode in SAI configuration it still doesn't respond correctly to tablet input (no pressure sensitivity). :(
http://bugs.winehq.org/show_bug.cgi?id=11846
hradec me@hradec.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |me@hradec.com
http://bugs.winehq.org/show_bug.cgi?id=11846
Stephen Badger stephen.badger@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stephen.badger@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11846
tannally@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tannally@yahoo.com
--- Comment #68 from tannally@yahoo.com 2013-06-18 16:30:57 CDT --- Since this bug has been open for 5 years now with no official fix in sight, I asked the nice people at PlayOnLinux to make a Wine build 1.5.5. with these fixes here. I've just tested it and the pen pressure works great (with TabletMouseSimulation to 1). So now there's a Wine build on PlayOnLinux called 1.5.5-SAI with which you can have working pen pressure in SAI. Hope people find this useful, until a proper fix is made for official Wine build :)
http://bugs.winehq.org/show_bug.cgi?id=11846
sevencoloredbox@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sevencoloredbox@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11846
phaethon eriks00@moon.lv changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eriks00@moon.lv
--- Comment #69 from phaethon eriks00@moon.lv --- Can somebody get patch attached to http://bugs.winehq.org/show_bug.cgi?id=18517 and check if it helps?
http://bugs.winehq.org/show_bug.cgi?id=11846
Oliver Larsen Cooldreng15@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Cooldreng15@gmail.com
--- Comment #70 from Oliver Larsen Cooldreng15@gmail.com --- @phaethon I tried with the patch you referred to but it still doesn't work. the only new thing i noticed was this in my terminal: err:wintab32:LoadTablet LoadTabletInfo(0x1a047c) failed
http://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #71 from phaethon eriks00@moon.lv --- Oliver, if you cannot load tablet, then it is not related to this patch. Likely the error would be the same without this patch. This patch is solving the case when you can load tablet, but pressure sensitivity is not working in applications where it should.
https://bugs.winehq.org/show_bug.cgi?id=11846
Storm hewanci@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hewanci@gmail.com
--- Comment #72 from Storm hewanci@gmail.com --- I came here from https://bugs.winehq.org/show_bug.cgi?id=18517 and tried phaethon's patch - to no avil so far. I thought I drop a line here as well, as I'm not sure what is exactly that causes my Phpotoshop to think that there are no pressure enabled devices attached.
https://bugs.winehq.org/show_bug.cgi?id=11846
sghpunk sgh-punk@yandex.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sgh-punk@yandex.ru
https://bugs.winehq.org/show_bug.cgi?id=11846
John Chadwick johnwchadwick@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |johnwchadwick@gmail.com
--- Comment #73 from John Chadwick johnwchadwick@gmail.com --- Created attachment 51391 --> https://bugs.winehq.org/attachment.cgi?id=51391 Hacky pressure patch for Sai
Requres `AvoidOldWacomBug = 1` and `TabletMouseSimulation = 1` inside of Sai. Also, it's a poor hack. Sorry, I am very busy and I just wanted to get this working at all :( Based on hints and code from this thread. I do not like the way I am attaching XI events to the desktop window, but it is apparently the only way I can actually get XI 1 events working on my box (GNOME 3.16, Arch Linux.)
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #74 from John Chadwick johnwchadwick@gmail.com --- Final note: if you are coming here uninitialized and want to get pressure working in Sai on a recent version of Wine, then my previous patch will get you closer. But be aware that you still need patches to make the DRM work. I just patched in all of the wine-staging patches, it contains sufficient emulation of the Hidden and System attributes to work. Note that you will need to `make clean` after applying wine-staging, for the fix for Sai to work.
https://bugs.winehq.org/show_bug.cgi?id=11846
Zakk zakk@rsdio.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zakk@rsdio.com
--- Comment #75 from Zakk zakk@rsdio.com --- I just got pressure sensitivity working with SAI under OSX: some notes for those of you that may end up here via searching for that exact thing:
It seems the DRM issues can be bypassed simply by setting the OS version to Windows 98. I think this may be dependent on which version of SAI you're using, but new(er) ones seem to be just fine this way. My friend had an older version and it didn't seem to work.
You'll need to apply the 'Hacky pressure patch for SAI'.
Even after this pressure sensitivity didn't work. The cause was that the wintab code was not recognizing my input as a tablet. X11 was reporting the name as "pen" which wasn't in the tablet_cursor_whitelist array. Adding the string "pen" there allowed SAI to recognize sensitivity.
Final issue: this may be tablet specific so YMMV. Pressure worked, but if too much pressure was applied SAI would stop drawing. I'm not entirely sure what the issue was, but through some experimentation I noted two things: 1) X11 was reporting the pressure value range as 0 - 65k. 2) SAI would stop drawing somewhere between values of 40k and 50k.
I worked around/fixed this by arbitrarily deciding to report a range of only 0 - 1024 (gSysDevice.NPRESSURE.axMin and axMax) and then storing the value (Axis->max_value - Axis->min_value)/1024 in cursor.pressure_factor (which is a field I added). Then everywhere pkNormalPressure was being setup, I divided the value by cursor->pressure_factor.
The result is a completely functional SAI under OSX, complete with pressure response.
Unfortunately I don't really have a variety of tablets to test with, so I don't know if any of this would be appropriate to package into a general patch. Perhaps making the pressure value mangling controllable via registry settings would be a better approach...
https://bugs.winehq.org/show_bug.cgi?id=11846
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #76 from winetest@luukku.com --- patching file dlls/winex11.drv/wintab.c Hunk #2 FAILED at 866. Hunk #3 FAILED at 895. Hunk #4 FAILED at 944. Hunk #5 succeeded at 964 (offset 4 lines). 3 out of 5 hunks FAILED -- saving rejects to file dlls/winex11.drv/wintab.c.rej
wine 2.0rc4.
Could someone retest with more recent wine or wine-staging? Most likely the patch needs rebase too.
https://bugs.winehq.org/show_bug.cgi?id=11846
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
https://bugs.winehq.org/show_bug.cgi?id=11846
C0rn3j spleefer90@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spleefer90@gmail.com
--- Comment #77 from C0rn3j spleefer90@gmail.com --- Vanilla wine and wine-staging(no patches): Latest SAI won't even launch on wine 3.0rc6-1 (no change since my last report basically https://appdb.winehq.org/objectManager.php?sClass=version&iId=33968 )
on wine-staging it launches, but no pressure sensitivity is present.
tested with Wacom Intuos Pen Small (CTL-480)
I tried setting TabletMouseSimulation to 1(SAI setting) and it still didn't work.
https://bugs.winehq.org/show_bug.cgi?id=11846
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|xixsimplicityxix@gmail.com |wine-bugs@winehq.org
--- Comment #78 from Fabian Maurer dark.shadow4@web.de ---
Latest SAI won't even launch on wine 3.0rc6-1 (no change since my last report basically
Common issue, needs win98.
Since it's been ten years assigned without fix, I'll reset the assignee.
https://bugs.winehq.org/show_bug.cgi?id=11846
Storm Engineer hewanci@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|hewanci@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=11846
ralphagris@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ralphagris@gmail.com
--- Comment #79 from ralphagris@gmail.com --- Now, SAI crashs on Wine 3.2
0009:fixme:htmlhelp:HtmlHelpW HH case HH_INITIALIZE not handled. 002c:fixme:appbar:SHAppBarMessage unknown msg: 4 0028:fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETSTATE): stub 0028:fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETAUTOHIDEBAR, hwnd=(nil), edge=0): stub 0028:fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETAUTOHIDEBAR, hwnd=(nil), edge=2): stub 0028:fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETAUTOHIDEBAR, hwnd=(nil), edge=1): stub 0028:fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETAUTOHIDEBAR, hwnd=(nil), edge=3): stub 002c:fixme:appbar:SHAppBarMessage unknown msg: 1 0009:fixme:htmlhelp:HtmlHelpW HH case HH_UNINITIALIZE not handled.
https://bugs.winehq.org/show_bug.cgi?id=11846
Karl H karlhmlist@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |karlhmlist@gmail.com
--- Comment #80 from Karl H karlhmlist@gmail.com --- Created attachment 60756 --> https://bugs.winehq.org/attachment.cgi?id=60756 wintab log, wine 3.3
SAI (1.2.0 and 1.2.5) loads up fine with wine 3.3. Still no pressure sensitivity on either of my wacom devices(intuos2 XD-1218-U, graphite CTE-430). Pressure sensitivity works in native programs (kirta, azpainter).
Any chance someone can point out the version of wine that "Hacky pressure patch for Sai" is for? I've tried various older builds of wine with "SAI patches" but none have worked as of yet.
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #81 from C0rn3j spleefer90@gmail.com --- Lutris has a build named SAI (1.x WINE), though I haven't been able to get it to work.
If you do get it to work please post step by step instructions, am sure I was just doing something wrong as I don't usually use Lutris.
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #82 from Karl H karlhmlist@gmail.com --- Any chance you could point me to said install script for Lutris? Searching their site/forums yields no results for PTS, nor does google/duck provide anything that hasn't been personally attempted.
I've gone as far as installing older versions of distros (buntu 12-16, Debian 7-9) and while buntu 16 using POL's 1.5.5-SAI build "worked", SAI detected my pen "backwards" (eraser was the "normal end", and the pen tip only worked as mouse and would not function on canvas).
I've also tried various builds of wine, wine-staging, wine-nine and wine-staging-nine (going as far back as wine v0.9.x). None have given me pressure with either libinput or using xf86-input-wacom on either of my devices. Hell, I've even tried installing wacom drivers in the wine prefix (although I have zero clue as to whether wine will actually use those drivers or how to make it do so it beyond me).
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. So if anyone reading this really *needs* SAI that is probably your best bet.
Also wine devs, if this discussion is not appropriate here, please let me know! Sorry in advance if so!
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #83 from C0rn3j spleefer90@gmail.com ---
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.
https://bugs.winehq.org/show_bug.cgi?id=11846
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=11846
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |STAGED CC| |leslie_alistair@hotmail.com Staged patchset| |https://github.com/wine-sta | |ging/wine-staging/tree/mast | |er/patches/wintab32-improve | |ments
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #84 from C0rn3j spleefer90@gmail.com --- 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?
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #85 from C0rn3j spleefer90@gmail.com --- I forgot to add that I was trying to use Wacom Intuos Pen Small (CTL-480).
Pressure sensitivity works fine on Krita with it.
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #86 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Created attachment 61661 --> https://bugs.winehq.org/attachment.cgi?id=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?
https://bugs.winehq.org/show_bug.cgi?id=11846
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset|https://github.com/wine-sta | |ging/wine-staging/tree/mast | |er/patches/wintab32-improve | |ments | Status|STAGED |NEW
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #87 from C0rn3j spleefer90@gmail.com --- Created attachment 61665 --> https://bugs.winehq.org/attachment.cgi?id=61665 +wintab32
Here you go, hopefully I did it correctly.
https://bugs.winehq.org/show_bug.cgi?id=11846
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya@gmail.com
--- Comment #88 from Robert Walker bob.mt.wya@gmail.com --- Created attachment 62973 --> https://bugs.winehq.org/attachment.cgi?id=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
https://bugs.winehq.org/show_bug.cgi?id=11846
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset| |https://github.com/wine-sta | |ging/wine-staging/tree/mast | |er/patches/wintab32-improve | |ments Status|NEW |STAGED
--- Comment #89 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- 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?
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #90 from C0rn3j spleefer90@gmail.com --- (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.
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #91 from C0rn3j spleefer90@gmail.com --- @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.
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #92 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- (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.
https://bugs.winehq.org/show_bug.cgi?id=11846
C0rn3j spleefer90@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #61665|0 |1 is obsolete| |
--- Comment #93 from C0rn3j spleefer90@gmail.com --- Created attachment 63430 --> https://bugs.winehq.org/attachment.cgi?id=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
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #94 from Matteo Bruni matteo.mystral@gmail.com --- (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?)
https://bugs.winehq.org/show_bug.cgi?id=11846
Federico Santamorena federicosantamorena@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |federicosantamorena@gmail.c | |om
--- Comment #95 from Federico Santamorena federicosantamorena@gmail.com --- 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
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #96 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- (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.
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #97 from C0rn3j spleefer90@gmail.com --- 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.
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #98 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- (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?
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #99 from C0rn3j spleefer90@gmail.com --- 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.
https://bugs.winehq.org/show_bug.cgi?id=11846
Sabs sobs@sobs.moe changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sobs@sobs.moe
--- Comment #100 from Sabs sobs@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.
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #101 from Sabs sobs@sobs.moe --- 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.
https://bugs.winehq.org/show_bug.cgi?id=11846
jigglywiggly@3dslice.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jigglywiggly@3dslice.net
--- Comment #102 from jigglywiggly@3dslice.net --- Are any logs needed to get some progress on this? It's very disappointing that tablet support is completely broken.
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #103 from jigglywiggly@3dslice.net --- 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.
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #104 from jigglywiggly@3dslice.net --- 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.
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #105 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- (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?
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #106 from jigglywiggly@3dslice.net --- Created attachment 65084 --> https://bugs.winehq.org/attachment.cgi?id=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
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #107 from Federico Santamorena federicosantamorena@gmail.com --- 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
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #108 from Federico Santamorena federicosantamorena@gmail.com --- 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.
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #109 from John Chadwick johnwchadwick@gmail.com --- 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 needed to ensure the events between two button_events from a single cursor are always routed to the same context even if they leave the bounds of the context.
Regardless, I hope we can resolve this issue soon. It's been a long time coming.
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #110 from jigglywiggly@3dslice.net --- (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 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 needed to ensure the events between two button_events from a single cursor are always routed to the same context even if they leave the bounds of the context.
Regardless, I hope we can resolve this issue soon. It's been a long time coming.
That sounds awesome, really great to see someone looking into this.
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #111 from Federico Santamorena federicosantamorena@gmail.com --- (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 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 needed to ensure the events between two button_events from a single cursor are always routed to the same context even if they leave the bounds of the context.
Regardless, I hope we can resolve this issue soon. It's been a long time coming.
Thank you very much for your work. As you probably read I am the super-maintainer of SAI on Wine.
Now that I know someone is finally looking on this issue I will check SAI for every Wine staging release and update the AppDB.
Already updated for 4.20-staging and I'm happy to announce the S-x stabilizer is starting to work on SAI 2 (not yet on SAI 1), it seems more rough than Windows, but better than nothing.
Let me know if there are some specific edge cases I will need to test.
Keep us updated!
https://bugs.winehq.org/show_bug.cgi?id=11846
shiro shiro@usagi.io changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |shiro@usagi.io
--- Comment #112 from shiro shiro@usagi.io --- 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.
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #113 from John Chadwick john@jchw.io --- 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.)
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #114 from shiro shiro@usagi.io --- 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.
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #115 from amiire layif52204@amail1.com --- 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.)
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #116 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- (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.
https://bugs.winehq.org/show_bug.cgi?id=11846
--- Comment #117 from amiire layif52204@amail1.com --- (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.
https://bugs.winehq.org/show_bug.cgi?id=11846
dough.mean@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dough.mean@gmail.com
--- Comment #118 from dough.mean@gmail.com --- 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.
https://bugs.winehq.org/show_bug.cgi?id=11846
devil.tamachan@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |devil.tamachan@gmail.com
--- Comment #119 from devil.tamachan@gmail.com --- 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#L9...
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);
https://bugs.winehq.org/show_bug.cgi?id=11846
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |geekrodrigo@live.com
--- Comment #120 from Zebediah Figura z.figura12@gmail.com --- *** Bug 50746 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=11846
alastair.trackermail@gmx.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alastair.trackermail@gmx.co | |m
--- Comment #121 from alastair.trackermail@gmx.com --- This issue is still occuring in 6.15 staging
https://bugs.winehq.org/show_bug.cgi?id=11846
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Alias|Sai |
-
wine-bugs＠winehq.org -
WineHQ Bugzilla