[Bug 58463] New: Clip Studio Paint 4.0 Pen proximity not handled correctly - brushes continuing drawing when pen is hovering
http://bugs.winehq.org/show_bug.cgi?id=58463
Bug ID: 58463 Summary: Clip Studio Paint 4.0 Pen proximity not handled correctly - brushes continuing drawing when pen is hovering Product: Wine Version: 10.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wintab32 Assignee: wine-bugs@winehq.org Reporter: gagen85826@binafex.com Distribution: ---
Created attachment 78917 --> http://bugs.winehq.org/attachment.cgi?id=78917 csp pen pressure log
Using the default pen pressure out of the box with a tablet, when hovering my pen in Clip Studio Paint under Wine 10.11 (Arch, staging), the app will register lingering strokes and basically fails to recognize that the pen is not in contact with the screen.
Steps to Reproduce (will need a tablet for this):
Open CSP in a clean Wine prefix
Draw with any pen, lift the pen but hover pen closely over canvas
Observe how strokes continue drawing
I've already verified through OpenTabletDriver that it registers the pen pressure as 0 when I lift my pen from the screen. I would try to set CSP to Tablet PC but its greyed out for me and I'm sure that Wintab is recommened for wine programs.
Attached is a log, note the comment within the file.
http://bugs.winehq.org/show_bug.cgi?id=58463
gagen85826@binafex.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gagen85826@binafex.com
http://bugs.winehq.org/show_bug.cgi?id=58463
--- Comment #1 from gagen85826@binafex.com --- Also, forget to add but I did further testing disabling Windows Ink via the registry helped somewhat.
Testing on a pen with pen pressure off because thats when the issue is the most egregious, sometimes the stroke would stop after I lift my pen from the screen and other times it would continue drawing until I hovered the pen far away enough that the tablet no longer picked up the pen hover.
Before, when I moved my pen close enough again, it would just keep drawing so there's that.
http://bugs.winehq.org/show_bug.cgi?id=58463
quela gagen85826@binafex.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |ArchLinux
http://bugs.winehq.org/show_bug.cgi?id=58463
quela gagen85826@binafex.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|wintab32 |-unknown
http://bugs.winehq.org/show_bug.cgi?id=58463
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware
http://bugs.winehq.org/show_bug.cgi?id=58463
Maxime Nordier maxime.nordier@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maxime.nordier@gmail.com
--- Comment #2 from Maxime Nordier maxime.nordier@gmail.com --- I can reproduce on Hyprland and Niri. Xorg, KDE, GNOME and Sway work correctly.
When looking at the tablet events, Hyprland and Niri do not reset the pressure when lifting the pen (by sending a pressure(0) event before the up() event), whereas Sway, KDE and GNOME do. And if I patch Hyprland to do it, Clip Studio Paint works correctly.
But the documentation of the tablet-v2 protocol lets me think that it is normal behaviour: "Note that pressure may be nonzero even when a tool is not in logical contact. See the down and up events for more details."
Also here's additional system info: - distro: Arch Linux - kernel: 6.15.5-arch1-1 - wine version: 10.11 - hyprland version: 0.49.0 - tablet driver: OpenTabletDriver 0.6.5.1 (also tested with the wacom kernel driver) - tablet model: Wacom CTL-672
http://bugs.winehq.org/show_bug.cgi?id=58463
Daniel Guerrera Dan.guerrera@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Dan.guerrera@gmail.com
--- Comment #3 from Daniel Guerrera Dan.guerrera@gmail.com --- Any chance you could show your patch I'm also struggling with this issue and I'd like to get something working while waiting/hoping for a more permanent fix.
http://bugs.winehq.org/show_bug.cgi?id=58463
--- Comment #4 from Maxime Nordier maxime.nordier@gmail.com --- I've kind of put that issue on the back burner after making a permanent fix for Hyprland, I still need to see about fixing wine.
If you are using Hyprland, the next aquamarine release (Hyprland's wlroots equivalent) should fix it. Though I have no idea when that release will be.
I have put the patch as a plugin mostly for testing. But it's a very hacky workaround. If you use it, don't forget to remove it once aquamarine gets updated. https://github.com/DarkCreepy59/hyprland-plugins
http://bugs.winehq.org/show_bug.cgi?id=58463
mt19770209@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mt19770209@gmail.com
--- Comment #5 from mt19770209@gmail.com --- I am an affected user who investigated this issue further.
Thanks to the very detailed technical analysis provided by @Maxime Nordier in Comment 2, the root cause was clearly identified as a missing pressure(0) event in the Smithay Wayland compositor library (used by Niri and others).
Following this analysis, I submitted a compatibility patch to Smithay. The fix has now been successfully merged into Smithay's master branch.
Merged PR: https://github.com/Smithay/smithay/pull/1851
This change aligns Smithay's tablet event behavior with major compositors like Sway and GNOME, and is expected to resolve the continuous drawing issue in applications like Clip Studio Paint under Wine.
Thank you very much, @Maxime Nordier, for your excellent investigation and information. This bug should be resolved for users once affected compositors update their dependencies to the latest Smithay version.
-
WineHQ Bugzilla