https://bugs.winehq.org/show_bug.cgi?id=44032
Bug ID: 44032 Summary: Diablo 3 2.6.1: Mouse-downs register as mouse clicks Product: Wine Version: 2.20 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: sts33nvyb@gmail.com Distribution: ---
Created attachment 59696 --> https://bugs.winehq.org/attachment.cgi?id=59696 Terminal output (not that I expect this to be useful)
In Diablo 3, mouse-downs (pressing and holding the mouse button) often register as mouse clicks (pressing and immediately releasing the mouse button). This happens for approximately 50% of the mouse-downs when playing the game, which dramatically changes how the game plays, since holding down the mouse button is used for both moving and attacking continuously in the game.
I'm running wine-staging 2.20 on OpenSuse 42.3 x86_64.
This is for the current version of Diablo 3, version 2.6.1.47919 32-bit. Note that Diablo 3 recently dropped support for Windows XP; since this change, Diablo 3 no longer works in non-staging wine at all. Also, the 64-bit version of Diablo 3 has severe performance problems in wine-staging 2.20, so this is using the 32-bit version of Diablo 3.
I speculate that some bug in wine is causing bogus mouse-up events to sometimes be generated immediately after mouse-down events.
Note that this is a completely different bug from bug 31262. Note that user "pakos" has mistakenly commented about this bug in that bug report, dated 2017-11-13. He reports that this problem is present in versions of wine-staging at least back to 2.5.
There has been some discussion of this bug on the application page. Some users have reported that changing wine's virtual desktop setting, forcing 32-bit using setarch, or changing Diablo 3's settings to windowed-fullscreen instead of fullscreen alleviated the problem. None of these helped for me.
https://bugs.winehq.org/show_bug.cgi?id=44032
--- Comment #1 from Steve Soule sts33nvyb@gmail.com --- Some more testing results:
The problem also happens in 64-bit Diablo 3. The 64-bit version has a frame rate of only about 1 FPS, so it's unplayable, but this mouse-down problem is easy to test, and it does happen.
I've also tried using a 32-bit wine prefix. This does not help; the problem still happens.
https://bugs.winehq.org/show_bug.cgi?id=44032
--- Comment #2 from Steve Soule sts33nvyb@gmail.com --- I've gone through the 440 patches of wine-staging 2.20 and found which one seems to be responsible for this problem: the patch "server-send_hardware_message". With just the patches "kernel32-SetFileCompletionNotificationModes" and "ntdll-FileNameInformation" (which are necessary for Blizzard app to work) applied to vanilla wine 2.20, the problem is gone. With the single patch "server-send_hardware_message" applied as well, the problem occurs.
https://bugs.winehq.org/show_bug.cgi?id=44032
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Product|Wine |Wine-staging CC| |erich.e.hoover@wine-staging | |.com, michael@fds-team.de, | |sebastian@fds-team.de Component|-unknown |-unknown
https://bugs.winehq.org/show_bug.cgi?id=44032
--- Comment #3 from Steve Soule sts33nvyb@gmail.com --- I just tested again with wine 2.21 and wine-staging 2.21. As before, the patch server-send_hardware_message triggers this problem for me, and leaving it out (and just using kernel32-SetFileCompletionNotificationModes) makes the problem disappear, for me.
https://bugs.winehq.org/show_bug.cgi?id=44032
xardas01 xardas01@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xardas01@gmail.com
--- Comment #4 from xardas01 xardas01@gmail.com --- I am also having this problem. Every second mouse click is like mouse down/up event. Is there any fix?
https://bugs.winehq.org/show_bug.cgi?id=44032
--- Comment #5 from Steve Soule sts33nvyb@gmail.com --- xardas01: Yes, there is a fix, though it's not a convenient one. As I wrote above, you need to compile non-staging wine 2.21 with one patch from wine-staging 2.21: the patch "kernel32-SetFileCompletionNotificationModes". This one patch is necessary for Blizzard App to work. You can't use full wine-staging 2.21 because it includes a patch, the patch "server-send_hardware_message", that triggers this mouse-downs-register-as-mouse-clicks problem. Unfortunately, compiling wine for yourself is not trivial.
https://bugs.winehq.org/show_bug.cgi?id=44032
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya@gmail.com
--- Comment #6 from Robert Walker bob.mt.wya@gmail.com --- Re: "hit and run" question on #gentoo-wine ...
For anyone that's hitting this issue on Gentoo...
cd "<Portage Directory>/app-emulation/wine-staging/" sed -i -e '|set -- DESTDIR="${S}" --backend=eapply --no-autoconf|{s|--all|kernel32-SetFileCompletionNotificationModes|}' wine-staging-2.19.ebuild ebuild wine-staging-2.19.ebuild manifest
Will disable all the Wine Staging patchsets, for the 2.19 ebuild on Wine Staging, apart from: kernel32-SetFileCompletionNotificationModes
https://bugs.winehq.org/show_bug.cgi?id=44032
Adam Bolte abolte@systemsaviour.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |abolte@systemsaviour.com
--- Comment #7 from Adam Bolte abolte@systemsaviour.com --- I've spent hours on this, and haven't gotten anywhere. I'm in Act III at Bastion's Keep Stronghold, and nothing I do allows me to avoid this bug.
I tried all wine-staging patches against 2.21 except server-send_hardware_message by applying the patches like so.
./patchinstall.sh DESTDIR=../../git --all -W server-send_hardware_message
I also tried building wine-3.0-rc1 and applied only the kernel32-SetFileCompletionNotificationModes patch. No dice. Then I tried doing the same to 2.21. Then I went back to looking at my older wine-staging builds for comparison (eg 2.16-staging). Made no difference.
The bug is easy to reproduce. Launch Battle.net as usual. 64-bit is too slow to be playable, but either 32-bit or 64-bit mode trigger the bug. Once in, I hold down shift so my character is stationary, and then at the same time hold down the left mouse button.
The first time this happens, the hero will continue attacking until the mouse button is released. This is the expected behaviour. Still holding down shift, click and hold the mouse button a second time. Only a single attack will be performed, and then nothing. The result wasn't expected to change.
Then trying again will cause it to work, trying once more and it won't, etc. Every second time the attack button is held down, the game will not register that the button is held down. I expect this would make the game too frustrating to play at higher difficulty settings.
I would love to know why removing the server-send_hardware_message patch solves the problem for you, but not for me. I'm running Debian GNU/Linux 9.3 (Stretch) and an Xfce desktop on an i7-6700k, 32Gb RAM, and ATI RadeonHD 5870 graphics card at 2560x1440 with Linux kernel 4.15.0-rc1 (radeon kernel module), Mesa 17.4.0-devel (git-4c7af87fb9). My mouse is a Logitech G502.
https://bugs.winehq.org/show_bug.cgi?id=44032
--- Comment #8 from Steve Soule sts33nvyb@gmail.com --- Adam, have you tried tweaking the various settings related to windowed mode and desktop emulation? Several people on the Diablo 3 appdb page reported that this helped for them.
My computer: OpenSuse 42.3 x86_64, KDE, i5-4460, 8 GB RAM, Nvidia GTX 460, 1920x1200, kernel 4.4.92-31, nvidia driver 384.98, mouse Logitech G402.
https://bugs.winehq.org/show_bug.cgi?id=44032
Andreas andi@errornet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andi@errornet.de
--- Comment #9 from Andreas andi@errornet.de --- First of all thanks for your research "Steve Soule".
I was struggeling with the same problem and solved it because of your research! Thanks for that! ;)
the only thing that i am missing at the moment is that i normaly play d3 for better performance with gallium nine enabled. like i submited on the link below, the mouse bug appears again if i activate the gallium-nine feature.
https://github.com/iXit/Mesa-3D/issues/298
looks like the gallium nine patchset includes something similar to the "server-send_hardware_message" patch from staging patchset.
like i explained in the last part of my bug report on ixit, i got the same bug a few yours ago while i was testing to install diablo 3 in a new wineprefix with "windows 7" as windows version. changing on the same wineprefix back to windows xp solved the problem and the mouse bug disappeard. i have been on wine-any at this time which is (wine-vanilla + staging + d3d9). because of this i think that something in "server-send_hardware_message" has to be changed to work together with "windows 7" as windows version.
My Computer: Gentoo x86_64, xfce, AMD Phenom(tm) II X6 1100T, 16GB RAM, amd rx470, 3 monitors in a strange arrangement ;) , kernel 4.14.5, mesa 17.2.6, mouse Roccat Kone+
https://bugs.winehq.org/show_bug.cgi?id=44032
--- Comment #10 from Adam Bolte abolte@systemsaviour.com --- Thanks Steve - that's exactly what it was. I tested various combinations of the options listed under the winecfg Graphics tab, and what I discovered was that in addition to the patched version of Wine, "Automatically capture the mouse in full-screen windows" needs to be disabled, and "Emulate a virtual desktop" needs to be enabled. Setting "Desktop size" to the same resolution as my monitor worked best - 2560x1440 in my case. I tried 1920x1080 initially, but then the keyboard wouldn't work and the Wine Windows taskbar was displayed over the top of the game until I clicked around on it.
The middle two winecfg options "Allow the window manager to decorate/control the windows" made no difference regardless of being enabled or disabled.
I also tested wine + wine-staging (minus the bad patch) + d3d9 and the issue returned. In the winecfg Staging tab, disabling the "Enable Gallium Nine for better D3D9 graphic performance" and instead selecting the option "Enable CSMT for better graphic performance", I was able to get the game working correctly again. Certainly not as good as using the d3d9 patch set, but better than nothing.
I should note that before I retested the above, I had replaced my RadeonHD 5870 graphics card with a Fury X. I doubt it made a difference as far as this bug report goes, but worth mentioning.
https://bugs.winehq.org/show_bug.cgi?id=44032
--- Comment #11 from Steve Soule sts33nvyb@gmail.com --- I've just tested with wine-staging 3.3, and the problem is unchanged. With all patches applied, the mouse-downs-register-as-mouse-clicks problem is present; with the single patch "server-send_hardware_message" removed, the problem is not present and Diablo 3 works normally.
https://bugs.winehq.org/show_bug.cgi?id=44032
Maciej Stanczew maciej.stanczew+b@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maciej.stanczew+b@gmail.com
--- Comment #12 from Maciej Stanczew maciej.stanczew+b@gmail.com --- Is anyone who experiences this bug using Battle.net voice chat during the game? I seem to have this issue when I have voice chat in progress. Every second mouse-down will register as a single click. But the moment I disconnect from it (using the green "Leave voice chat" button), the issue stops appearing -- all mouse-downs register properly.
https://bugs.winehq.org/show_bug.cgi?id=44032
--- Comment #13 from Maciej Stanczew maciej.stanczew+b@gmail.com --- I have done some debugging of queue_mouse_message function and have found the following: - Pressing the mouse button calls this function twice: first call has input->mouse.flags = 0x8003 (MOVE|LEFTDOWN), second = 0x8001 (MOVE). - Releasing the button calls it with input->mouse.flags = 0x8005 (MOVE|LEFTUP), and then, after about ~1 ms, an injected event is generated (hook_flags = 1, input->mouse.flags = 1, input->mouse.time = 0). - Without Voice chat enabled, all above events return 0 from call to 'send_hook_ll_message' that is assigned to 'wait' variable. - With Voice chat enabled the above call to 'send_hook_ll_message' *always* returns 1. With the 'server-send_hardware_message' patchset reverted, this is the only change in behavior. - With the 'server-send_hardware_message' in place (not reverted) however, on every second mouse-down the injected event appears after the mouse is *pressed* instead of released (releasing the mouse generates just the MOVE|LEFTUP event, without the following injected event). This is the problematic point -- there was a mouse-down event, but the game behaves as if the button was immediately released.
Can someone knowledgeable in this area look into the issue? I have 100% reproduction of the bug, I can gather whatever logs would be needed.
https://bugs.winehq.org/show_bug.cgi?id=44032
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=45875
https://bugs.winehq.org/show_bug.cgi?id=44032
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #14 from Zebediah Figura z.figura12@gmail.com --- (In reply to Maciej Stanczew from comment #13)
Can someone knowledgeable in this area look into the issue? I have 100% reproduction of the bug, I can gather whatever logs would be needed.
I have a hard enough time wrapping my head around whether the patch is even fundamentally correct, but in the interest of furthering diagnosis, can you please attach a log with +server,+event,+hook?
https://bugs.winehq.org/show_bug.cgi?id=44032
--- Comment #15 from Maciej Stanczew maciej.stanczew+b@gmail.com --- Created attachment 62403 --> https://bugs.winehq.org/attachment.cgi?id=62403 +server,+event,+hook without voice chat
https://bugs.winehq.org/show_bug.cgi?id=44032
--- Comment #16 from Maciej Stanczew maciej.stanczew+b@gmail.com --- Created attachment 62404 --> https://bugs.winehq.org/attachment.cgi?id=62404 +server,+event,+hook with voice chat
https://bugs.winehq.org/show_bug.cgi?id=44032
--- Comment #17 from Maciej Stanczew maciej.stanczew+b@gmail.com --- Attached, but there was so much noise that the log was over the size limit and I had to split it.
In both voice chat states I did a couple of press-release cycles, with about 2-3 seconds between each action.
In the first half of both logs I did a press, then move the mouse (to confirm my character is following the cursor), and then release. In the second half I held shift (which is "attack in place"), then mouse press, confirm that my character is attacking continuously (and not just once), then release.
With voice chat disabled all actions were registered correctly. With voice chat enabled there were problematic mouse-downs at timestamps 11484, 11496, 11519, 11526 (moving the mouse -> character only goes to the place clicked initially), and 11540, 11550, 11556 (holding shift -> character attacks only once).
One thing that stands out is "HOOK_CallHooks" mask, which gets changed from 80010000 to 8001c000 when voice chat is enabled (and back to 80010000 when it's disabled -- it's not shown in attached logs, but I tested it afterwards). I don't know if it's related, or just a side effect.
https://bugs.winehq.org/show_bug.cgi?id=44032
--- Comment #18 from Zebediah Figura z.figura12@gmail.com --- The addition of flags 0xc000 means that WH_KEYBOARD_LL and WH_MOUSE_LL hooks were set.
Bizarrely, your log seems to only contain output from one thread in it, and I don't see any attempts to call hooks from that thread. I also don't see any +server output. Did you do any filtering of the log (besides just clipping it)? If +server doesn't work, can you try +msg instead?
My simplest guess is that somehow the game doesn't expect to receive some message until the hook is done executing, but I don't know what message that would be.
https://bugs.winehq.org/show_bug.cgi?id=44032
--- Comment #19 from Maciej Stanczew maciej.stanczew+b@gmail.com --- I noticed after the fact that +server logs are not present because I launched Battle.net App as the first process and Diablo III (with logs) as second. However with +server there are so many logs that 5 seconds of them take over 7 MB, which is already over the limit (and the whole process took me about 1.5 minutes).
I'll see with +msg, and if +server is still required, I'll try to gather them for a single press-release iteration.
https://bugs.winehq.org/show_bug.cgi?id=44032
--- Comment #20 from Zebediah Figura z.figura12@gmail.com --- (In reply to Maciej Stanczew from comment #19)
I noticed after the fact that +server logs are not present because I launched Battle.net App as the first process and Diablo III (with logs) as second. However with +server there are so many logs that 5 seconds of them take over 7 MB, which is already over the limit (and the whole process took me about 1.5 minutes).
I'll see with +msg, and if +server is still required, I'll try to gather them for a single press-release iteration.
Yep, +server logs attach to the first tty that wine was launched from; should have mentioned that. But yeah, they can be heavy. Hopefully +msg should be enough to provide what I'm looking for.
https://bugs.winehq.org/show_bug.cgi?id=44032
Maciej Stanczew maciej.stanczew+b@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #62403|0 |1 is obsolete| | Attachment #62404|0 |1 is obsolete| |
--- Comment #21 from Maciej Stanczew maciej.stanczew+b@gmail.com --- Created attachment 62406 --> https://bugs.winehq.org/attachment.cgi?id=62406 +msg,+event,+hook
I capped the game's FPS at 8 and now there is less noise in the logs -> they can fit all in the size limit. In this log first scenario is with voice chat, and issue appears at timestamps 17320, 17342, 17362, 17375 and 17386. Voice chat was disabled at 17394 and the issue did not appear from this point until the end.
https://bugs.winehq.org/show_bug.cgi?id=44032
--- Comment #22 from Maciej Stanczew maciej.stanczew+b@gmail.com --- Created attachment 62408 --> https://bugs.winehq.org/attachment.cgi?id=62408 +server,+event,+hook
And log with +server, for a single press-release (I still had to zip it). This is the problematic one, that the game registered as a click instead of mouse-down. If needed I can attach working iterations for comparison.
https://bugs.winehq.org/show_bug.cgi?id=44032
--- Comment #23 from Zebediah Figura z.figura12@gmail.com --- One discrepancy I can see is that MsgWaitForMultipleObjects() will return early if a hardware message is received, even though no window message has been delivered to the thread's queue yet. I'd be surprised if this is throwing off the application, but finding other discrepancies has as yet been difficult.
Trying to write a patch to fix this discrepancy is less than trivial; I'm working on it.
https://bugs.winehq.org/show_bug.cgi?id=44032
zzzzzyzz@hacari.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzzzzyzz@hacari.org
https://bugs.winehq.org/show_bug.cgi?id=44032
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=45938, | |https://bugs.winehq.org/sho | |w_bug.cgi?id=46021
--- Comment #24 from Zebediah Figura z.figura12@gmail.com --- Making a note of other bugs related to this patch set. I'm not going to mark them as duplicates, since I haven't been able to determine the exact problem, and it may be different.
https://bugs.winehq.org/show_bug.cgi?id=44032
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=46052
https://bugs.winehq.org/show_bug.cgi?id=44032
--- Comment #25 from Gijs Vermeulen gijsvrm@gmail.com --- The problematic patchset (server-send_hardware_message) was removed from wine-staging, please retest with wine-staging-3.21.
https://bugs.winehq.org/show_bug.cgi?id=44032
--- Comment #26 from Steve Soule sts33nvyb@gmail.com --- Unfortunately, I can no longer reproduce this bug, even with wine-staging 3.3. When I last tested, in March 2018, I was able to reproduce this bug with wine-staging 3.3. I also tried wine-staging 3.21 just now, and, as expected, the bug does not happen for me with it either.
Things I know have changed for me since March: - Diablo 3 version: is now 2.6.1.51663 (was 2.6.1.49508 or newer) - Linux kernel version: is now 4.4.162-78 (was 4.4.92-31 or newer) - nvidia driver version: is now 390.87 (was 384.98 or newer)
Things I know have not changed for me since March: - wine version (still wine-staging 3.3) - my hardware - my linux distribution version (still opensuse 42.3 x86_64) - my Diablo 3 wine prefix directory (except for the updates to Diablo 3 itself).
Unless someone can suggest some configuration change that I might easily make that will allow me to reproduce the bug, I'm afraid my usefulness as a tester for this bug is at an end.
https://bugs.winehq.org/show_bug.cgi?id=44032
--- Comment #27 from Maciej Stanczew maciej.stanczew+b@gmail.com --- I can still do it with voice chat enabled (as described in comment #12). And sure enough, I have reproduction in Wine Staging 3.19, and no repro in 3.20 and 3.21.
https://bugs.winehq.org/show_bug.cgi?id=44032
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |e4a3b5fc9d5ed7c102b1618270e | |26a1fcac2d53e Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #28 from Gijs Vermeulen gijsvrm@gmail.com --- (In reply to Maciej Stanczew from comment #27)
I can still do it with voice chat enabled (as described in comment #12). And sure enough, I have reproduction in Wine Staging 3.19, and no repro in 3.20 and 3.21.
Alright, marking FIXED then. Thanks for reporting back! If someone can still reproduce this, feel free to reopen.
https://bugs.winehq.org/show_bug.cgi?id=44032
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #29 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Closing Fixed Staging bugs.
-
wine-bugs＠winehq.org