http://bugs.winehq.org/show_bug.cgi?id=27522
Summary: Mouse motion blocked or laggy while clicking Product: Wine Version: 1.3.19 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-dinput AssignedTo: wine-bugs@winehq.org ReportedBy: pilota51@gmail.com
This regression started in 1.3.19 and appears to be related to the fix of Bug 6971.
I posted Bug 6971 comment 512 regarding this issue trying to see if anyone else was experiencing it, which seemed to be ignored. I'm not sure if the lack of complaints is because of a rare combination on my system or because not many people play the affected games in Wine. I've recently reinstalled Ubuntu (for other reasons) and tried a clean .wine directory as per the guidelines, but this issue remained.
In Battlefield 1942 starting at 1.3.19, the mouse completely stops moving when clicking a mouse button and allows moving again when the button is released. The issue exists both in the menu and in-game. BF1942 did not experience Bug 6971. In 1.3.19 (not later releases, but worth noting) only the first click would register. All clicks register in 1.3.20 and later.
In Unreal Tournament 3 starting at 1.3.20, with the option enabled, there is significant lag in mouse movement while clicking, about 1 second between refreshes. With it disabled, there is no issue with clicking and moving the mouse simultaneously, but of course the mouse will leave the window. I've also noticed that while clicking and inducing the lag, the range of the mouse is limited, which tells me the issue with window borders hasn't been fixed entirely even though the mouse doesn't escape. Releasing the button will allow full motion. This is what I did to test how the mouse range behaves: 1. Hold a button down and rotate all the way to the right until it won't go further. 2. Release button, either don't rotate or only rotate right. 3. Hold button again and notice how it still doesn't move any further right. 4. Release button and spin left a few times. 5. Hold button and notice how it won't rotate any further left.
The reason UT3 didn't have this issue in 1.3.19 is because the option simply didn't work until Bug 6971 was fixed in 1.3.20. As for why BF1942 has this problem and other games don't, I have a few guesses but I'm not sure.
If I have time later I might mess with the source and build it to find exactly which code causes it. Looks like one of the last 3 commits on mouse.c contain the cause.
http://bugs.winehq.org/show_bug.cgi?id=27522
--- Comment #1 from Pilot pilota51@gmail.com 2011-06-18 03:48:27 CDT --- Sorry, in the description where I say "the option" I was referring to "Allow DirectX apps to stop the mouse leaving their window". All the tweaking before posting got rid of the original reference and I didn't realize.
http://bugs.winehq.org/show_bug.cgi?id=27522
Pilot pilota51@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=27522
Fab netfab@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |netfab@gmail.com
--- Comment #2 from Fab netfab@gmail.com 2011-06-22 03:05:34 CDT --- Confirming same behavior with (at least) Tomb Raider Anniversary and Jedi Outcast. With this option on, holding mouse button and trying to move results in erratic movements. Wine 1.3.21.
http://bugs.winehq.org/show_bug.cgi?id=27522
--- Comment #3 from Alexandre Julliard julliard@winehq.org 2011-06-22 04:50:08 CDT --- I can't reproduce. BF1942 works fine here.
http://bugs.winehq.org/show_bug.cgi?id=27522
--- Comment #4 from Fab netfab@gmail.com 2011-06-22 05:20:40 CDT --- In Tomb Raider Anniversary I noticed that the behavior does not happen if it is launched in a virtual desktop. It happens only in real fullscreen.
http://bugs.winehq.org/show_bug.cgi?id=27522
--- Comment #5 from Fab netfab@gmail.com 2011-06-22 05:42:13 CDT --- In fact, my previous comment is partially wrong.
in real fullscreen --> always happens, even if capture-the-mouse is unchecked. in virtual desktop --> happens only if capture-the-mouse is checked.
http://bugs.winehq.org/show_bug.cgi?id=27522
--- Comment #6 from Alexandre Julliard julliard@winehq.org 2011-06-22 05:49:42 CDT --- What X server and window manager?
http://bugs.winehq.org/show_bug.cgi?id=27522
--- Comment #7 from Fab netfab@gmail.com 2011-06-22 05:54:58 CDT --- xorg-server 1.9.5, xfwm4-4.8.1 (xfce 4.8).
http://bugs.winehq.org/show_bug.cgi?id=27522
--- Comment #8 from Alexandre Julliard julliard@winehq.org 2011-06-22 06:16:48 CDT --- Can you find a downloadable demo that shows the problem for you?
http://bugs.winehq.org/show_bug.cgi?id=27522
--- Comment #9 from Fab netfab@gmail.com 2011-06-22 06:49:03 CDT --- http://www.tombraiderfiles.com/tra/tombraideranniversary_demo.exe
Installed into a new WINEPREFIX with default parameters.
Holding right click will unsheathe the weapons until you release the mouse button. In real fullscreen, if you try to move the camera while holding the button, you will see the camera jumping from one view to another. If you do the same thing into virtual desktop, the camera movement will be smooth.
http://bugs.winehq.org/show_bug.cgi?id=27522
--- Comment #10 from Alexandre Julliard julliard@winehq.org 2011-06-22 07:22:25 CDT --- Thanks. I don't see any problem here unfortunately, not sure what's going on for you.
http://bugs.winehq.org/show_bug.cgi?id=27522
Pilot pilota51@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware
--- Comment #11 from Pilot pilota51@gmail.com 2011-06-22 16:50:19 CDT --- In my case there is no difference between virtual desktop and fullscreen for BF1942 and UT3.
Using X Server 1.10.1 and Gnome 2.32.1.
I think I'm on to something. I tried my Microsoft Mobile Memory Mouse 8000 and it doesn't have this problem. My mouse that does experience this issue is a Logitech MX510. Because of this, I added the 'hardware' keyword.
http://bugs.winehq.org/show_bug.cgi?id=27522
--- Comment #12 from Fab netfab@gmail.com 2011-06-23 07:02:24 CDT --- (In reply to comment #11)
In my case there is no difference between virtual desktop and fullscreen for BF1942 and UT3.
With jedi outcast, virtual desktop makes also no difference for me : the camera movement always jumps when holding mouse button. Can you try the Tomb raider demo above to see if we're talking about the same thing ?
I tried with another mouse, nothing changed.
Unfortunately today I'm experiencing another fun mouse issue into tomb raider series : the mouse movement is always slowed down, as if the engine was missing mouse events. But I can't explain it. I'm currently building git version to see if it makes difference.
http://bugs.winehq.org/show_bug.cgi?id=27522
--- Comment #13 from Fab netfab@gmail.com 2011-06-23 09:53:47 CDT --- (In reply to comment #12)
Unfortunately today I'm experiencing another fun mouse issue into tomb raider series : the mouse movement is always slowed down, as if the engine was missing mouse events. But I can't explain it. I'm currently building git version to see if it makes difference.
For the record I fixed this slowdown, and this was caused by something totally unrelated to wine and this bug.
I tried wine-git : same behavior when holding mouse buttons : camera is jumping.
http://bugs.winehq.org/show_bug.cgi?id=27522
--- Comment #14 from Pilot pilota51@gmail.com 2011-06-23 17:09:24 CDT --- Tried the Tomb Raider: Anniversary demo and can confirm it is very much like UT3, except menus are also affected (like BF1942), the range isn't limited while clicking. and the behavior between virtual desktop and full-screen is as described by Fab. Also tried it with both of my mice, same results as my other tests: It works fine with the Microsoft mouse.
I tried using both mice simultaneously and I can move one and click the other with no issue, it only happens when the Logitech is doing both the moving and clicking.
http://bugs.winehq.org/show_bug.cgi?id=27522
--- Comment #15 from Pilot pilota51@gmail.com 2011-06-25 00:22:55 CDT --- I installed Jedi Outcast to test, but so far couldn't get it to run. I have Quake 2 installed and remembered that Jedi Outcast also uses the Id Engine (different version though) and that Quake 2 had mouse issues when I played it a couple months back. Turns out the issue it very similar: Lag while clicking, except the update rate is faster at roughly 4 times a second and there's a momentum issue on top of it.
While regression testing, I found that it had a different issue from 1.3.18 to 1.3.20 with the aim moving in an additive momentum fashion and mouse lagging as it did. It also happened with both of my mice. I noticed that pressing a button caused mouse lag where I could notice it (when the momentum wasn't causing any lag), only with my Logitech mouse. The momentum problem was partially fixed in 1.3.21 up to the current 1.3.23 where instead of happening all the time, it only happens while clicking. With my Microsoft mouse the issue is completely gone.
I also did regression testing with Tomb Raider and found that, like UT3, it started with 1.3.20.
I tested Battlefield 2 and it has the same issue as BF1942, starting in 1.3.19, where the mouse completely stops moving while clicking, except it's only in-game and not the main menu. Again, the issue doesn't exist with my Microsoft mouse.
http://bugs.winehq.org/show_bug.cgi?id=27522
Dave Wickham dave@dwickham.me.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dave@dwickham.me.uk
--- Comment #16 from Dave Wickham dave@dwickham.me.uk 2011-07-03 10:48:20 CDT --- I seem to be seeing this same behaviour with Beat Hazard and Team Fortress 2 with Wine 1.3.23; whilst clicking, the mouse's position updates very slowly. I'm not entirely sure when this started happening, as I hadn't played either game for a while, but the games were working a few months ago, so I imagine it's the same issue, although I did switch from Gnome 2 to Xfce, so that could also be a factor.
The behaviour I'm seeing seems to be consistent with Fab's, with one addition; with "Automatically capture the mouse in full-screen windows" disabled and "Emulate a virtual desktop" enabled, both TF2 and Beat Hazard seem to be smoother with regards to mouse movement.
Distro: Ubuntu Natty AMD64 X version: X.Org X Server 1.10.1 Window manager: xfwm4 4.8.1 Mouse: Logitech MX Revolution
http://bugs.winehq.org/show_bug.cgi?id=27522
William Pettersson william.pettersson+wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |william.pettersson+wine@gma | |il.com
--- Comment #17 from William Pettersson william.pettersson+wine@gmail.com 2011-07-07 01:35:28 CDT --- I'm seeing similar issues with Starcraft II. Running wine , with a virtual desktop and Automatically capture the mouse in full-screen windows, the selection box for selecting units is irregular.
It seems that every second-ish, the game draws a new selection box, based on the current location of the mouse. It does this fairly quickly, and the graphical display seems to have no bearing on whether units are selected or not. Additionally the mouse keeps moving fine and the game keeps progressing so it just seems like the UI in SC2 is waiting for some note from the OS to say that the mouse is still moving.
Video clip of broken selection: http://www.youtube.com/watch?v=TGVPioYj4kI
If I disable "Automatically capture the mouse in full-screen windows" then it all works fine.
Video clip of working selection box: http://www.youtube.com/watch?v=suIl2RQNW9c
http://bugs.winehq.org/show_bug.cgi?id=27522
--- Comment #18 from William Pettersson william.pettersson+wine@gmail.com 2011-07-07 09:39:34 CDT --- Created an attachment (id=35464) --> (http://bugs.winehq.org/attachment.cgi?id=35464) Adds XI_ButtonPress to events registered for processing
Just ran some trace logs (WINEDEBUG=trace+cursor) and noticed the following: While the mouse is captured, and I'm holding down a mouse button, no RawMotion events are seen. However, if the mouse is not captured, then I do see RawMotion events while holding down a mouse button and moving the mouse.
I think this might have something to do with passive grabbing. Reading from http://www.mail-archive.com/xorg-devel@lists.x.org/msg16250.html it seems like that basic test program has the exact same issue, while holding down a mouse button, the app doesn't "see" motion events any more.
Reading further on http://comments.gmane.org/gmane.comp.freedesktop.xorg.devel/21612 it seems like this is intended behaviour.
This behaviour holds with both RawButtonPress/RawMotion and ButtonPress/Motion, it appears that if we don't register for the button press, then any motion events that come after between a press and a release won't be sent to the calling application.
It seems like just registering for the ButtonPress event, however, is all that we need to get a "passive grab" which then gives us the RawMotion events again.
The attached file simply just registers the XI_ButtonPress, and it "fixes" the issue for me. I am not sure why this issue only shows up when the mouse is set to be captured, and it seems like a hack to me, but I think the only proper solution is to fully implement libXi mouse button presses as well, so I don't know whether this is worthwhile as a stopgap measure.
http://bugs.winehq.org/show_bug.cgi?id=27522
--- Comment #19 from Alexandre Julliard julliard@winehq.org 2011-07-07 10:00:46 CDT --- That XInput behavior seems broken to me, but if the workaround helps, it can certainly be applied, it should be harmless. Please submit a patch.
http://bugs.winehq.org/show_bug.cgi?id=27522
--- Comment #20 from Fab netfab@gmail.com 2011-07-07 10:48:51 CDT --- I built wine 1.3.23 with the patch from comment #18 and it seems to fix the problem for all tested applications, thanks :)
http://bugs.winehq.org/show_bug.cgi?id=27522
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #21 from Austin English austinenglish@gmail.com 2011-07-11 13:30:18 CDT --- (In reply to comment #20)
I built wine 1.3.23 with the patch from comment #18 and it seems to fix the problem for all tested applications, thanks :)
Committed: http://source.winehq.org/git/wine.git/commitdiff/266cd6c46acf7465ad65ae2b963...
http://bugs.winehq.org/show_bug.cgi?id=27522
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #22 from Alexandre Julliard julliard@winehq.org 2011-07-22 12:45:33 CDT --- Closing bugs fixed in 1.3.25.
http://bugs.winehq.org/show_bug.cgi?id=27522
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |266cd6c46acf7465ad65ae2b963 | |a75cfc21d63d0
-
wine-bugs＠winehq.org