[Bug 44887] New: Pressure sensitivity lost when file requester is opened in ZBrush
https://bugs.winehq.org/show_bug.cgi?id=44887 Bug ID: 44887 Summary: Pressure sensitivity lost when file requester is opened in ZBrush Product: Wine Version: 3.4 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: f2267911(a)nwytg.com Distribution: --- ZBrush (4r8 and 2018) works quite fine but when a file requester (to load or save a tool) is opened, ZBrush does not response to the pressure sensitivity. Before loading a tool the pressure sensitivity worked fine. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44887 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de --- Comment #1 from Fabian Maurer <dark.shadow4(a)web.de> --- Does the issue appear with the demo from https://pixologic.com/zbrush/trial/ ? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44887 --- Comment #2 from Ted <f2267911(a)nwytg.com> --- (In reply to Fabian Maurer from comment #1)
Does the issue appear with the demo from https://pixologic.com/zbrush/trial/ ?
A co-worker reported yes but I haven't tested it myself. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44887 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |wintab32 CC| |leslie_alistair(a)hotmail.com --- Comment #3 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Can you please provide a +wintab32 log? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44887 pattietreutel <katyaberezyaka(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44887 ckardaris(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ckardaris(a)gmail.com --- Comment #4 from ckardaris(a)gmail.com --- Created attachment 65313 --> https://bugs.winehq.org/attachment.cgi?id=65313 +wintab log -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44887 --- Comment #5 from ckardaris(a)gmail.com --- Comment on attachment 65313 --> https://bugs.winehq.org/attachment.cgi?id=65313 +wintab log wintab log from ZBrush 2019 on wine-staging 4.16. Fixme prints starting from the line 54527 signify when the file dialog pops up and after that point the tablet loose pressure. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44887 Marc Laffler <d1096252(a)urhen.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |d1096252(a)urhen.com --- Comment #6 from Marc Laffler <d1096252(a)urhen.com> --- Is more information needed? I'd really like the ZBrush related bugs to fixed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44887 Neko-san <nekoNexus(a)protonmail.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nekoNexus(a)protonmail.ch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=44887 Manuel LaMoire <pippiboyagain(a)posteo.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pippiboyagain(a)posteo.de --- Comment #7 from Manuel LaMoire <pippiboyagain(a)posteo.de> --- This bug still exists in wine 10.8. I needed to install vcrun2022 to get it working and pressure works in the beginning but when I click on load or save it stops working. Please fix! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=44887 woofinmuffin <wfnmuffin@proton.me> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wfnmuffin@proton.me --- Comment #8 from woofinmuffin <wfnmuffin@proton.me> --- This bug is caused by wSerial being incremented by ZBrush internally while file selector is open, while wintab32.dll does not. This causes desynchronization of wSerial numbers between both, and makes ZBrush request WTPacket that have higher wSerial than anything in wintab32's PacketQueue. Both will keep increasing this after popup closes, and it will never match anything in queue after that. I was able to make a bypass for this issue, by making the WTPacket check if ZBrush asks for higher wSerial twice, and if so, just set that serial to whatever ZBrush requests on last available packet in PacketQueue. This makes wintab32.dll resynchronize with ZBrush internal wSerial index, and makes the pen pressure just work after any interaction with any popup. I'm not sure if this is a quirky implementation of wintab in ZBrush, or wine not keeping track of pen events when, the main window that created wintab context, is blocked by a file selector window (that freezes main window both running native on windows and in wine, plus afaik doesn't use wintab at all). I cannot contribute quality code for this project, sorry. I'm including modified context.c from wine-10.20 as a reference. (only BOOL WINAPI WTPacket function is changed) I would also add TRACE() if executable asks for invalid wSerial for any similar cases. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=44887 --- Comment #9 from woofinmuffin <wfnmuffin@proton.me> --- Created attachment 81526 --> http://bugs.winehq.org/attachment.cgi?id=81526 wintab32/context.c Bypass of wSerial desynchronization in wintab (do not merge into main) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=44887 Brandon T <brandon@garagebay9.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brandon@garagebay9.com --- Comment #10 from Brandon T <brandon@garagebay9.com> --- I set Claude loose on this because it's a massive headache for me and it zeroed in on the wintab32 packet queue as well. Summary - The wintab32 packet queue wedges permanently after the file requester opens. The per-context queue holds 10 entries. Once it fills with entries the application never requests, AddPacketToContextQueue drops every newer packet, so the queue never drains and pressure is lost until ZBrush is restarted. The overflow branch in dlls/wintab32/context.c drops the newest packet and keeps the stale ones. That is the part this comment proposes changing. Environment Wine 11.0 (wow64, from the Lutris runner), Debian 13, Wayland session with Xwayland 24.1.6, HUION GT1602 pen tablet (libinput). ZBrush 2022. Trace produced with WINEDEBUG=+wintab32,+timestamp. Reproduction 1. Draw a stroke. Pressure responds. 2. Open File > Load with the pen. In the reporter's tests this has reproduced every time. 3. Close the dialog. Closing with the mouse or the pen gives the same result. 4. Draw a stroke. Contact packets report zero pressure. The state persists until ZBrush is restarted. Trace evidence (timestamps from the log) - 26244.195: last WTPacket call before the gap. - 26244.236 to 26244.244: serials 0x3ef to 0x3f8 are placed. The queue is now full, with 10 entries. - 26244.260 to 26244.360: serials 0x3f9, 0x3fa and 0x3fb hit "Queue Overflow" and are dropped. - 26244.36 to 26249.0: no packets and no WTPacket calls. The pen was idle here (the reporter reached for the mouse), so this gap is not the bug itself. - 26249.032: serial 0x3fc overflows and is dropped. The application's first WTPacket after the gap asks for 0x3fc. TABLET_FindPacket reports 10 entries, none matching, and WTPacket returns 0. - 26249.032 to 26251.556: 520 packets, all "Queue Overflow", zero "Placed in queue". An earlier burst at 26238.679 shows the same policy under normal use. Ten packets arrive in one millisecond, the queue overflows, and WTPacket returns 0 for the dropped serials. The queue recovers there because the application fetches every queued entry, so the queue empties, and new packets are placed again from 26238.784. The 26244 case differs because the queued entries are never requested. Mechanism 1. On overflow, AddPacketToContextQueue sets TPS_QUEUE_ERR on the last queued packet and discards the new packet. 2. wintab32.c still posts WT_PACKET for the discarded packet, so the application asks for a serial that is not in the queue. 3. As far as the trace shows, entries leave the queue only through a WTPacket call that finds a matching serial. The dropped serials are the newest ones, so nothing that is queued gets fetched, and the queue stays full. Proposed change Attached as wintab-queue-evict.diff (against wine master 081042ede6, dlls/wintab32/context.c only). On overflow the oldest entry is evicted, the new packet is stored, and TPS_QUEUE_ERR is set on the new packet. The cursor-change message block now runs on both the normal and overflow paths. The reason for evicting the oldest is that a serial-based application follows the newest packets. Keeping the newest packets retrievable prevents the wedge, and stale entries are pushed out as new packets arrive. Testing status - Syntax-checked with x86_64-w64-mingw32-gcc -Wall, context.c only. - A standalone model of the queue, not Wine code: drop-newest gives 0/20 successful fetches after the overflow, evict-oldest gives 20/20. - Not yet run in a full Wine build with ZBrush. Testing on other applications or tablets would help. Open questions - Why ZBrush does not request the queued serials 0x3ef to 0x3f8 after the gap. The trace shows the messages being posted but no fetches. The cause could be on the application side (for example, handling only the newest WT_PACKET after its loop resumes) or in how messages are dispatched while the file dialog is open. The trace alone does not settle this. - Whether native Wintab behaves differently on overflow. Not checked. - Eviction versus a larger queue. A larger queue only delays the wedge if the application stops fetching for longer than the queue can hold, so the eviction change addresses the failure itself. Maintainers may still prefer a different policy. The full timestamped trace (about 34,000 lines) also included. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=44887 --- Comment #11 from Brandon T <brandon@garagebay9.com> --- Created attachment 82357 --> http://bugs.winehq.org/attachment.cgi?id=82357 Timestamped log of pressure drop showing queue wedge Done in Wine 11 / Zbrush 2022.06 (behavior has been consistent in multiple Wine versions across multiple versions of Zbrush for years) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (3)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla
-
WineHQ Bugzilla