Wacom pressure sensitivity lacking under Wine applications.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Wine |
Unknown
|
High
|
|||
wine1.4 (Ubuntu) |
Triaged
|
Low
|
Unassigned |
Bug Description
Having done a great deal of searching and finding alot of "sometimes it works, sometimes it doesn't" information, I found out how to enable wacom tablet pressure sensitivity under Wine on my laptop. The wacom drivers were already preinstalled with Ubuntu Feisty so it already worked in native linux applications such as Gimp.
What almost worked was commenting out the Synaptics reference, as several places instructed, but then I lost some touch pad functionality. What worked instead and is so far allowing me full functionality in both was to edit the xorg.conf file and moving the synaptics touchpad above the wacom pen inputs.
Unless there is some obvious reason not to, it would be nice if they were installed in this order as a default.
I ran:
sudo cp /etc/X11/xorg.conf /etc/X11/
sudo gedit /etc/X11/xorg.conf
and modified the: Section "ServerLayout" from
Section "ServerLayout"
Identifier "Default Layout"
Screen "Default Screen" 0 0
InputDevice "Generic Keyboard"
InputDevice "Configured Mouse"
InputDevice "stylus" "SendCoreEvents"
InputDevice "cursor" "SendCoreEvents"
InputDevice "eraser" "SendCoreEvents"
InputDevice "Synaptics Touchpad"
EndSection
to
Section "ServerLayout"
Identifier "Default Layout"
Screen "Default Screen" 0 0
InputDevice "Generic Keyboard"
InputDevice "Configured Mouse"
InputDevice "Synaptics Touchpad"
InputDevice "stylus" "SendCoreEvents"
InputDevice "cursor" "SendCoreEvents"
InputDevice "eraser" "SendCoreEvents"
EndSection
Till Hartmann (tillux) wrote : | #1 |
Vadim (zedzzz) wrote : | #2 |
in WINE 0.9.54 Wacom Bamboo is still recognizes as a mouse.
In Wine Bugzilla #11846, Todor Eemreorov (blurymind-gmail) wrote : | #3 |
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://
another application that is a freeware and a fine substitute for painter is
http://
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.
In Wine Bugzilla #11846, Dan Kegel (dank) wrote : | #4 |
What tablet do you have?
Can you give us a +wintab32 log?
In Wine Bugzilla #11846, Todor Eemreorov (blurymind-gmail) wrote : | #5 |
(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:
fixme:mountmgr:
fixme:mountmgr:
fixme:mountmgr:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:imm:
fixme:imm:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:imm:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:shell:
fixme:shell:
fixme:htmlhelp:
err:ole:
theo@theo-
=======
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:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
fixme:wintab32:
In Wine Bugzilla #11846, Todor Eemreorov (blurymind-gmail) wrote : | #6 |
same version of wine and tablet model, tested on freeware application artweaver 0.4.9:
wine: Call from 0x7ee4e4f0 to unimplemented function ntoskrnl.
wine: Call from 0x7ee4e4f0 to unimplemented function ntoskrnl.
fixme:ntdll:
fixme:wintab32:
fixme:wintab32:
only wintab messages,right?
In Wine Bugzilla #11846, Dan Kegel (dank) wrote : | #7 |
That's not quite what we wanted. Can you rerun with
WINEDEBUG=
and attach log.txt (do not put inline! Click 'Add an attachment' above.)
Thanks.
In Wine Bugzilla #11846, Dan Kegel (dank) wrote : | #8 |
It looks like SAI has a trial mode and can be downloaded from
http://
In Wine Bugzilla #11846, Todor Eemreorov (blurymind-gmail) wrote : | #9 |
Created an attachment (id=11411)
sai 1.0.1 wintab32 log file
WINEDEBUG=
wacom graphire 4 xl, sai 1.0.1, wine 0.9.57
feisty fawn
In Wine Bugzilla #11846, Todor Eemreorov (blurymind-gmail) wrote : | #10 |
(In reply to comment #5)
> It looks like SAI has a trial mode and can be downloaded from
> http://
>
yes of course,i know about the trial, i am even thinking of buying Sai if tablet emulation works with wine some day
In Wine Bugzilla #11846, Dan Kegel (dank) wrote : | #11 |
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.)
In Wine Bugzilla #11846, Dan Kegel (dank) wrote : | #12 |
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.)
In Wine Bugzilla #11846, Todor Eemreorov (blurymind-gmail) wrote : | #13 |
Created an attachment (id=11427)
xorg.conf file- tablet settings- photoshop cs2 and artrage 2.5 work,but sai and artweaver dont work
my xorg.conf file under ubuntu. I can confirm that tablet pressure works in photoshop cs2 and in artrage 2.5 (latest) always- wine 0.9.57
In Wine Bugzilla #11846, Todor Eemreorov (blurymind-gmail) wrote : | #14 |
(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://
it does not have any hacks on its binaries (exe wasnt edited by a hex editor) ,only text files were edited.
In Wine Bugzilla #11846, Todor Eemreorov (blurymind-gmail) wrote : | #15 |
(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.
In Wine Bugzilla #11846, Dan Kegel (dank) wrote : | #16 |
Thanks for the info. We'll try SAI here.
In Wine Bugzilla #11846, Lei Zhang (thestig-google) wrote : | #17 |
please leave the version field alone.
In Wine Bugzilla #11846, Todor Eemreorov (blurymind-gmail) wrote : | #18 |
(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.
In Wine Bugzilla #11846, DOPing (harddoping) wrote : | #19 |
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.
In Wine Bugzilla #11846, Dan Kegel (dank) wrote : | #20 |
Marking confirmed since 2nd user sees problem.
Does
http://
help, by any chance?
In Wine Bugzilla #11846, DOPing (harddoping) wrote : | #21 |
(In reply to comment #17)
> Does
> http://
> 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.
In Wine Bugzilla #11846, Xixsimplicityxix (xixsimplicityxix) wrote : | #22 |
Created an attachment (id=12026)
Implementes WTSetA WTSetW for wintab32
I've yet to test this out on my ubuntu tablet machine but it builds ok.
If anyone is up for testing go for it. Should provide a minimum functioning of WTSetA and WTSetW.
In Wine Bugzilla #11846, Xixsimplicityxix (xixsimplicityxix) wrote : | #23 |
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.
In Wine Bugzilla #11846, Xixsimplicityxix (xixsimplicityxix) wrote : | #24 |
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.
Scott Ritchie (scottritchie) wrote : | #25 |
Please retest on the latest Wine in Ubuntu Hardy. Thanks.
Changed in wine: | |
status: | New → Incomplete |
In Wine Bugzilla #11846, Xixsimplicityxix (xixsimplicityxix) wrote : | #26 |
WTSetA/W committed: http://
In Wine Bugzilla #11846, Xixsimplicityxix (xixsimplicityxix) wrote : | #27 |
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://
In Wine Bugzilla #11846, Xixsimplicityxix (xixsimplicityxix) wrote : | #28 |
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_
AttachEventQueu
Maybe more tonight. hrmm
In Wine Bugzilla #11846, Todor Eemreorov (blurymind-gmail) wrote : | #29 |
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?
In Wine Bugzilla #11846, Xixsimplicityxix (xixsimplicityxix) wrote : | #30 |
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 AttachEventQueu
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 (!AttachEventQu
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
azathothgr (azathothgr) wrote : | #31 |
I can confirm on latest hardy (rc) with wine 0.9.59 from the repos, and an intuos 6x8
Pressure works under gimp, but not under wine in Artrage starter or full.
Stylus is properly recognized and works in absolute mode, but no pressure or tilt.
azathothgr (azathothgr) wrote : | #32 |
I've got it to work :
First, in dlls/winex11.
Code:
if (!axis_
I changed this to :
Code:
if (!axis_
It seems it checks for each axis anyway after that, so it's redundant.
Most importantly, however, I changed every instance of IsXExtensionDevice in that file with IsXExtensionPoi
In Wine Bugzilla #11846, Xixsimplicityxix (xixsimplicityxix) wrote : | #33 |
Created an attachment (id=12574)
Search harder for an x11 window when given an hwnd
Coming a bit closer now. I tried my best to get this in before 1.0 but I don't think we're gonna make it. Good news is that the problem is related to child window messaging. Before we simply dropped the packets if the root window wasnt used as the wintab context window. I have a patch that grabs either the x11 parent window OR the root window ensuring that we always ahve a source for those precious x11 tablet events.
The next step is to get the messages we generate from those events back to the child windows themselves. My 2nd patch does that, though I'm not sure if it is the proper way. It does work though.
It still doesn't make pressure work in sai though amazingly enough. The logs now show the tablet pressure events streaming to the child window and the corresponding context but still not a drop of pressure from sai. Puzzling... but closer.
Not going to be around for a bit now with it being learning crunch time around here so
In Wine Bugzilla #11846, Xixsimplicityxix (xixsimplicityxix) wrote : | #34 |
Created an attachment (id=12575)
Support wintab messaging for child windows
In Wine Bugzilla #11846, Todor Eemreorov (blurymind-gmail) wrote : | #35 |
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://
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 TabletMouseSimu
another (solved) problem like yours -> http://
================
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://
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..
gusdefrog (gusdefrog) wrote : | #36 |
Since upgrading to Hardy Heron I can't get my wacom graphire tablet to have pressure sensitivity, eraser, or side buttons to work under Wine no matter what I try. I've tried the same xorg.conf I've tried the default Wine distribution and the updated 1.x distribution. I've downloaded and installed from source the 1.x distribution. Currently I'm running version 1.0-rc1
This always comes up in the terminal window if I start any of my windows graphics programs from the command line when I'm using the tablet to navigate.
fixme:wintab32:
Here is my bug output for wintab:
frog@Frogpad:
wine: Unhandled page fault on write access to 0x00463000 at address 0x7bc44a1f (thread 001a), starting debugger...
Unhandled exception: page fault on write access to 0x00463000 in 32-bit code (0x7bc44a1f).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:7bc44a1f ESP:7ec1e910 EBP:7ec1e938 EFLAGS:00010202( - 00 - -RI1)
EAX:00000ffe EBX:7bc88444 ECX:004701dc EDX:00462000
ESI:00000132 EDI:00050000
Stack dump:
0x7ec1e910: 7ec1e9cc 0046ff70 7ec1e938 7b89be9a
0x7ec1e920: ffffffff 00462000 00000005 7eea48f4
0x7ec1e930: 0046ff70 00462000 7ec1e9e8 7eea2f0e
0x7ec1e940: 00462000 00000132 0046ff78 00050000
0x7ec1e950: 00110ef0 7ec1e9d4 00000000 00000130
0x7ec1e960: 00000026 7ec1e9cc 7ec1e9c4 f7dcfec9
Backtrace:
=>1 0x7bc44a1f LdrProcessReloc
2 0x7eea2f0e ServiceMain+
3 0x7ee4c529 service_
4 0x7bc6bbbe call_thread_
5 0x7bc6c252 call_thread_
6 0x7bc6c482 in ntdll (+0x5c482) (0x7ec1f3d8)
7 0xf7dca4fb start_thread+0xcb() in libpthread.so.0 (0x7ec1f4c8)
0x7bc44a1f LdrProcessReloc
2061 *(int *)((char *)page + offset) += delta;
Modules:
Module Address Debug info Name (29 modules)
PE 450000- 472000 Deferred sshdrv65.sys
ELF 7b800000-7b92d000 Deferred kernel32<elf>
\-PE 7b820000-7b92d000 \ kernel32
ELF 7bc00000-7bca4000 Dwarf ntdll<elf>
\-PE 7bc10000-7bca4000 \ ntdll
ELF 7bf00000-7bf03000 Deferred <wine-loader>
ELF 7eaa6000-7eb0f000 Deferred msvcrt<elf>
\-PE 7eac0000-7eb0f000 \ msvcrt
ELF 7ec20000-7ec33000 Deferred libresolv.so.2
ELF 7ec49000-7ec67000 Deferred iphlpapi<elf>
\-PE 7ec50000-7ec67000 \ iphlpapi
ELF 7ec67000-7ecc8000 Deferred rpcrt4<elf>
\-PE 7ec70000-7ecc8000 \ rpcrt4
ELF...
In Wine Bugzilla #11846, gusdefrog (gusdefrog) wrote : | #37 |
(In reply to comment #28)
> Created an attachment (id=12575) [details]
> Support wintab messaging for child windows
>
I could not apply this patch, using a different version of wine than it was created for I believe, or maybe just not understanding well enough how to apply it. I usually work through the package managers for software. However I do think that it is a child window problem. All of my windows painting programs that hold another window inside themselves as a canvas do not have pressure sensitivity under wine. Windows drawing programs that have the canvas as a part of the program window instead such as ArtRage 2.5 have full pressure sensitivity for me. I have tested out the default wine installation and the 1.0-rc3, Pixia, OpenCanvas, ArtRage and Corel Photopaint. I had not thought to look for that simaliarity before reading this bug.
I used to have pressure sensitivity in Pixia and OpenCanvas 1.1 in Ubuntu Feisty Fawn (when that installation package was new), but I hadn't been running any updates, and I had done some tweaking with the wine installation, I think I just compiled it from source, but I have forgotten. (Compiling (./configure, make, etc.) vs. package installation doesn't change the behavior of the current versions.) Unfortunately I upgraded to Hardy Heron, and broke it. I then assumed that the problem was with Ubuntu, however, I believe now that this bug is on a closer track with the problem.
Bug #151448 is one I created back when I found the last key that I believed fixed the problem when I was running Feisty. I think it should be closed or linked to this bug. I appologize for my poor bug ettiquette, I'm learning, but slowly.
In Wine Bugzilla #11846, Xixsimplicityxix (xixsimplicityxix) wrote : | #38 |
(In reply to comment #30)
> (In reply to comment #28)
> > Created an attachment (id=12575) [details] [details]
> > Support wintab messaging for child windows
> >
>
> I could not apply this patch, using a different version of wine than it was
> created for I believe, or maybe just not understanding well enough how to apply
The patch needs to be updated.
> sensitivity for me. I have tested out the default wine installation and the
> 1.0-rc3, Pixia, OpenCanvas, ArtRage and Corel Photopaint. I had not thought to
> look for that simaliarity before reading this bug.
>
> I used to have pressure sensitivity in Pixia and OpenCanvas 1.1 in Ubuntu
I've never tried pixia but I know for certain that pressure sensitivity works for openCanvas 4.5e with wacom tablets. If you have a non wacom tablet see bugs 11699 or 12005.
> make, etc.) vs. package installation doesn't change the behavior of the current
> versions.) Unfortunately I upgraded to Hardy Heron, and broke it. I then
Broke what, your compiler? (you need to reinstall the dev packages, see the wiki) or Wine(explain in detail about what's broken).
> Bug #151448 is one I created back when I found the last key that I believed
> fixed the problem when I was running Feisty. I think it should be closed or
> linked to this bug. I appologize for my poor bug ettiquette, I'm learning, but
> slowly.
>
The following information would be great:
Tablet model:
OS version:
Program Name and Version:
Problem and steps to demonstrate the problem:
In Wine Bugzilla #11846, Todor Eemreorov (blurymind-gmail) wrote : | #39 |
(In reply to comment #30)
> (In reply to comment #28)
> > Created an attachment (id=12575) [details] [details]
> > Support wintab messaging for child windows
> >
>
> I could not apply this patch, using a different version of wine than it was
> created for I believe, or maybe just not understanding well enough how to apply
> it. I usually work through the package managers for software. However I do
> think that it is a child window problem. All of my windows painting programs
> that hold another window inside themselves as a canvas do not have pressure
> sensitivity under wine. Windows drawing programs that have the canvas as a
> part of the program window instead such as ArtRage 2.5 have full pressure
> sensitivity for me. I have tested out the default wine installation and the
> 1.0-rc3, Pixia, OpenCanvas, ArtRage and Corel Photopaint. I had not thought to
> look for that simaliarity before reading this bug.
>
> I used to have pressure sensitivity in Pixia and OpenCanvas 1.1 in Ubuntu
> Feisty Fawn (when that installation package was new), but I hadn't been running
> any updates, and I had done some tweaking with the wine installation, I think I
> just compiled it from source, but I have forgotten. (Compiling (./configure,
> make, etc.) vs. package installation doesn't change the behavior of the current
> versions.) Unfortunately I upgraded to Hardy Heron, and broke it. I then
> assumed that the problem was with Ubuntu, however, I believe now that this bug
> is on a closer track with the problem.
>
> Bug #151448 is one I created back when I found the last key that I believed
> fixed the problem when I was running Feisty. I think it should be closed or
> linked to this bug. I appologize for my poor bug ettiquette, I'm learning, but
> slowly.
>
Sai's pressure sensitivity problem is still not resolved...Your report fits another bug report of wine- the one where when you upgrade to hardy heron,tablet pressure sensitivity gets borked. I had a simular problem (if not exactly the same) with wine on vector linux 5.9., which is the same as slackware 12.* (curent). Tablet pressure sensitivity in wine did not work.But somebody released a patch for an older version of wine that has it fixed on both slackware and the latest ubuntu:
http://
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.
In Wine Bugzilla #11846, gusdefrog (gusdefrog) wrote : | #40 |
(In reply to comment #31)
> (In reply to comment #30)
> > (In reply to comment #28)
> > > Created an attachment (id=12575) [details] [details] [details]
> > > Support wintab messaging for child windows
> > >
> >
> > I could not apply this patch, using a different version of wine than it was
> > created for I believe, or maybe just not understanding well enough how to apply
>
> The patch needs to be updated.
>
> > sensitivity for me. I have tested out the default wine installation and the
> > 1.0-rc3, Pixia, OpenCanvas, ArtRage and Corel Photopaint. I had not thought to
> > look for that simaliarity before reading this bug.
> >
> > I used to have pressure sensitivity in Pixia and OpenCanvas 1.1 in Ubuntu
>
> I've never tried pixia but I know for certain that pressure sensitivity works
> for openCanvas 4.5e with wacom tablets. If you have a non wacom tablet see
> bugs 11699 or 12005.
I have a Wacom Graphire and a Wacom Intuous 3. I only have one of them pluged into a machine at a time, but have tried both of them with each version.
>
>
> > make, etc.) vs. package installation doesn't change the behavior of the current
> > versions.) Unfortunately I upgraded to Hardy Heron, and broke it. I then
>
> Broke what, your compiler? (you need to reinstall the dev packages, see the
> wiki) or Wine(explain in detail about what's broken).
>
Broke the tablet pressure sensitivity. I had it going in Feisty with Wine (but uncertain what version, sorry.)
>
> > Bug #151448 is one I created back when I found the last key that I believed
> > fixed the problem when I was running Feisty. I think it should be closed or
> > linked to this bug. I appologize for my poor bug ettiquette, I'm learning, but
> > slowly.
> >
>
> The following information would be great:
>
Tablet model: Wacom Graphire and Wacom Intuos 3
OS version: Hardy Heron
Program Name and Version: Does not work in: Pixia 3.0, Pixia 3.5 or the new APixia (but this is not a stable release yet), Corel Photopaint 6
Draws upside down and and with scribbles and errors in: Open Canvas 1.1
Works in: Artrage 2.5 trial.
Problem and steps to demonstrate the problem:
Tablet behaves like mouse in many, but not all graphic painting programs under wine. Installed Hardy Heron (On one computer, clean install, on the other upgrade. Wine automatically upgraded itself to the latest 9.59, tablet pressure stopped working in several programs. Haven't got it to work at all on the clean install for those programs. Tried Wine 1.0rc3. Same. Uninstalled Wine using "Mark for Complete Removal". Compiled from source. Same. Tried swapping tablets between computers and reinstalling Wacom drivers. On the upgraded system tried compiling the new 8.0 wacom drivers. This changed the default behavior of the tablets to relative navigation, and modified the strange output of Open Canvas 1.1, but did not fix it.
Both tablets work normally with native Linux painting and drawing applications in all installed versions.
Changed in wine: | |
importance: | Undecided → Low |
status: | Incomplete → Confirmed |
Changed in wine: | |
status: | Unknown → Confirmed |
Changed in wine: | |
status: | Confirmed → Triaged |
Changed in wine: | |
status: | Confirmed → In Progress |
Changed in wine (Ubuntu): | |
status: | Triaged → Incomplete |
Changed in wine: | |
importance: | Unknown → High |
affects: | wine (Ubuntu) → wine1.4 (Ubuntu) |
Changed in wine1.4 (Ubuntu): | |
status: | Incomplete → Triaged |
Changed in wine: | |
status: | In Progress → Unknown |
58 comments hidden Loading more comments | view all 138 comments |
In Wine Bugzilla #11846, Martin (c0rn3j) wrote : | #99 |
Since this was just marked as staged, I compiled wine-staging from git (AUR package wine-staging-git - wine-staging-git 3.10.r14.
Set up latest SAI in a fresh wine prefix - https:/
and neither with the default SAI config or with `AvoidOldWacomBug = 1` and `TabletMouseSim
Am I missing something?
In Wine Bugzilla #11846, Martin (c0rn3j) wrote : | #100 |
I forgot to add that I was trying to use Wacom Intuos Pen Small (CTL-480).
Pressure sensitivity works fine on Krita with it.
In Wine Bugzilla #11846, Alistair Leslie-Hughes (alesliehughes) wrote : | #101 |
Created attachment 61661
+wintab32
Thanks for testing.
I've attached a log for wintab32 for reference.
At a guess, its one of these that needs to be handled correctly.
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
0034:fixme:
Can you please attached a +wintab32 log for comparison?
In Wine Bugzilla #11846, Martin (c0rn3j) wrote : | #102 |
Created attachment 61665
+wintab32
Here you go, hopefully I did it correctly.
Changed in wine: | |
status: | Unknown → Confirmed |
In Wine Bugzilla #11846, Bob-mt-wya (bob-mt-wya) wrote : | #103 |
Created attachment 62973
wine-vanilla-
Patch (1.8 version) rebased for Wine 4.0-rc1.
This support was requested by a forum member: https:/
In Wine Bugzilla #11846, Alistair Leslie-Hughes (alesliehughes) wrote : | #104 |
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?
In Wine Bugzilla #11846, Martin (c0rn3j) wrote : | #105 |
(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:/
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 TabletMouseSimu
Changed in wine: | |
status: | Confirmed → Unknown |
In Wine Bugzilla #11846, Martin (c0rn3j) wrote : | #106 |
@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.
In Wine Bugzilla #11846, Alistair Leslie-Hughes (alesliehughes) wrote : | #107 |
(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.
In Wine Bugzilla #11846, Martin (c0rn3j) wrote : | #108 |
Created attachment 63430
staging 4.0 PTH-660 +wintab32
Wacom Intuos Pro M (PTH-660)
I drew 4 'lines' and made each cut off due to overpressure.
+wintab32, Wine staging 4.0
In Wine Bugzilla #11846, Matteo-mystral (matteo-mystral) wrote : | #109 |
(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?)
In Wine Bugzilla #11846, Federicosantamorena (federicosantamorena) wrote : | #110 |
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:/
In Wine Bugzilla #11846, Alistair Leslie-Hughes (alesliehughes) wrote : | #111 |
(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.
In Wine Bugzilla #11846, Martin (c0rn3j) wrote : | #112 |
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.
In Wine Bugzilla #11846, Alistair Leslie-Hughes (alesliehughes) wrote : | #113 |
(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/
WINETEST_
What is the pressure value that is displayed when pressure is applied?
In Wine Bugzilla #11846, Martin (c0rn3j) wrote : | #114 |
Doesn't look like that works for pure git wine
c0rn3j@Luxuria ‹ master › : /tmp/wine/
[0] % WINETEST_
make: *** No rule to make target 'test'. Stop.
c0rn3j@Luxuria ‹ master › : /tmp/wine/
[2] % cd ..
c0rn3j@Luxuria ‹ master › : /tmp/wine/
[0] % WINETEST_
make: *** No rule to make target 'test'. Stop.
Sabs (sabslikesobs) wrote : | #115 |
- logs-for-151448.zip Edit (25.7 KiB, application/zip)
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-
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_
WINEDEBUG=+wintab32 WINETEST_
Some binary appears to run and quit without awaiting input, a different result from executing the test manually with:
WINETEST_
...which still isn't interactive, but does print some output. I've attached logs of both. Wine is version wine-4.
I'm using xsetwacom's automatic Wacom configuration for my Wacom Bamboo Fun CTE-650. Here's the output of xsetwacom --list:
Wacom BambooFun 6x8 Pad pad id: 11 type: PAD
Wacom BambooFun 6x8 Pen stylus id: 12 type: STYLUS
Wacom BambooFun 6x8 Pen eraser id: 26 type: ERASER
Wacom BambooFun 6x8 Pen cursor id: 27 type: CURSOR
I also included a log of "xinput list-props" for those devices if it helps.
I suspect that c0rn3j and I have a similar problem: Paint Tool SAI and Krita (windows) both output no tablet activity. wintab32 appears to find my tablet (and its 4 devices) just fine but only reports window changes afterwards -- no input activity at all while the tablet is in use. It acts exactly like a mouse does for both the STYLUS and ERASER pressures, and SAI doesn't seem to notice the difference between the two (usually the eraser is treated as a different tool). My attachment includes a +wintab32 log of SAI where I opened the program, drew a few lines, flicked the mouse in and out of the window to generate the window events, and then closed it.
Native linux Krita does have a working pressure curve. I checked with "xsetwacom set {id} ToolDebugLevel 6", and both the STYLUS and ERASER send pressure events to Arch's /var/log/Xorg.0.log that aren't reflected in wintab32's debug logs. The events are present in the X logs while wine is running. I've included a log of a few stylus and eraser clicks with ToolDebugLevel set to 12 (the max) in case it helps (I can see pressure changing on the z axis).
Is it possible that there's an incompatibility with X's perceived order of my devices and with Wine's? It looks like Wine loads each of the 4 devices into their own stream, so (although I don't r...
In Wine Bugzilla #11846, Sobs (sobs) wrote : | #116 |
Created attachment 64583
Logs for Sabs's comment
c0rn3j, you probably need to run /tmp/wine/configure and build dependencies before running the test.
I'm testing based on Arch linux's AUR wine-staging-git package. I'm not familiar with building WINE, so my workflow has been coupled with trizen, an AUR wrapper:
1. mkdir -p /tmp/wine; cd /tmp/wine
2. trizen -Gl wine-staging-git # download the package locally
3. vim wine-staging-
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_
WINEDEBUG=+wintab32 WINETEST_
Some binary appears to run and quit without awaiting input, a different result from executing the test manually with:
WINETEST_
...which still isn't interactive, but does print some output. I've attached logs of both. Wine is version wine-4.
I'm using xsetwacom's automatic Wacom configuration for my Wacom Bamboo Fun CTE-650. Here's the output of xsetwacom --list:
Wacom BambooFun 6x8 Pad pad id: 11 type: PAD
Wacom BambooFun 6x8 Pen stylus id: 12 type: STYLUS
Wacom BambooFun 6x8 Pen eraser id: 26 type: ERASER
Wacom BambooFun 6x8 Pen cursor id: 27 type: CURSOR
I also included a log of "xinput list-props" for those devices if it helps.
I suspect that c0rn3j and I have a similar problem: Paint Tool SAI and Krita (windows) both output no tablet activity. wintab32 appears to find my tablet (and its 4 devices) just fine but only reports window changes afterwards -- no input activity at all while the tablet is in use. It acts exactly like a mouse does for both the STYLUS and ERASER pressures, and SAI doesn't seem to notice the difference between the two (usually the eraser is treated as a different tool). My attachment includes a +wintab32 log of SAI where I opened the program, drew a few lines, flicked the mouse in and out of the window to generate the window events, and then closed it.
Native linux Krita does have a working pressure curve. I checked with "xsetwacom set {id} ToolDebugLevel 6", and both the STYLUS and ERASER send pressure events to Arch's /var/log/Xorg.0.log that aren't reflected in wintab32's debug logs. The events are present in the X logs while wine is running. I've included a log of a few stylus and eraser clicks with ToolDebugLevel set to 12 (the max) in case it helps (I can see pressure changing on the z axis).
Is it possible that there's an incompatibility with X's perceived order of my devices and with Wine's? It looks like Wine loads each of the 4 devices into their own stream, so (although I don't really under...
In Wine Bugzilla #11846, Sobs (sobs) wrote : | #117 |
A little more testing with DEBUGLEVEL=
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.
In Wine Bugzilla #11846, oh (jigglywiggly) wrote : | #118 |
Are any logs needed to get some progress on this? It's very disappointing that tablet support is completely broken.
In Wine Bugzilla #11846, oh (jigglywiggly) wrote : | #119 |
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.
In Wine Bugzilla #11846, oh (jigglywiggly) wrote : | #120 |
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.
In Wine Bugzilla #11846, Alistair Leslie-Hughes (alesliehughes) wrote : | #121 |
(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?
In Wine Bugzilla #11846, oh (jigglywiggly) wrote : | #122 |
Created attachment 65084
wintab32 logs wine 4.14
I am just using AUR to compile Wine's git. I take back the pressure sensitivity range, it does seem to use the whole range. I was mistaken as it is hard to tell with the very low sampling rate.
The log file is very large at 80 megabytes for only a few seconds of testing. Since most of it is redundant, I uploaded it as a zip so it would fit.
wintab32-4.14.zip
In Wine Bugzilla #11846, Federicosantamorena (federicosantamorena) wrote : | #123 |
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
In Wine Bugzilla #11846, Federicosantamorena (federicosantamorena) wrote : | #124 |
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.
In Wine Bugzilla #11846, John Chadwick (johnwchadwick) wrote : | #125 |
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:/
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, XSelectExtensio
The Wintab code should probably register for events in X11DRV_
I suspect all of the information we need to determine if a context overlaps is the HWND. So, we already have most of the necessary information. However, we do need a way to propagate the WTOverlap calls back to winex11.drv, which will probably need to come in the form of new graphics driver functions. In the meantime, it's probably not a big deal to ignore WTOverlap since it probably only has an impact when working between different applications.
It's probably going to be valuable to also investigate the behaviors and interactions between various techniques in Windows. For example, what happens when you drag the tablet outside the window? It may not be sufficient to simply route events based on what the top most context matching the geometry is; some additional heuristics may be n...
In Wine Bugzilla #11846, oh (jigglywiggly) wrote : | #126 |
(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:/
> (https:/
> 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, XSelectExtensio
> called on the X11 window of hOwner (using X11DRV_
> 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 XSelectExtensio
> to figure out what context it should send the events to.
>
> The Wintab code should probably register for events in
> X11DRV_
> X11DRV_
> crucially, the way the event handlers work needs to change. Instead of
> sending the message directly to the hWnd that the event is matched with, the
> hWnd should be ignored, and we should iterate through a stack of windows,
> finding the first one that overlaps with the event coordinates. Then,
> WTOverlap should be implemented to manipulate this stack.
>
> I suspect all of the information we need to determine if a context overlaps
> is the HWND. So, we already have most of the necessary information. However,
> we do need a way to propagate the WTOverlap calls back to winex11.drv, which
> will probably need to come in the form of new graphics driver functions. In
> the meantime, it's probably not a big deal to ignore WTOverlap since it
> probably only has an impact when working between different applications.
>
> It's probably going to be valuable to also investigate the behaviors and
> interactions between various techniques in Windows. For example, what
> happens when you drag the tablet outside the wind...
In Wine Bugzilla #11846, Federicosantamorena (federicosantamorena) wrote : | #127 |
(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:/
> (https:/
> 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, XSelectExtensio
> called on the X11 window of hOwner (using X11DRV_
> 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 XSelectExtensio
> to figure out what context it should send the events to.
>
> The Wintab code should probably register for events in
> X11DRV_
> X11DRV_
> crucially, the way the event handlers work needs to change. Instead of
> sending the message directly to the hWnd that the event is matched with, the
> hWnd should be ignored, and we should iterate through a stack of windows,
> finding the first one that overlaps with the event coordinates. Then,
> WTOverlap should be implemented to manipulate this stack.
>
> I suspect all of the information we need to determine if a context overlaps
> is the HWND. So, we already have most of the necessary information. However,
> we do need a way to propagate the WTOverlap calls back to winex11.drv, which
> will probably need to come in the form of new graphics driver functions. In
> the meantime, it's probably not a big deal to ignore WTOverlap since it
> probably only has an impact when working between different applications.
>
> It's probably going to be valuable to also investigate the behaviors and
> interactions between various techniques in Windows. For example, what
> happens when you drag the tablet outside the wind...
In Wine Bugzilla #11846, Shiro-3 (shiro-3) wrote : | #128 |
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:/
The log from the demo including the debug wintab output is attached, hope this helps in any way.
In Wine Bugzilla #11846, D-john-j (d-john-j) wrote : | #129 |
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 (ddec23013e39b5
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.)
In Wine Bugzilla #11846, Shiro-3 (shiro-3) wrote : | #130 |
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.
In Wine Bugzilla #11846, Layif52204 (layif52204) wrote : | #131 |
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:
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:/
A download for Clip Studio Paint (v1.9.5) can be found at:
https:/
(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.)
In Wine Bugzilla #11846, Alistair Leslie-Hughes (alesliehughes) wrote : | #132 |
(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:
> orAltitude detected" for each motion event.
>
Please file a new bug report, against wine-staging as the patch isn't upstream.
In Wine Bugzilla #11846, Layif52204 (layif52204) wrote : | #133 |
(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:
> > 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.
In Wine Bugzilla #11846, Dough-mean (dough-mean) wrote : | #134 |
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.
In Wine Bugzilla #11846, Devil-tamachan (devil-tamachan) wrote : | #135 |
pkButtons is always 2.
https:/
> 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:/
wintab.c - motion_event()
gMsgPacket.
- gMsgPacket.
+ gMsgPacket.
gMsgPacket.
In Wine Bugzilla #11846, Ztirfe Elgnid (z-figura12) wrote : | #136 |
*** Bug 50746 has been marked as a duplicate of this bug. ***
In Wine Bugzilla #11846, Alastair-trackermail (alastair-trackermail) wrote : | #137 |
This issue is still occuring in 6.15 staging
In Wine Bugzilla #11846, monte (monte3) wrote : | #138 |
I've been testing extensively for couple of days.
Wine 9.8 vanilla - SAI2 works out of the box, Photoshop CS4, 2017, 2020 tested and are broken. Pen pressure seems to be "working" but in a broken way, it registers pen press and the release events, and draws a straight line between this two points. It is only updated after pen release. Pressure is also only accounted at the time of pen down event. So basically unusable. The behavior changes if you unstack the canvas window from tabs line. Then pen works just like a simple mouse cursor, without lag but without any pressure control either. It seems like wintab is not used in this configuration, once you stack canvas back everything works as previously.
Wine 9.8 staging (proton, tkg) - wintab seems to be broken, in SAI2 can't draw with a pen, in Photoshop behaves as a simple mouse cursor. After applying staging patches one by one, I've found the culprit - https:/
I'd like to be able to use pen input in photoshop to the full extend, it seems so close, just find a way to make photoshop read motion events, and not only the button ones.
I am very upset with wine, as the announce for wine 0.9.52 reads: "Improved graphics tablet support.".
I updated wine, tried out different applications, but none of them is even recognizing the tablet, it acts like a normal mouse.
Maybe the "Improved support" did not mean the pressure to work, but that is what I have been hoping for, since the tablet already worked before version 0.9.52.