WineHQ
Bug Tracking Database – Bug 6971

 Bugzilla

 

Last modified: 2016-03-22 09:06:14 CDT  

Mouse "escapes" window or is confined to an area in the full screen program

Bug 6971 - Mouse "escapes" window or is confined to an area in the full screen program
Mouse "escapes" window or is confined to an area in the full screen program
Status: CLOSED FIXED
AppDB: Show Apps affected by this bug
Product: Wine
Classification: Unclassified
Component: winex11.drv
unspecified
x86 Linux
: P2 normal
: 1.4.0
Assigned To: Mr. Bugs
http://appdb.winehq.org/appview.php?i...
: download, regression
: 3219 6981 7005 7247 7450 7613 7958 7968 8291 8561 9244 9846 10553 10556 10927 11089 11381 12177 12472 13096 Worms 13603 13929 14017 14071 14307 14655 14890 15476 16067 Warcraft3_mms 16119 16819 17157 17751 17801 18774 20582 20593 20796 22729 23579 25855 26274 26408 27942 (view as bug list)
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2006-12-21 20:25 CST by Vitaliy Margolen
Modified: 2016-03-22 09:06 CDT (History)
197 users (show)

See Also:
Regression SHA1: 938657b1c1ff1f6c05b3a521a60f3dcfef0d196b
Fixed by SHA1:
Distribution: ---
Staged patchset:


Attachments
Hack to force mouse warping (376 bytes, patch)
2007-08-24 16:22 CDT, Toni Spets
Details | Diff
Hack for Lineage II camera rotation: Do mouse warp only when right mouse button is pressed (429 bytes, patch)
2008-01-08 11:48 CST, rm+bwo
Details | Diff
Hack for Lineage II camera rotation: Do mouse warp only when RMB is pressed, after a delay (1.05 KB, patch)
2008-01-18 23:13 CST, rm+bwo
Details | Diff
Hack to force warping when mouse leaves box (476 bytes, patch)
2008-03-10 14:38 CDT, Joe McKort
Details | Diff
winex11.drv: Use ClipCursor to grab/ungrab the pointer (7.19 KB, patch)
2008-03-30 00:35 CDT, Vitaliy Margolen
Details | Diff
winex11.drv: Process LeaveNotify to ungrab the pointer (4.19 KB, patch)
2008-03-30 00:36 CDT, Vitaliy Margolen
Details | Diff
winex11.drv: Virtualize mouse pointer if it's invisible and grabbed (4.89 KB, patch)
2008-03-30 00:37 CDT, Vitaliy Margolen
Details | Diff
Hack to force warping when mouse leaves box (modified) (1.61 KB, patch)
2008-05-11 15:23 CDT, Denis Misiurca
Details | Diff
Hack to warp mouse in Gothic 3 with resolution 1024x768 (1.61 KB, patch)
2008-05-16 12:21 CDT, Mariusz
Details | Diff
Mouse hack that wrapping cursor when app starts clipping cursor (1.84 KB, patch)
2008-05-18 09:27 CDT, Nikita
Details | Diff
hacked dinput.dll for wine version 0.9.58 - manages to warp the mouse in Project IGI, Gothic 3 and other games (217.36 KB, application/octet-stream)
2008-08-22 11:27 CDT, Cristian Dogaru
Details
Proposed mouse improvement for 'stuck menu problem (569 bytes, patch)
2008-08-25 16:22 CDT, Brian Vuyk
Details | Diff
Patch for mouse problems in Fallout 3 (2.95 KB, text/plain)
2008-11-08 19:42 CST, Mirek Slugen
Details
Patch for mouse problems in Fallout 3 (ver. 2) (3.09 KB, patch)
2008-11-18 01:00 CST, Mirek Slugen
Details | Diff
terminal output for SWAT4 game (2.59 KB, text/plain)
2009-01-05 16:59 CST, kemelzaidan
Details
Hack to read raw mouse movement from /dev/input/mice (2.66 KB, patch)
2009-01-13 11:42 CST, Daniel Scharrer
Details | Diff
add a toggle with the middle mouse button for the mouse wrapping. (1.22 KB, patch)
2009-04-06 12:38 CDT, Joey Forgues Forget
Details | Diff
mouse patch modified only recenter mouse when right,left or middle click is down. (3.55 KB, patch)
2009-04-26 06:02 CDT, Yvan Da Silva
Details | Diff
Output during lag/freeze when using patch id=18681 (3.82 KB, text/plain)
2009-05-11 14:00 CDT, LBM
Details
Patch for mouse for bug 6971 (13.22 KB, patch)
2009-06-04 12:05 CDT, giovanni.nicola
Details | Diff
Add force-box option to MouseWarpOverride registry key (3.09 KB, patch)
2009-11-17 08:07 CST, Thanos Chatziathanassiou
Details | Diff
New version of giovanni.nicola patch (21554) to work with Wine 1.1.34 (10.86 KB, patch)
2009-12-06 20:04 CST, Rob Whalley
Details | Diff
Resolves mouse problems for ME / ME 2 (3.88 KB, patch)
2010-02-06 15:12 CST, Kirov
Details | Diff
A possible Xi2 patch (18.57 KB, patch)
2010-03-05 23:55 CST, Vitaliy Margolen
Details | Diff
Xi2 patch with xorg bug workaround (20.63 KB, patch)
2010-07-03 08:11 CDT, Vitaliy Margolen
Details | Diff
Fix for mouse "escapes" window (3.01 KB, patch)
2010-07-18 10:07 CDT, madscientist
Details | Diff
xinput2 patch fixed for latest wine git (after-1.3.4) (19.29 KB, patch)
2010-10-08 07:36 CDT, quaker
Details | Diff
updated xinput2 patch for wine git (after-1.3.5) (19.59 KB, patch)
2010-10-20 12:56 CDT, quaker
Details | Diff
xinput2 patch fixed for wine git from 20101020 (after-1.3.5) (18.88 KB, patch)
2010-10-20 16:09 CDT, Johan Palmqvist
Details | Diff
Add Xinput2 support (20.36 KB, patch)
2010-11-03 00:48 CDT, ultrageek.lloyd
Details | Diff
xi2 patch fixed 11/11/2010 c138970ea2ce0661ebb80a5e0079e284a19d3176 (19.60 KB, patch)
2010-11-11 16:26 CST, quaker
Details | Diff
Xinput2 patch, fixed for commit 179b862738aae3b84b87c8e421cef868fe60e87e (01/08/2011) (19.60 KB, patch)
2011-01-07 23:40 CST, Itzamna
Details | Diff
Rediffed to apply to today's git (19.46 KB, patch)
2011-03-08 15:41 CST, Dan Kegel
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Vitaliy Margolen 2006-12-21 20:25:09 CST
In the menu and game itself Wine allows mouse to "escape" the game window. In
turn Wine looses track of the mouse and character freezes in the game. Forcing
game to reinitialize by changing screen resolution or toggling
windowed/full-screen mode "cures" the problem.

This happens because game attempts to set exclusive coop mode but fails (bug
6960). And instead ending up using background cooperative mode with dinput,
which should not touch position of existing mouse pointer. However Wine has no
means of tracking mouse if it leaves Wine windows.
Comment 1 Vitaliy Margolen 2006-12-23 22:54:53 CST
*** Bug 6981 has been marked as a duplicate of this bug. ***
Comment 2 Vitaliy Margolen 2006-12-26 09:48:53 CST
*** Bug 7005 has been marked as a duplicate of this bug. ***
Comment 3 Andreas Fischer 2007-01-02 13:11:48 CST
(not sure, whether this is still needed - sorry if not)

Regression caused by (according to git bisect):

<<
938657b1c1ff1f6c05b3a521a60f3dcfef0d196b is first bad commit
commit 938657b1c1ff1f6c05b3a521a60f3dcfef0d196b
Author: Vitaliy Margolen <wine-patches@kievinfo.com>
Date:   Wed Dec 20 01:05:42 2006 -0700

    dinput: Warp mouse in exclusive cooperation mode only.

:040000 040000 5e95a068457fd450e43dbe150ca3d6ab963aa918
aa2f7c32c494bb1806553d8253ee590764bedf40 M      dlls
>>

I'd be willing to do further testing on this, if required (and if someone tells
me what to do).
Comment 4 Vitaliy Margolen 2007-01-02 13:23:40 CST
Yeah I knew that patch would cause this regression. However, dinpuit should not
warp mouse at all.
I'm working on moving mouse warping into winex11drv. It should fix this
regression too.
Comment 5 Dean Hamstead 2007-01-02 16:46:52 CST
this not grabbing the mouse seems to also happen in halflife 2 and rollercoaster
tycoon 3.

but anyway, thanks for your good work - i realise that while this is a
regression, over all mouse support has progressed enormously. looking forward to
the fix!
Comment 6 Vitaliy Margolen 2007-01-02 17:28:40 CST
Half-Life (all versions) don't use dinput and never did. This bug does not apply
to them.
Comment 7 Dean Hamstead 2007-01-04 17:15:21 CST
yeah sorry you are right, hl2 just breaks regularly for me.
Comment 8 EA Durbin 2007-01-04 20:43:02 CST
This bug occurs in the lemony snickets demo, the previous bugs which made the
game unplayable have all been fixed except now the mouse escapes the window and
causes the character to keep running. The demo can be freely downloaded here.

http://www.fileshack.com/file.x/5989/Lemony+Snickets+A+Series+of+Unfortunate+Events+Demo
Comment 9 Albert Santoni 2007-01-10 16:29:06 CST
Rainbow Six: Raven Shield is almost playable now in WINE, and this is one of the
few bugs left that affects it.
Comment 10 chaykin 2007-02-01 16:05:06 CST
Postal 2 is affected too
Comment 11 Vitaliy Margolen 2007-02-16 20:07:07 CST
*** Bug 7450 has been marked as a duplicate of this bug. ***
Comment 12 Vitaliy Margolen 2007-03-03 18:39:15 CST
*** Bug 7613 has been marked as a duplicate of this bug. ***
Comment 13 Dean Hamstead 2007-03-16 16:11:26 CDT
i dont mean to be inappropriate, but how is this bug coming along? i understand
its a tricky one. would a few dollars in paypal help this move along?
Comment 14 Vitaliy Margolen 2007-03-16 22:54:12 CDT
Latest patches sent that still have issues are:
http://www.winehq.org/pipermail/wine-patches/2007-January/035191.html
http://www.winehq.org/pipermail/wine-patches/2007-January/035215.html

I do not have time to work on this. If anyone wants to get these patches in,
they better be sure to fix all issues with them before resending.
Hint: real good understanding of multi-threading required to fix them.
Comment 15 Vitaliy Margolen 2007-03-19 19:45:48 CDT
This bug does not depend on anything. It's other way around.
Comment 16 Vitaliy Margolen 2007-04-05 20:56:09 CDT
*** Bug 7958 has been marked as a duplicate of this bug. ***
Comment 17 Vitaliy Margolen 2007-04-07 16:23:17 CDT
*** Bug 7968 has been marked as a duplicate of this bug. ***
Comment 18 Vitaliy Margolen 2007-04-08 11:35:15 CDT
Rephrase the summary to include full screen programs.
Comment 19 Vitaliy Margolen 2007-06-01 21:58:22 CDT
*** Bug 8561 has been marked as a duplicate of this bug. ***
Comment 20 haarp 2007-06-25 10:52:40 CDT
Native dinput8.dll also shows this issue for me in Quake Wars. Does this bug
cover this?
Comment 21 Vitaliy Margolen 2007-06-25 12:17:14 CDT
Haarp, if you check component it says nothing about dinput. It is purely
difference in the way low level mouse messages are generated and delivered to an
application / window.
Comment 22 Loki Satyr 2007-06-26 02:38:16 CDT
In "American McGee's Alice", disabling Direct Input makes the mouse act
normally.  To do this, in a terminal run:

echo "seta in_mouse -1" >> "$HOME/.wine/drive_c/Program Files/EA GAMES/American
McGee's Alice/Base/config.cfg"
Comment 23 Vitaliy Margolen 2007-07-22 13:14:05 CDT
*** Bug 3219 has been marked as a duplicate of this bug. ***
Comment 24 PUNX69 2007-07-28 19:11:14 CDT
i hav the same problem with various Unreal 2 Engine games(UT2003/2004, Unreal 
2, Brothers in Arms RTH30, Brothers in Arms EIB)
Comment 25 Vitaliy Margolen 2007-08-11 16:44:56 CDT
*** Bug 9244 has been marked as a duplicate of this bug. ***
Comment 26 Toni Spets 2007-08-24 16:22:44 CDT
Created attachment 7774 [details]
Hack to force mouse warping

This hack forces Wine to use mouse warping even if the cooperation level does not include DISCL_EXCLUSIVE.

It's certainly NOT a permanent solution and is meant for testing only.

This patch enables mouse in the Raven Shield menu while the real implementation is on the way.

The mission briefing menu however has a strange drawing bug so I had to guess where to click START.

I don't know how this affects other applications.
Comment 27 Carroll Vance 2007-09-16 20:19:40 CDT
I find you can get around this naturally by setting the mouse sensativity extremely high ingame. The hack only worked for UT2004 for me. Swat 4 locks the mouse to the center of the window at all times. UT2004 plays great now though.
Comment 28 Vitaliy Margolen 2007-09-30 10:55:21 CDT
*** Bug 9846 has been marked as a duplicate of this bug. ***
Comment 29 Vitaliy Margolen 2007-10-06 17:55:25 CDT
Well I don't want to nominate my own bug, but this really should be fixed by 1.0.0
Comment 30 kapta 2007-10-07 09:08:20 CDT
i agree, tons of games are affected by this bug, fixing it will make a lot more of them playable.
Comment 31 Dan Kegel 2007-10-07 10:11:27 CDT
It does seem to affect a lot of apps, so it's a good candidate for 1.0.
Comment 32 Dean Hamstead 2007-10-16 18:00:00 CDT
did a patch for this just go into GIT?
Comment 33 tehblunderbuss 2007-11-07 00:55:00 CST
(In reply to comment #32)
> did a patch for this just go into GIT?
> 

The attached patch (from wine-0.9.44, on 07-08-24) is not in today's GIT.
Comment 34 Tom Anderson 2007-11-16 15:04:33 CST
Ummm...could a dev please throw in the mouse patch into 0.9.49 or higher GIT, actually come to think of it maybe on standard release.

There is still a good amount of RvS gamers out there! (even though RS: Las Vegas is out now.)
Comment 35 Vitaliy Margolen 2007-11-23 16:47:54 CST
*** Bug 10553 has been marked as a duplicate of this bug. ***
Comment 36 Jesse Allen 2007-11-24 11:47:45 CST
*** Bug 10556 has been marked as a duplicate of this bug. ***
Comment 37 Jared Sutton 2007-12-01 13:21:33 CST
I'm pretty sure this is the problem I'm seeing with BF1942 with wine 0.9.50 (and 0.9.49) on Ubuntu Gutsy.  I was using 0.9.49 from the winehq repository and 0.9.50 from a fresh build.
Comment 38 Jordan M 2007-12-18 01:22:33 CST
I can confirm this in Unreal 2 with wine 0.9.51
Comment 39 Clarence Risher 2007-12-25 17:05:12 CST
I can confirm the patch fixes mouse behavior in the game XIII.
Comment 40 Vitaliy Margolen 2007-12-28 13:16:46 CST
*** Bug 10927 has been marked as a duplicate of this bug. ***
Comment 41 Vitaliy Margolen 2007-12-29 16:23:04 CST
*** Bug 7247 has been marked as a duplicate of this bug. ***
Comment 42 Vitaliy Margolen 2008-01-08 10:16:57 CST
*** Bug 11089 has been marked as a duplicate of this bug. ***
Comment 43 rm+bwo 2008-01-08 11:48:59 CST
Created attachment 10119 [details]
Hack for Lineage II camera rotation: Do mouse warp only when right mouse button is pressed

I am the reporter of bug 11089.

I have tried the "Hack to force mouse warping", which enables mouse warping to be done always. But in Lineage II, this leads to inability to move mouse pointer away from center of the screen to click any of the UI buttons, click on surface for movement, etc.

In Lineage II, mouse warping is only needed whenever right mouse button is pressed down, because this means the use of camera rotation mode. So, this new hack achieves the perfect behavior of camera rotation in that particular game. 

But of course, this is not a correct fix, and just a temporary solution for those who need just one game to function properly.
Comment 44 Dave 2008-01-18 18:54:49 CST
I got this problem with Wine 0.9.53 Raven Shield v1.0 and v1.6 and the patch does work effectively
Comment 45 rm+bwo 2008-01-18 23:13:04 CST
Created attachment 10355 [details]
Hack for Lineage II camera rotation: Do mouse warp only when RMB is pressed, after a delay

Glad to hear it helped.

I made another, a bit more advanced version. It fixes the annoying problem (in Lineage II), specifically, the mouse cursor jumping from where it was to the screen center after any camera rotation. Enabling mouse warp only after a short delay seems to solve this.
Comment 46 Vitaliy Margolen 2008-01-29 15:21:24 CST
*** Bug 11381 has been marked as a duplicate of this bug. ***
Comment 47 Gilboa Davara 2008-01-31 03:33:30 CST
FYI.
Still happens in Red Orchestra / OSF under wine 0.9.52. (F8/x86_64)
Have yet to try the mouse-wrapping patch.

- Gilboa
Comment 48 Rafael JPD 2008-02-02 06:26:28 CST
This problem still occurs on Swat 4 under wine 9.54 (under linux ubuntu 7.04). Can someone help me ?
Thank you
Comment 49 joaopa 2008-02-02 07:03:59 CST
Try native dinput.dll.

If it does not work, you need to fix the bug yourself. This will be a huge task. Watch the wine devel mailing list. There are plenty of subjects related to this bug.

Joaopa
Comment 50 matthias münch 2008-03-05 05:39:21 CST
Hi anybody...

sorry... i'm new...
can somebody describe step by step how i can apply the patch "Hack to force mouse warping"? 

Please!!! i need help!
Comment 51 Dmitry Timoshkov 2008-03-05 05:52:07 CST
(In reply to comment #50)
> Hi anybody...
> sorry... i'm new...
> can somebody describe step by step how i can apply the patch "Hack to force
> mouse warping"? 
> Please!!! i need help!

If you need help ask on the user support forum, not here.

Comment 52 Schmaker 2008-03-05 08:21:06 CST
Hi there,
i wanna ask if there is a chance to get fix until wine 0.9.57 or 1.0. I thing, that this bug affected too many applications (mostly games), which could run out of the box... Thanks for response...
Comment 53 joaopa 2008-03-05 09:19:04 CST
I propose to raise this bug to the level Major, since it fulfill the requirement for this: loss of functionality and affect a lot of applications

It is a huge task to fix this bug (needs to modify X server)
So, no it won't be fixed in wine-0.9.57

Joaopa
Comment 54 Schmaker 2008-03-05 09:23:59 CST
Okay, i understand. So, this bug can be fixed only with new version of Xorg? Or wine developers have to find a "hack" to get this working?
Comment 55 Tom Anderson 2008-03-05 12:36:21 CST
Let's put it this way: some games will work better in the future (old and even new ones) in Wine, while other ones won't (ditto).

So it's mostly a shot in the dark anyway, getting these games to work, or in case in point, with mouse warping.

Haven't tested the games I mentioned yet (Raven Shield, Iron Wrath for it) with latest Wine yet.

Tom
Comment 56 Max 2008-03-07 12:52:52 CST
If you take a look here: http://en.wikipedia.org/wiki/Unreal_engine#Unreal_Engine_2_2 you'll see that there are several games that use the Unreal Engine 2.0, including games such as XIII, and Swat 4 itself. If this bug is fixed, then it would fix the bug for theoretically all the other games using the engine. I have played other games that use the engine, and they all have the exact same issue. Think of what can be accomplished by fixing one little bug? Think of it wine devs, it's all up to you. Fix a little bug, improve support for dozens of games.

This bug must have it's priority increased, it needs to be fixed.
Comment 57 Benjamin Debski 2008-03-07 18:18:29 CST
I agree, this bug affects to many games for it to go unfixed. The severity needs to be upped to major since it affects multiple applications and we are not just talking about 2 or 3 here its around 20 or so and the priority should be P1.

Not much of a programmer myself but I'm wondering why this is so difficult to fix, is it not as easy as resetting the cursor position to the center of the screen after each mouse movement thus preventing the mouse from escaping the window?
Comment 58 Timo-Heikki Mäkelä 2008-03-07 18:42:57 CST
(In reply to comment #57)
> Not much of a programmer myself but I'm wondering why this is so difficult to
> fix, is it not as easy as resetting the cursor position to the center of the
> screen after each mouse movement thus preventing the mouse from escaping the
> window?
> 
There certainly is more than that to it. One simply cannot change code easily in this area, because it'll affect things practically everywhere.

Perhaps this'll explain a bit better than myself how hard those guys really are working: http://bugs.winehq.org/reports.cgi?product=Wine&datasets=NEW%3A&datasets=UNCONFIRMED%3A&datasets=RESOLVED%3A&datasets=CLOSED%3A&datasets=FIXED%3A&datasets=INVALID%3A&datasets=DUPLICATE%3A&datasets=ABANDONED%3A
(I hope the link works this way.) [/offtopic]
Comment 59 Max 2008-03-07 18:55:14 CST
But what about this: Releasing the patch that fixes the issue for users that focus on Unreal 2 based-games. Think about it. A patch with an advisory that it will screw other things up in other applications, but at the same time, it'll fix an annoying issue in Unreal 2 engine based-games. Because the "unofficial patches" that are in the atachements only seem to centre the mouse, not letting it go ANYWHERE. If this issue is fixed with an official patch, it would be so good for so many people. Just, Please. Give us a fix, Advise us of the consequences.
Comment 60 Timo-Heikki Mäkelä 2008-03-07 19:41:04 CST
(In reply to comment #59)
> A patch with an advisory that it will screw other things up in other 
> applications, but at the same time, it'll fix an annoying issue in 
> Unreal 2 engine based-games.
You don't seem to understand. Wine is a program needed for running THOUSANDS of applications. A few games definitely aren't among the most important, although how fascinating. Fixing "an annoying issue" improperly in a few games, as you said it yourself, might totally screw up every other application AND that game of yours, too! All because of your impatience.

Now, Vitaliy said the core of the problem in comment #15:
> This bug does not depend on anything. It's other way around.
Do believe him. And now, let's cut the crap. With this spam we are wasting the time of those very few extremely valuable experts trying to fix this and many other thing around.

UNLESS YOU HAVE ESSENTIAL NEW INFORMATION
*** DO NOT POST! ***
Comment 61 Dave 2008-03-08 03:45:58 CST
(In reply to comment #53)
> I propose to raise this bug to the level Major, since it fulfill the
> requirement for this: loss of functionality and affect a lot of applications
> 
> It is a huge task to fix this bug (needs to modify X server)
> So, no it won't be fixed in wine-0.9.57
> 
> Joaopa
> 

Totally agree. The bug's current severity level is inaccurate.
Comment 62 Dan Kegel 2008-03-09 09:31:04 CDT
http://www.winehq.org/pipermail/wine-users/2008-March/029726.html
says the demo from
http://download.piranha-bytes.com/download.php?getname=/gothic3/Gothic3Demo-US.exe
probably exhibits this bug.
"The only way to turn the character around seems to be by moving the
mouse. Works, but a full turn is impossible because the cursor leaves
the window and that stops turning."
Comment 63 Joe McKort 2008-03-10 14:38:38 CDT
Created attachment 11303 [details]
Hack to force warping when mouse leaves box

i suffered from this bug using gothic 3, i.e. i couldn't turn around freely because the mouse stops when it hits the borders.
i started out with the "Hack to force mouse warping", but using the main menu is a pain this way ;-) (probably same problem as Roman Mamedov described commenting his patch)
but i don't want to press a button to look around, so none of those patches worked for me, therefore i started experimenting with the mouse.c until i came up with a solution that's unideal, but might at least work for a couple of games.
what it does is warping the mouse in case it leaves a box that is 2 pixels (can of course be changed) smaller than the screen on each side, using hook->pt.{x/y} to get the current mouse position and This->win_center{X/Y} for calculating the screen size.
the latter one could probably be replaced by adding a new variable, which stores the screen size, so it won't have to be computed anew.

the main two problems about this solution are:
the mouse will also warp, when in a menu leaving the box
and
when playing in window mode the mouse might leave the window before the hack "realizes" this, that means the window manager regains control over the mouse handling before the mouse is warped back to the center, f.e. if you move the mouse too fast.

but i hope it will help someone!
Comment 64 Joe McKort 2008-03-10 14:43:22 CDT
... i used it under version 0.9.56, if that's of any interest
Comment 65 kfs1 2008-03-14 14:01:17 CDT
Gnome 2.22 in rel notes say: "the ability to capture the pointer within a region of the screen;"

Is this of some use to the wine developers? I also heard that a patch on the xserver might fix this, is this correct and if so how?
Comment 66 Victor 2008-03-14 18:32:17 CDT
An idea for possible workaround. 

What about using Wine's virtual desktop (if enabled and available) for tracking mouse outside the window? I mean - comments say, that without a window tracking mouse position is impossible. But virtual desktop has it's own window, so  (as I understand) this window can be made fullscreen (without decorations, etc) and used for tracking mouse. 

Will this help?
Comment 67 Vitaliy Margolen 2008-03-14 19:17:16 CDT
Capturing mouse is not a problem - see XGrabPointer. Reading any mouse movements _ON THE EDGE_ of the window/display _IS_ the problem. The only way to do that is:
1. Warp the mouse
2. Read mouse events directly from the device. Be it xevents from XInput (via the X server - the right way), the evdev events from the device itself. Or some other source of events (dunno what else is left).

This bug is about consequence of doing 1) because 2) is not available (X server won't allow to open primary pointer device as an XInput device) or is the wrong way to do it (reading evdev events directly from the mouse device).
Comment 68 Dean Hamstead 2008-03-14 19:23:02 CDT
using events device would be linux specific, the bug would still remain for freebsd, solaris, etc etc.
Comment 69 Vitaliy Margolen 2008-03-14 19:34:18 CDT
(In reply to comment #68)
> using events device would be linux specific, the bug would still remain for
> freebsd, solaris, etc etc.
> 

Correct, so the only available options is getting these events from the X server (pretty much where Wine gets them now).

But the problem with that - it's the absolute coords of the pointer (not the actual mouse movements). These coordinates don't change if the pointer on the edge of the screen and doesn't move past it. While mouse can still move.

Which means Wine have to get actual hardware mouse events from X server. The only way to do that is via XInput extension. However core pointer and core keyboard can not be opened this way.
Comment 70 Andrew Charles Hurst 2008-03-16 07:45:37 CDT
Hello,
has the option of a virtual mouse pointer for fullsceen mode been disregarded?

I envisaged a solution where for a fullscreen app the XCursor is blanked, but warped every event, while wineX11drv maintains some virtual coordinates which the app is given.  Thus relative moves of the virtual mouse position can still be generated at the screen borders.

X11drv would have to take care of drawing the virtual mouse pointer, unless there's a shortcut in X/hardware.
Comment 71 Dan Kegel 2008-03-22 09:15:35 CDT
Proper fix will probably require being able to read XInput
events from main mouse, which is an X change.  We're going to
have a Wine representative at next month's X Developers Conference,
that might help.

But X changes are slow, so deferring.  (Sorry, folks.)
Comment 72 Austin English 2008-03-23 22:20:38 CDT
*** Bug 12177 has been marked as a duplicate of this bug. ***
Comment 73 Peter Kovacs 2008-03-24 03:46:25 CDT
Isn't it possible to read the mouse device directly on all plattforms?
I mean they are all unix system. if we add a mouse rawdevice to winecfg that points on the rawdevice in the system we get at least a technical correct workaround. Or am I wrong?
Comment 74 Dean Hamstead 2008-03-24 05:14:13 CDT
maybe link to manymouse from icculus.org

http://icculus.org/manymouse/

it provides mousing abstraction on linux mac etc. is zlib license though :\
Comment 75 Jose R. 2008-03-24 21:48:38 CDT
Quake 3 affected by this bug too
Comment 76 Victor 2008-03-26 04:25:06 CDT
> Proper fix will probably require being able to read XInput
> events from main mouse, which is an X change.
This bug somehow doesn't exist on Cedega (or maybe they use game-dependant database of workarounds - i don't know), and Cedega doesn't require X server changes. So there must be other way.
Comment 77 rm+bwo 2008-03-28 09:15:33 CDT
I highly doubt that Cedega uses a game compatibility database for all mouse warping behavior. It does use some game-specific code, but as far as I can tell, the amount of it is minor. It should be mentioned that the Cedega source code is available on the web. A license could disallow a direct copy-paste, but one can look and gather ideas, and ideas can not be copyrighted. I have been trying to compare the Wine mouse code with the corresponding Cedega code, but unfortunately I do not know neither C++ nor Wine codebase well enough to decipher the key differences which cause (or not cause) this bug.
Comment 78 Dmitry Timoshkov 2008-03-28 10:49:06 CDT
(In reply to comment #77)
> I highly doubt that Cedega uses a game compatibility database for all mouse
> warping behavior. It does use some game-specific code, but as far as I can
> tell, the amount of it is minor. It should be mentioned that the Cedega source
> code is available on the web. A license could disallow a direct copy-paste, but
> one can look and gather ideas, and ideas can not be copyrighted. I have been
> trying to compare the Wine mouse code with the corresponding Cedega code, but
> unfortunately I do not know neither C++ nor Wine codebase well enough to
> decipher the key differences which cause (or not cause) this bug.

You are highly overestimating openness of Transgaming. What you see as
a WineX source code is a very small part of actual code, all the directx,
d3d and related source has not been updated for years in the public tree.
Comment 79 Ben P. 2008-03-28 11:03:00 CDT
> You are highly overestimating openness of Transgaming. What you see as
> a WineX source code is a very small part of actual code, all the directx,
> d3d and related source has not been updated for years in the public tree.
> 

http://cvs.transgaming.org/cgi-bin/viewcvs.cgi/winex/dlls/dinput/mouse/main.c

It was last updated almost 8 months ago.  Whether or not it's 100% up to date: I dunno.  But there do seem to be some hacks related to this bug in there.  See specifically around line 622 "#ifdef MOUSE_HACK" and below, where they work on transposing "Relative mouse input with absolute mouse event", and the WARP_NEEDED, WARP_STARTED, etc.
Comment 80 Peter Kovacs 2008-03-29 06:34:16 CDT
Hi all,

I took a glance into mouse.c. Can anyone tell me where the mouse uses X events?
I dont see anything, exept that wine reads mouse staus from X.
And it looks to me that wine is handleing everything on its own. Is that correct?

I will check and read on. Only have checked mouse.c yet.
If someone has some overview doc that would be great. However I continue my research.

Is there any mouse.c description of the windowsside?
Comment 81 Julian Rüger 2008-03-29 23:55:00 CDT
I think its completely irrelevant how windows does it, it can read mouse movement directly from the driver.
Wine however, has to take what X gives us, or get its own mouse driver.
Thats not that easy, as far as I know, because we would have to override X's driver somehow.
The best way would be to get mouse messages from X pretty much, so we know the mouse was moved, even if absolute cursor position did not change.

In window mode for example, the mouse could still leave the window and it could loose focus, that needs some thinking...

But until there is no direct way to get mouse events from X, we cant do anything on this issue.

If I got anything wrong, please corret me ;)
Comment 82 Vitaliy Margolen 2008-03-30 00:35:39 CDT
Created attachment 11735 [details]
winex11.drv: Use ClipCursor to grab/ungrab the pointer

Here are my old 3 patches that moved mouse warping to winex11drv. However they weren't accepted. While first two will take care of keeping mouse inside Wine's windows last one actually does the "magic". However it has a problem - it deadlocks while waiting for the next mouse event.
Comment 83 Vitaliy Margolen 2008-03-30 00:36:16 CDT
Created attachment 11736 [details]
winex11.drv: Process LeaveNotify to ungrab the pointer

Second patch
Comment 84 Vitaliy Margolen 2008-03-30 00:37:00 CDT
Created attachment 11737 [details]
winex11.drv: Virtualize mouse pointer if it's invisible and grabbed

Third patch.
Comment 85 Vitaliy Margolen 2008-03-30 00:38:59 CDT
(In reply to comment #80)
> I took a glance into mouse.c. Can anyone tell me where the mouse uses X events?
winex11.drv/mouse.c
Comment 86 Vitaliy Margolen 2008-03-30 00:42:06 CDT
(In reply to comment #76)
This bug doesn't the oposit does - they always warp mouse which breaks all other games (see bug 1410). dinput should not warp mouse period. Native doesn't do it.
Comment 87 Andrew Charles Hurst 2008-03-30 04:31:01 CDT
Vitaliy,
I'm convinced this (virtual pointer) method should work for fullscreen apps, so if it were restricted to this case, I think the vast majority of dependent bugs would be solved.

Having said that, I've applied your 3 patches to GIT, and the pointer doesn't get warped (although it doesn't deadlock either) in AvP (bug 7613)
Comment 88 Vitaliy Margolen 2008-03-30 20:02:30 CDT
(In reply to comment #87)
> Having said that, I've applied your 3 patches to GIT, and the pointer doesn't
> get warped (although it doesn't deadlock either) in AvP (bug 7613)
> 
There are few requirements for these patches to work:
1. DXGrab have to be enabled (winecfg->Graphics first check-box).
2. The cursor should be invisible/turned off by the application (ex FPS game, not the menu).
3. Optional: remove mouse warping code from the dinput.
Comment 89 Andrew Charles Hurst 2008-04-03 13:28:37 CDT
With points 1 2 and 3 above, the cursor grabbing works well for me.

In windowed apps, however, the mouse event is delvered with a coordinate about 20 pixels above where the pointer was:  could be difference between whole_rect and virtual_screen_rect when a title-bar is drawn?

Also, it still gives zero cursor movement when up against the edge of the window in virtual desktop mode.  - is the cursor actually getting warped?
Comment 90 Steve Chow 2008-04-04 20:24:30 CDT
What version do these latest three patches work with? I've tried CVS & 0.9.58 and some of the hunks fail to patch. Leaving; 
gcc -c -I. -I. -I../../include -I../../include  -D__WINESRC__  -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith  -g -O2  -o mouse.o mouse.c
mouse.c: In function 'X11DRV_LeaveNotify':
mouse.c:1143: error: 'mouse_grabbing_hwnd' undeclared (first use in this function)
mouse.c:1143: error: (Each undeclared identifier is reported only once
mouse.c:1143: error: for each function it appears in.)
mouse.c:1145: error: 'switching_to' undeclared (first use in this function)
mouse.c: At top level:
mouse.c:1155: error: redefinition of 'X11DRV_LeaveNotify'
mouse.c:1133: error: previous definition of 'X11DRV_LeaveNotify' was here
mouse.c: In function 'X11DRV_LeaveNotify':
mouse.c:1165: error: 'mouse_grabbing_hwnd' undeclared (first use in this function)
mouse.c:1167: error: 'switching_to' undeclared (first use in this function)
make: *** [mouse.o] Error 1
Comment 91 Vitaliy Margolen 2008-04-04 20:46:42 CDT
(In reply to comment #90)
> What version do these latest three patches work with?
Old. You can see dates for yourself in each patch.
Comment 92 Vitaliy Margolen 2008-04-09 23:22:39 CDT
*** Bug 12472 has been marked as a duplicate of this bug. ***
Comment 93 Julian Rüger 2008-04-15 21:04:27 CDT
I found out something I think is very interesting:
When you play the game Mafia with native dinput8.dll, it shows this bug.
However, with wine's own dinput8 it works perfectly.

Maybe thats another case where wine does mouse warping when it should not.
Or its something completely different, like windoze does mouse warping in this case, too, in another place/dll, but I think Vitaliy said dinput does not warp mouse at all.
Comment 94 Jonas Aaberg 2008-05-04 03:39:18 CDT
This bug affects Keepsake as well. The game crashes if you by accident move the mouse pointer to another screen, I.E unfocus the game while in fullscreen. 
For work-arounds, see:
http://gentoo-wiki.com/HOWTO_Dual_Monitors

Comment 95 Tobias Jakobi 2008-05-04 08:41:29 CDT
I'm experiencing this problem in AvP1 Alien Demo (see this bug http://bugs.winehq.org/show_bug.cgi?id=12944 for a download link of the demo).

If I have virtual desktop disabled the mouse stops "working" if I move it too far to the right/left/whatever. I'm currently compensating it through angular movement via the keyboard and "finetuning" with the mouse. That's of course horrible to play.

If vdesktop is on I can better see the problem. You can clearly see that the mouse escapes the windows if it's moved too far. As soon as it escapes the window no more input is generated in the game. Upon inserting the cursor into the vdesktop area again input continues.
Comment 96 Vitaliy Margolen 2008-05-10 19:58:56 CDT
*** Bug 13096 has been marked as a duplicate of this bug. ***
Comment 97 Denis Misiurca 2008-05-11 15:23:46 CDT
Created attachment 12943 [details]
Hack to force warping when mouse leaves box (modified)

A small modification of attachment 11303 [details] that activates only if WINEFORCEMOUSEWARP is set.

Tested on Steam version of Unreal II with wine 0.9.61
Comment 98 Mariusz 2008-05-12 14:13:17 CDT
(In reply to comment #97)
> Created an attachment (id=12943) [details]
> Hack to force warping when mouse leaves box (modified)
> 
> A small modification of attachment 11303 [details] that activates only if
> WINEFORCEMOUSEWARP is set.
> 
> Tested on Steam version of Unreal II with wine 0.9.61
> 

Hello. I've tried to apply patch on wine 1.0-rc1 and 09.58 but in both cases I had in console:

can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- dlls/dinput/mouse.c.orig	2008-05-11 18:53:05.000000000 +0300
|+++ dlls/dinput/mouse.c	2008-05-11 23:09:16.000000000 +0300
--------------------------
File to patch: mouse.diff
patching file mouse.diff
Hunk #1 FAILED at 24.
Hunk #2 FAILED at 64.
Hunk #3 FAILED at 188.
Hunk #4 FAILED at 310.
4 out of 4 hunks FAILED -- saving rejects to file mouse.diff.rej

Could you help me with this?

Thank you
Comment 99 Luke Bratch 2008-05-12 14:16:09 CDT
It applies fine in the latest git with -p0
Comment 100 Triffid Hunter 2008-05-13 07:59:14 CDT
patch works for me against 1.0-rc1, now I can play gta3 again! :D
Comment 101 Miguel Gualdino 2008-05-13 09:11:05 CDT
(In reply to comment #100)
> patch works for me against 1.0-rc1, now I can play gta3 again! :D
> 

where can I find a folder with file mouse.c to Ubuntu 8.04?
Comment 102 Mariusz 2008-05-13 10:19:34 CDT
(In reply to comment #97)
> Created an attachment (id=12943) [details]
> Hack to force warping when mouse leaves box (modified)
> 
> A small modification of attachment 11303 [details] that activates only if
> WINEFORCEMOUSEWARP is set.
> 
> Tested on Steam version of Unreal II with wine 0.9.61
> 

I'm not sure if I'm doing it right. When I've applied patches ( 3dmark and yours) on wine 0.9.57 everything compile and built with no problems but mouse is still not warped. Do I have to somehow set WINEFORCEMOUSEWARP? And if then how. Thanks 
Comment 103 Denis Misiurca 2008-05-13 11:06:47 CDT
(In reply to comment #102)

> Do I have to somehow set WINEFORCEMOUSEWARP? And if then
> how. Thanks

WINEFORCEMOUSEWARP=yes wine yourapp.exe
Comment 104 Denis Misiurca 2008-05-13 11:08:35 CDT
(In reply to comment #101)

> where can I find a folder with file mouse.c to Ubuntu 8.04?
> 

Download the source package from packages.ubuntu.com and google how to build debian packages.
Comment 105 Miguel Gualdino 2008-05-13 11:18:15 CDT
(In reply to comment #104)
> (In reply to comment #101)
> 
> > where can I find a folder with file mouse.c to Ubuntu 8.04?
> > 
> 
> Download the source package from packages.ubuntu.com and google how to build
> debian packages.
> 

Thank you very much !
Comment 106 Mariusz 2008-05-14 04:04:00 CDT
(In reply to comment #103)
> (In reply to comment #102)
> 
> > Do I have to somehow set WINEFORCEMOUSEWARP? And if then
> > how. Thanks
> 
> WINEFORCEMOUSEWARP=yes wine yourapp.exe
> 

Thanks for help. The solution is almost perfect. Now turning left is ok in Gothic 3 but turning right is still annoying (spinning around). I believe that its a bit farther on right ( talking about moved screen or "mouse area") so I think it should warp a little bit earlier when character's turning on right or looking down. I can see exactly the edges of mouse working area on left and top edge but right and down is not visible and mouse disappears. I believe that it's about 20 pixels. That's why your workaround is working great for turning left and up but spinning character when down or right. I think if you would be able to force mouse to warp a wee bit earlier on bottom and right edge then solution would be just perfect for gothic as well. Thanks
Comment 107 Mariusz 2008-05-16 12:21:21 CDT
Created attachment 13101 [details]
Hack to warp mouse in Gothic 3 with resolution 1024x768 

This is just a wee bit modified patch of Denis Misiurca. It makes Gothic 3 fully playable ( I mean mouse problem ) in resolution 1024x768. For different resolution it must be modified ( If I will have time I will make it)
On AppDB (Gothic 3) I gave simple solution how to apply this without compiling wine

Marian
Comment 108 Nikita 2008-05-18 09:27:02 CDT
Created attachment 13153 [details]
Mouse hack that wrapping cursor when app starts clipping cursor

This is mouse hack that i use for Lineage II. It can be useful for somebody. 

sory 4 my english.
Comment 109 Nikita 2008-05-18 09:28:01 CDT
Comment on attachment 13153 [details]
Mouse hack that wrapping cursor when app starts clipping cursor

This is mouse hack that i use for Lineage II. It can be useful for somebody.
Comment 110 Vitaliy Margolen 2008-05-24 10:44:38 CDT
*** Bug 13385 has been marked as a duplicate of this bug. ***
Comment 111 unnicked 2008-06-02 14:03:42 CDT
I have this bug in Mandriva 2008.1. I can't play GTA3 without mouse escape from
the window.
My wine version is 1.0-rc3
Comment 112 Hew McLachlan 2008-06-03 02:14:18 CDT
This bug is present in Unreal Tournament 3, and therefore likely to be present in all other Unreal Engine 3 games as well.
Comment 113 unnicked 2008-06-03 10:20:56 CDT
I have this bug in Mandriva 2008.1. I can't play GTA3 without mouse escape from
the window.
My wine version is 1.0-rc3
Comment 114 Roderick Colenbrander 2008-06-15 07:04:20 CDT
*** Bug 13929 has been marked as a duplicate of this bug. ***
Comment 115 Austin English 2008-06-20 13:08:55 CDT
*** Bug 8291 has been marked as a duplicate of this bug. ***
Comment 116 Oisin O Malley 2008-06-20 15:04:49 CDT
*** Bug 14017 has been marked as a duplicate of this bug. ***
Comment 117 Warren Dumortier 2008-06-22 03:27:59 CDT
I also confirm this bug! Please include a patch in wine to fix this, i had liked to have the game working (out-of-the-box, i'm not a patcher) :D
Comment 118 Benjamin Hodgetts 2008-06-22 07:02:42 CDT
The patch wont be included unless it is submitted to Wine Patches AND it is up to the standard that AJ will accept.
Comment 119 Vitaliy Margolen 2008-06-23 19:17:59 CDT
*** Bug 14071 has been marked as a duplicate of this bug. ***
Comment 120 tehblunderbuss 2008-07-14 02:53:53 CDT
Here's another confirmation that the 7774 patch works with "XIII"
Comment 121 Vitaliy Margolen 2008-07-26 22:25:05 CDT
*** Bug 14307 has been marked as a duplicate of this bug. ***
Comment 122 Vitaliy Margolen 2008-07-27 11:22:14 CDT
*** Bug 14655 has been marked as a duplicate of this bug. ***
Comment 123 Dropknee 2008-08-02 14:51:08 CDT
Anyone know what of this patches work for Americas Army, I suffer for the leaving Windows bug and can't rotate the character around. pls help
Comment 124 Lorenzo 2008-08-05 06:46:11 CDT
Has anyone tried one of the patches with Outcast? I tried the latest ones (for the 1024x768 I modified 30 to 15, since in Outcast the resolution is exactly half than that) manually patching my 1.1.2 version of Wine, and none worked, neither fullscreen nor windowed, so if someone else instead managed to get it work I'd be glad to know how...
Comment 125 Valeriy Malov 2008-08-14 14:26:14 CDT
Is Aliens versus Predator 2 still affected to this bug? As far as I tested, it was fixed for this game some versions ago. There is another Bug #12272 instead.
Comment 126 Vitaliy Margolen 2008-08-17 10:28:45 CDT
*** Bug 14890 has been marked as a duplicate of this bug. ***
Comment 127 Vitaliy Margolen 2008-08-20 10:44:49 CDT
Today's GIT added a workaround:
Set [HKCU\Software\Wine\DirectInput] "MouseWarpOverride" to "force" to force mouse warping. It can also be set per application.

Of course the bug is still not fixed.
Comment 128 haarp 2008-08-21 06:31:49 CDT
May I suggest an improvement for the workaround-regedit-setting? Add the option 'force-box' that works like Attachment 11303 [details] and only warps when the mouse is about to leave the box.

The current 'force' works fine for Crysis in-game, but breaks in the menus because the pointer is forced to the middle at all times.
Comment 129 Cristian Dogaru 2008-08-22 01:01:56 CDT
hi Vitality, haarp ...

it seemed that the registry key workaraound was an elegant and simply temporary solution, BUT:

1. the specified registry key DOES NOT EXIST - so i had toi create it manually
2. i assumed "MouseWarpOverride" is a string value - i created this also
3. PROBLEM NOT SOLVED !

(i am using PlayOnLinux for Project IGI)

so, Project IGI still escapes the cursors, even with the above registry edits
did i do smthing wrong? or is there smthing more i should do? maybe i should not use PlayOnLinux ...

thanx a bunch
Comment 130 haarp 2008-08-22 08:52:40 CDT
You need the newest GIT version. 1.1.2 or older won't cut the deal. If you don't know how to compile it yourself from GIT, you "normal" people will have to wait for 1.1.3 then (which is long due btw)
Comment 131 Austin English 2008-08-22 10:37:35 CDT
(In reply to comment #130)
> You need the newest GIT version. 1.1.2 or older won't cut the deal. If you
> don't know how to compile it yourself from GIT, you "normal" people will have
> to wait for 1.1.3 then (which is long due btw)
> 

It'll be out today.
Comment 132 Toni Spets 2008-08-22 11:23:25 CDT
Confirming that Vitaliy's workaround works for Raven Shield.
Comment 133 Cristian Dogaru 2008-08-22 11:24:28 CDT
(In reply to comment #131)
> (In reply to comment #130)
> > You need the newest GIT version. 1.1.2 or older won't cut the deal. If you
> > don't know how to compile it yourself from GIT, you "normal" people will have
> > to wait for 1.1.3 then (which is long due btw)
> > 
> 
> It'll be out today.
> 

yes - i am a "normal" ppl . i am just too lazy to compile wine, when i could just boot to windows.

yes, wine 1.1.3 is HERE.
still, it's not yet listed in PlayOnLinux, which i used to workaround the mouse bug.

yes, i DID find a workaround - i will post it later

cheers everyone
Comment 134 Cristian Dogaru 2008-08-22 11:27:53 CDT
Created attachment 15550 [details]
hacked dinput.dll for wine version 0.9.58 - manages to warp the mouse in Project IGI, Gothic 3 and other games
Comment 135 Cristian Dogaru 2008-08-22 11:30:32 CDT
How to solve the "escaping mouse" issue:

1. Install PlayOnLinux - get it here: http://www.playonlinux.com/en/download.html

2. Install Project IGI INSIDE PlayOnLinux, and make a shortcut to it INSIDE PlayOnLinux

3. Install Wine version 0.9.58 INSIDE PlayOnLinux: Tools -> Manage Wine Versions, select 0.9.58 from the list and click "Add"

4. Download the hacked dinput.dll.so file from:
     a. rapidshare.com/files/115359174/dinput.dll.so
     b. http://bugs.winehq.org/attachment.cgi?id=15550

5. Copy the dinput.dll.so to the folder /home/YOUR-USERNAME-HERE/.PlayOnLinux/WineVersions/0.9.58/usr/lib/wine

6. Open the folder /home/YOUR-USERNAME-HERE/.PlayOnLinux/configurations/installed - you should see a file named as your shortcut created at step 3 above

7. Open the shortcut to Project IGI and add the following line just below the other "export" lines:

export WINEFORCEMOUSEWARP=yes

8. save the file

9. Run the game

10. Enjoy!


Comment 136 Vitaliy Margolen 2008-08-22 19:22:44 CDT
(In reply to comment #135)
> How to solve the "escaping mouse" issue:
> 
> 1. Install PlayOnLinux - get it here:
> http://www.playonlinux.com/en/download.html
Please keep such recipes away from Wine bugzilla! Use latest Wine version.
Comment 137 Cristian Dogaru 2008-08-23 00:14:57 CDT
(In reply to comment #136)
> (In reply to comment #135)
> > How to solve the "escaping mouse" issue:
> > 
> > 1. Install PlayOnLinux - get it here:
> > http://www.playonlinux.com/en/download.html
> Please keep such recipes away from Wine bugzilla! Use latest Wine version.
> 

sorry for my undoing

however, this workaround DOES NOT work with wine 1.1.2 (did not try with 1.1.3), and since people have been complaining about it since like forever, i thought i added my suggestions about how to make things work.

if there's smthing wrong with my posts, admins please feel free to delete it, or just the part that offends you.

regards,
Cristi
Comment 138 Vitaliy Margolen 2008-08-23 00:36:53 CDT
> however, this workaround DOES NOT work with wine 1.1.2 (did not try with
> 1.1.3)
Of course it did not work! I can go back in time 1 month and change Wine source then. The change was done only 2 days ago! And that is _EXACTLY_ what I said:
"Today's GIT added a workaround:"

If you blind or can't read then please don't post here at all!
Comment 139 Lorenzo 2008-08-23 02:19:30 CDT
Just tried the 1.1.3 on Outcast with the MouseWarpOverride force: the value seems to work, even if the rotation of the main character is often too fast (mouse sensibility is not the cause) which somehow spoils the gaming experience.

I can also confirm that, as haarp noticed with Crysys, the starting game menu is very hard to navigate with the MouseWarpOverride forced on.
Comment 140 Tobias Stegmann 2008-08-23 05:41:05 CDT
I just got the wine-1.1.3 update from the wine Launchpad PPA.

Neither in wincfg, nor in any registry file I'm able to find sth like MouseWarpOverride.

I'm using the amd64 version, is in this case a difference to 32bit wine?
Comment 141 Tobias Jakobi 2008-08-23 05:56:54 CDT
You won't find it in winecfg because it's not exported there. It's a feature that is only exposed in the registry, see:
http://wiki.winehq.org/UsefulRegistryKeys

And like every other special key there it has to be created.
Comment 142 Reyn 2008-08-23 06:52:50 CDT
I confirm that Vitaliy's workaround works.
To make it work, I 
1. ran regedit
2. found [HKCU\Software\Wine\]
3. added key "DirectInput"
4. in  "DirectInput" added new string value "MouseWarpOverride" 
5. set its value to "force".

The problem only that this workaround does work for some games that uses both fp view and menu, because it forces mouse to middle of the screen in menu.
It would be good to have "force-box" option as it was told above. 
Comment 143 Mamede 2008-08-23 07:12:42 CDT
"MouseWarpOverride"  Solution Didn't work for America's Army 2.8.3. I tried to change mouse.c according to the patches presented, still I can only rotate 180º and not 360º. Any more ideas?
Comment 144 Mamede 2008-08-23 07:24:18 CDT
(In reply to comment #143)
> "MouseWarpOverride"  Solution Didn't work for America's Army 2.8.3. I tried to
> change mouse.c according to the patches presented, still I can only rotate
> 180º and not 360º. Any more ideas?
> 

However the PlayonLinux thing with 0.9.58 works.
Is there a git that should solve this?
Comment 145 Tobias Stegmann 2008-08-23 07:40:42 CDT
(In reply to comment #143)
> "MouseWarpOverride"  Solution Didn't work for America's Army 2.8.3. I tried to
> change mouse.c according to the patches presented, still I can only rotate
> 180º and not 360º. Any more ideas?
> 

hmm it works for me with 2.8.3 Americas Army (thanks to Tobias ;) ), but PunkBuster kicks me due to sth. about "unknown Windows API command".

I'll file a bug for this issue tonight.
Comment 146 Toni Spets 2008-08-23 08:10:50 CDT
(In reply to comment #145)
> (In reply to comment #143)
> > "MouseWarpOverride"  Solution Didn't work for America's Army 2.8.3. I tried to
> > change mouse.c according to the patches presented, still I can only rotate
> > 180º and not 360º. Any more ideas?
> > 
> 
> hmm it works for me with 2.8.3 Americas Army (thanks to Tobias ;) ), but
> PunkBuster kicks me due to sth. about "unknown Windows API command".
> 
> I'll file a bug for this issue tonight.
> 

Please don't. It's already there:

http://bugs.winehq.org/show_bug.cgi?id=9685
Comment 147 Mamede 2008-08-23 09:56:36 CDT
(In reply to comment #145)
> (In reply to comment #143)
> > "MouseWarpOverride"  Solution
> hmm it works for me with 2.8.3 Americas Army (thanks to Tobias ;) ), 

Only with the registry option? What version of wine are you using?

Comment 148 Tobias Stegmann 2008-08-23 10:17:59 CDT
> Please don't. It's already there:
So I won't. ;)

(In reply to comment #147)
> (In reply to comment #145)
> > (In reply to comment #143)
> > > "MouseWarpOverride"  Solution
> > hmm it works for me with 2.8.3 Americas Army (thanks to Tobias ;) ), 
> 
> Only with the registry option? What version of wine are you using?
> 

The registry option + 'Allow DirectX apps to stop the mouse leaving their window' enabled with winecfg works with wine-1.1.3 amd64 and AA 2.8.3 (except the PB issue)
Comment 149 Ambro 2008-08-23 10:29:31 CDT
The MouseWarpOverride=force doesn't work for Crysis. Using this option with Wine 1.1.3 locks the cursor in the menu into the middle of the screen, and whenever I move the mouse, it moves a little and jumps back. Without the registry value it behaves the same way as previous Wine versions without the patch (which worked).
Comment 150 haarp 2008-08-23 10:37:58 CDT
(In reply to comment #149)
> The MouseWarpOverride=force doesn't work for Crysis. Using this option with
> Wine 1.1.3 locks the cursor in the menu into the middle of the screen, and
> whenever I move the mouse, it moves a little and jumps back. Without the
> registry value it behaves the same way as previous Wine versions without the
> patch (which worked).
> 

Yes. see comment 128 for a possible improvement. In the meantime, navigate the menus with the keyboard.
Comment 151 Mariusz 2008-08-23 11:53:38 CDT
Look at my comment #107 and go to appdb gothic 3 for "mouse problem temporary solved" comment. This way is working 100%. and you don't have to change registry to do it. Sometimes this week I will provide another dinput.dll.so for 1.1.3 wine. PlayOnLinux way is using this dll which I provide so it's working like the others confirmed. I tried first solution but it's holding mouse in the center in menu. Denis Misiurca way it looks better, I only made dll and changed few bits.
Comment 152 Mamede 2008-08-23 12:20:51 CDT
(In reply to comment #151)
> Look at my comment #107 and go to appdb gothic 3 for "mouse problem temporary
> solved" comment. This way is working 100%. and you don't have to change
> registry to do it. Sometimes this week I will provide another dinput.dll.so for
> 1.1.3 wine. PlayOnLinux way is using this dll which I provide so it's working
> like the others confirmed. I tried first solution but it's holding mouse in the
> center in menu. Denis Misiurca way it looks better, I only made dll and changed
> few bits.
> 

It's working now. I kinda messed up in with instation I setted --prefix but wine ended up going to /usr/bin one. It's working ty.
Comment 153 Cristian Dogaru 2008-08-24 08:06:37 CDT
(In reply to comment #138)
> > however, this workaround DOES NOT work with wine 1.1.2 (did not try with
> > 1.1.3)
> Of course it did not work! I can go back in time 1 month and change Wine source
> then. The change was done only 2 days ago! And that is _EXACTLY_ what I said:
> "Today's GIT added a workaround:"
> 
> If you blind or can't read then please don't post here at all!
> 

vitality, i am new to linux (2 weeks), therefore new to wine, so i don't really know what a GIT is.

as i said, admins please free to delete my messages or part of them, in case they offend someone, or are out of the picture.

i wish i could delete your offending message
i'll just pretend i am INDEED blind to it :))


glad to see in further comments that the PlayOnLinux workaround works for others too. at least it's USEFUL.

vitality, have a nice day and don't be blind to the needs of others :)
Comment 154 Dan Kegel 2008-08-24 09:09:19 CDT
Hi Cristian,
we cannot delete or edit messages in bugzilla.  It's a bug tracking
system, not a user support forum.  That's why we discourage
user discussion in bug reports; if you want to talk about
workarounds, the appdb is the place.
Comment 155 Brian Vuyk 2008-08-25 14:47:29 CDT
(In reply to comment #150)
> (In reply to comment #149)
> > The MouseWarpOverride=force doesn't work for Crysis. Using this option with
> > Wine 1.1.3 locks the cursor in the menu into the middle of the screen, and
> > whenever I move the mouse, it moves a little and jumps back. Without the
> > registry value it behaves the same way as previous Wine versions without the
> > patch (which worked).
> > 
> 
> Yes. see comment 128 for a possible improvement. In the meantime, navigate the
> menus with the keyboard.
> 

It also locks the mouse to the center on the menus in World War II Online. Unfortunately, in this game there is no mouse menu navigation. 

If it's possible to implement, the force-box suggestion sounds good. 
Comment 156 Brian Vuyk 2008-08-25 14:51:10 CDT
> It also locks the mouse to the center on the menus in World War II Online.
> Unfortunately, in this game there is no mouse menu navigation. 
> 
> If it's possible to implement, the force-box suggestion sounds good. 
> 

Oops - meant to say 'keyboard menu navigation' above.

Comment 157 James Jurack 2008-08-25 14:59:30 CDT
(In reply to comment #156)
> > It also locks the mouse to the center on the menus in World War II Online.
> > Unfortunately, in this game there is no mouse menu navigation. 
> > 
> > If it's possible to implement, the force-box suggestion sounds good. 
> > 
> 
> Oops - meant to say 'keyboard menu navigation' above.
> 

This is also the case for Mount&Blade. I think that the force-box would likely be more useful in this game's case as well.
Comment 158 Vitaliy Margolen 2008-08-25 15:52:21 CDT
>If it's possible to implement, the force-box suggestion sounds good. 

That won't be as simple as you think. If the mouse pointer leaves Wine's window - it's lost. Wine won't be receiving events from it and won't be warping it.

The only possibility that I can think of is to fix DXGrab first. Then you can warp mouse on the border. Given you might loose some long movements, which will negatively affect action games.
Comment 159 Brian Vuyk 2008-08-25 16:22:06 CDT
Created attachment 15638 [details]
Proposed mouse improvement for 'stuck menu problem
Comment 160 Brian Vuyk 2008-08-25 16:30:19 CDT
(In reply to comment #159)
> Created an attachment (id=15638) [details]
> Proposed mouse improvement for 'stuck menu problem
> 

I meant to include this as a comment to that attachment...

Patch is made against the latest git commit.

I've taken Joe McKort's idea (http://bugs.winehq.org/attachment.cgi?id=11303) and added it into the new mouse code.

With this patch, instead of warping back to center on every mouse movement when  mouse warp is forced, it only warps when it gets within 2 pixels of the edge of the window. 

I've tested this with World War II Online, and it works well - the first person view is flawless, and the menu system is navigable. I imagine it will work with Crysis and other games currently having this problem.

On the down side, if your mouse pointer hits the edge of the screen in the menu system, it will still warp to center. So it's an improvement, but it isn't flawless yet.

Comments?
Comment 161 SheeEttin 2008-08-25 17:06:42 CDT
I have a question, rather than a comment...
Do any of these hack patches break other apps?
I regularly apply Toni Spets' patch (the first one) when I upgrade Wine, and I've never seen an app broken by this. (I always run with an emulated desktop, so that may affect what I see.)

If these patches don't break anything, I'm curious (baffled, really) as to why they haven't been integrated with a release yet.
Comment 162 Vitaliy Margolen 2008-08-25 18:03:52 CDT
(In reply to comment #161)
> Do any of these hack patches break other apps?
Yes they do. For example see bug 1410 for what will happen of you always warp mouse pointer. And bug 8354 for what still happens now.

Obviously these two problems are opposites of each other. The only way to fix them both would be to:
1. Never warp mouse
2. Receive mouse movement events from actual hardware / X server
3. When mouse acquired in exclusive mode, stop pointer from moving

Any other variations won't be enough.
Comment 163 Toni Spets 2008-08-26 02:31:29 CDT
Comment on attachment 7774 [details]
Hack to force mouse warping

Obsoleted by Vitaliy's recent commit which was released in 1.1.3.

Please update or add a HOWTO to all apps that do work with this particular workaround.
Comment 164 kfs1 2008-08-26 09:39:11 CDT
"2. Receive mouse movement events from actual hardware / X server"

Ok, so this might be wildly inaccurate but is provided in the event it checks out...: If wine sat 'xset m 0/0'(that i think, sets the mouse to no artificial acc at all) on startup would not wine be able to get accurate mouse readings?

This is what, atleast pro gamers, want anyway because its easier to aim and better to set acc & speed in-game. So if this is possible... :)
Comment 165 Vitaliy Margolen 2008-08-26 10:20:44 CDT
That doesn't work for the pointer that stuck in the corner. Mouse keeps moving. But pointer not.
Comment 166 Turerkan 2008-08-27 14:50:57 CDT
the problem is solved in here:

http://appdb.winehq.org/objectManager.php?sClass=version&iId=5444

it works flawlessly, without affecting the game play or menus..
Comment 167 Vitaliy Margolen 2008-08-27 20:15:47 CDT
(In reply to comment #166)
> the problem is solved in here:
> 
> http://appdb.winehq.org/objectManager.php?sClass=version&iId=5444
> 
> it works flawlessly, without affecting the game play or menus..
> 

That is the binary. Please provide the source.
Comment 168 Reyn 2008-08-28 12:11:30 CDT
(In reply to comment #166)
> the problem is solved in here:
> 
> http://appdb.winehq.org/objectManager.php?sClass=version&iId=5444
> 
> it works flawlessly, without affecting the game play or menus..
> 

I wonder which games except RO it works for.
For Mount&Blade it works the same way as Vitaliy's workaround. I.e. it makes impossible to navigate in menu.
So i suppose that the principle the same but hack some how detect menu mode (it seems that works only for some games) and off force mouse warping.


Comment 169 Rasto S 2008-09-04 04:14:59 CDT
(In reply to comment #168)
> (In reply to comment #166)
> > the problem is solved in here:
> > 
> > http://appdb.winehq.org/objectManager.php?sClass=version&iId=5444
> > 
> > it works flawlessly, without affecting the game play or menus..
> > 
> 
> I wonder which games except RO it works for.
> For Mount&Blade it works the same way as Vitaliy's workaround. I.e. it makes
> impossible to navigate in menu.
> So i suppose that the principle the same but hack some how detect menu mode (it
> seems that works only for some games) and off force mouse warping.
> 

Same for WWIIOnline. No improvement. 
Comment 170 Brian Vuyk 2008-09-04 07:47:49 CDT
Rasto, Reyn, and others

Can you test the <a href='http://bugs.winehq.org/attachment.cgi?id=15638'>patch I posted in #160?</a> I would like to know if it works in the other games mentioned (Mount & Blade, RO etc.). It definitely works in WWIIOnline for me.

It minorly changes the mouse warp code so that when warping, instead of warping whenever the mouse moves slightly off center, it warps when the mouse hits the edge of the wine screen.

The end result is no more 'stuck-mouse' problem; you have free range of motion within the wine screen. However, the mouse will still warp if you hit the absolute edge of the screen.

Is there a good reason why the mouse should be not be allowed to go off center when warping rather than being allowed to the edge of the screen? I can't see where it would make a different in first-person views, since the mouse cursor is hidden. Are there situations that I may not be taking into account?
Comment 171 Vitaliy Margolen 2008-09-04 11:29:45 CDT
(In reply to comment #170)
> Is there a good reason why the mouse should be not be allowed to go off center
> when warping rather than being allowed to the edge of the screen? I can't see
> where it would make a different in first-person views, since the mouse cursor
> is hidden. Are there situations that I may not be taking into account?

See my previous replies. You can't do that without using DXGrab.

If you wait for mouse to be withing 2px of the border before you warp:
1. You will loose part of the long pointer motion (say 100px while pointer is 10px away from the border). This will be felt like "sticking" mouse in action games.
2. In 99% cases you will loose the pointer itself (it will go off the Wine's window). This means number of bad things. The biggest one - Wine won't be receiving any pointer movement events at all. And nothing will be warping that pointer.
3. You still not solving the problem with "edge-scrolling" used in some games to scroll screen when you move mouse "past the edge".
Comment 172 Brian Vuyk 2008-09-04 12:00:19 CDT
(In reply to comment #171)
> (In reply to comment #170)
> > Is there a good reason why the mouse should be not be allowed to go off center
> > when warping rather than being allowed to the edge of the screen? I can't see
> > where it would make a different in first-person views, since the mouse cursor
> > is hidden. Are there situations that I may not be taking into account?
> 
> See my previous replies. You can't do that without using DXGrab.
> 
> If you wait for mouse to be withing 2px of the border before you warp:
> 1. You will loose part of the long pointer motion (say 100px while pointer is
> 10px away from the border). This will be felt like "sticking" mouse in action
> games.
> 2. In 99% cases you will loose the pointer itself (it will go off the Wine's
> window). This means number of bad things. The biggest one - Wine won't be
> receiving any pointer movement events at all. And nothing will be warping that
> pointer.
> 3. You still not solving the problem with "edge-scrolling" used in some games
> to scroll screen when you move mouse "past the edge".
> 

Hi Vitaliy.

Ah yes - I hadn't thought about edge scrollers. 

However, to address your other two points,

1. I haven't noticed any 'sticking' sensation in the games I've tested this patch with.
2. Never lost the pointer. 

Finally, edge scrollers are no good under the current system as it is, if they have the mouse stuck to center or confined to the window. However, this will make it somewhat playable if they have keyboard controls to move / pan the screen as opposed to mouse only control.

It's not a perfect solution (never did I claim this), but I think it's improves this bug in that it makes apps suffering from it somewhat more playable, and will not (AFAIK) affect apps not suffering from this bug.

Comment 173 Toni Spets 2008-09-04 13:11:37 CDT
(In reply to comment #172)
> 
> Finally, edge scrollers are no good under the current system as it is, if they
> have the mouse stuck to center or confined to the window. However, this will
> make it somewhat playable if they have keyboard controls to move / pan the
> screen as opposed to mouse only control.
> 
> It's not a perfect solution (never did I claim this), but I think it's improves
> this bug in that it makes apps suffering from it somewhat more playable, and
> will not (AFAIK) affect apps not suffering from this bug.
> 

The bug works differently for different apps. For example in Raven Shield the mouse is confined in a small box inside the wine window and will jump off the wine screen too early and the menus are not usable because you can't click anything there. The pointer works fine in-game though.

The warping workaround thats committed is not keeping the mouse pointer at the center in Raven Shield menu, it works with this patch and is not confined in a box. However in-game it's of course kept at the center but it has it's flaws too. I can move my mouse fast enough that wine can't get the movement event and it jumps off the window but it's a minor problem, probably with your patch it would jump off the screen with lower speed if the cursor is too fast and skips the few pixels on the sides where it would be warped back.

Your improvement is probably working for some apps but it would need to be a new value for the registry key so the old "force" would work for example Raven Shield.

Vitaliy any comments on this?
Comment 174 Rasto S 2008-09-05 09:19:14 CDT
(In reply to comment #170)
> Rasto, Reyn, and others
> 
> Can you test the <a href='http://bugs.winehq.org/attachment.cgi?id=15638'>patch
> I posted in #160?</a> I would like to know if it works in the other games
> mentioned (Mount & Blade, RO etc.). It definitely works in WWIIOnline for me.
> 
> It minorly changes the mouse warp code so that when warping, instead of warping
> whenever the mouse moves slightly off center, it warps when the mouse hits the
> edge of the wine screen.
> 
> The end result is no more 'stuck-mouse' problem; you have free range of motion
> within the wine screen. However, the mouse will still warp if you hit the
> absolute edge of the screen.
> 
> Is there a good reason why the mouse should be not be allowed to go off center
> when warping rather than being allowed to the edge of the screen? I can't see
> where it would make a different in first-person views, since the mouse cursor
> is hidden. Are there situations that I may not be taking into account?
> 

I tried it, it works in WWIIOnline. Unless it breaks something, I would consider it a good temporary fix. I suppose the problem might be with games, that don't grab the mouse and use edge-scrolling?
Comment 175 Reyn 2008-09-05 15:47:40 CDT
(In reply to comment #170)
> Rasto, Reyn, and others
> 
> Can you test the <a href='http://bugs.winehq.org/attachment.cgi?id=15638'>patch
> I posted in #160?</a> I would like to know if it works in the other games
> mentioned (Mount & Blade, RO etc.). It definitely works in WWIIOnline for me.
> 


I've applied your hack to 1.1.4. And yes it works fine in Mount & Blade. 
Thanks :)
Comment 176 ChaosCode 2008-09-18 17:35:33 CDT
I dont know if anyone have though of this yet and I hate to be a newb on my first post. I have had things like this come up in my own personal coding projects and I'm very lazy so I just made the screen slightly larger then the display area to counter act the edge effect. **shrugs**
Comment 177 haarp 2008-09-18 17:42:41 CDT
As far as I understand it, the screen would have to be infinitely large. Doesn't work
Comment 178 ChaosCode 2008-09-18 17:55:50 CDT
from what I understand the mouse wouldnt go beyond the desktop edge for the os but would still be tracked correctly by app? I'm not sure I don't have experence with wine.
Comment 179 Austin English 2008-09-29 18:40:30 CDT
*** Bug 15476 has been marked as a duplicate of this bug. ***
Comment 180 Forest Hale 2008-10-06 06:42:08 CDT
Why does wine not use XF86DGADirectMouse?  It seems like an exact equivalent to DirectInput's mouse handling...

Here's an example call to turn it on:
XF86DGADirectVideo(display, screen, XF86DGADirectMouse);
(where display is the Display and screen is the Screen)

Using it locks the pointer in place, receives raw relative motion from the driver (no acceleration or other handling), and ignores focus events entirely (I.E. keeps a grab), obviously this functionality requires xorg, it's not present on __APPLE__ or __SUNOS__.

I hope I'm not wasting anyone's time with this question, just wanted to make sure this functionality is known, I've been using this approach in my DarkPlaces Quake engine for years with great success.
Comment 181 kfs1 2008-10-08 21:10:22 CDT
This is also not a problem in dosbox with games requiring a mouse..
Comment 182 Tobias Jakobi 2008-10-10 09:07:27 CDT
I think some time ago all DGA (and DGA2) support was ripped out of the wine source.

I don't know why this happened, but since DGA is now considered deprecated anyway I don't think any of this code will return. Most likely the input issues are finally fixed when XInput2 hits the road. However this is still going to take some time.

Can anyone (from the input devs) comment on the DGA "story"?
Comment 183 Vitaliy Margolen 2008-10-10 11:20:26 CDT
Most video drivers do not support DGA anymore. And most distros disabled/removed it from default Xorg configuration. DGA also required additional access to memory and other resources that considered a bad thing now. So even if you enable it in xorg it won't run in most setups.

So for all practical purposes DGA is dead.
Comment 184 Forest Hale 2008-10-17 17:40:40 CDT
That is incorrect.

DGA shared memory video was deprecated because it required superuser privileges (essentially it mapped the video memory into application memory space, so that a game could draw stuff at the fastest possible speed, provided that the window was completely uncovered).

In essence, it was useless for security reasons.

DGA mouse grab has never been deprecated, and is still fully supported in most xorg input modules (evdev did not support it until recently though).

I don't see any reason that DGA mouse grab would ever be deprecated without a better replacement, and as long as it does work we should use it (it is a queryable extension after all).
Comment 185 Mirek Slugen 2008-11-08 19:42:30 CST
Created attachment 17157 [details]
Patch for mouse problems in Fallout 3

I have patch for all mouse problems in Fallout 3. Sadly it is just hack, but it should resolve those issues:
+ mouse click on buttons in menu
+ mouse click on buttons in game computer (on left hand)
+ mouse move in menu
+ mouse escapes window in menu

How-to use it:
Apply patch, recompile wine, and set this in registry:
"MouseWarpOverride"="enable"
or
"MouseWarpOverride"="force"

Enable is default behavior so it should work out of box!

Patch is for wine 1.1.8

PS: You should set option bBackground Mouse to 0 in fallout.ini
Comment 186 Mirek Slugen 2008-11-08 19:56:44 CST
(In reply to comment #185)
> Created an attachment (id=17157) [details]
> Patch for mouse problems in Fallout 3
> 
> I have patch for all mouse problems in Fallout 3. Sadly it is just hack, but it
> should resolve those issues:
> + mouse click on buttons in menu
> + mouse click on buttons in game computer (on left hand)
> + mouse move in menu
> + mouse escapes window in menu
> 
> How-to use it:
> Apply patch, recompile wine, and set this in registry:
> "MouseWarpOverride"="enable"
> or
> "MouseWarpOverride"="force"
> 
> Enable is default behavior so it should work out of box!
> 
> Patch is for wine 1.1.8
> 
> PS: You should set option bBackground Mouse to 0 in fallout.ini
> 

I am sorry but this patch can break some other games, detection of menu is real hack, if we can detect menu better please tell me, and i will fix it.
Comment 187 Aurimas 2008-11-12 05:50:13 CST
(In reply to comment #186)
> (In reply to comment #185)
> > Created an attachment (id=17157) [details] [details]
> > Patch for mouse problems in Fallout 3
> 
> I am sorry but this patch can break some other games, detection of menu is real
> hack, if we can detect menu better please tell me, and i will fix it.
> 

Suggestion:
Make menu detection manual.
If ScrollLock is on use one behavior (that works in menu)
else use another behavior (that works in game)
Or vice versa.

I don't think that ScrollLock is widely (if at all) used in games, so toggling it shouldn't break anything.
Comment 188 Austin English 2008-11-15 13:00:07 CST
*** Bug 16067 has been marked as a duplicate of this bug. ***
Comment 189 kfs1 2008-11-17 11:58:20 CST
this is additional information to Foresh Hale's post above:

also xinput 2 is postponed: http://www.phoronix.com/scan.php?page=news_item&px=Njg1Nw ...
Comment 190 Mirek Slugen 2008-11-18 01:00:44 CST
Created attachment 17342 [details]
Patch for mouse problems in Fallout 3  (ver. 2)

Patch for mouse problems in Fallout 3 (ver. 2)

Newely fixed issue: Lockpick problems, If you want to lockpick you should bush mouse button and move mouse, it should work now, normal lockpick without mouse button is not working yet.
Comment 191 Vitaliy Margolen 2008-11-19 19:51:35 CST
*** Bug 16119 has been marked as a duplicate of this bug. ***
Comment 192 Vitaliy Margolen 2008-11-19 20:13:45 CST
*** Bug 16106 has been marked as a duplicate of this bug. ***
Comment 193 Sebastian Mikulec 2008-11-30 20:11:33 CST
(In reply to comment #190)
> Created an attachment (id=17342) [details]
> Patch for mouse problems in Fallout 3  (ver. 2)
> 
> Patch for mouse problems in Fallout 3 (ver. 2)
> 
> Newely fixed issue: Lockpick problems, If you want to lockpick you should bush
> mouse button and move mouse, it should work now, normal lockpick without mouse
> button is not working yet.
> 

The patch fails to keep my cursor from leaving the screen although it does allow me to keep turning when the mouse reaches the edge of the screen on the other side (I have a twinview setup so even in "full screen" I have desktop on one side).  The patch also however breaks my gamepad controls in GTA: Vice City.
Comment 194 haarp 2008-12-22 12:40:22 CST
Vitaliy, is there any chance of us getting a force-box option like suggested in comment 128? This would really benefit a couple of games that use dinput in their menus aswell, like Crysis for example.
Comment 195 Austin English 2008-12-22 13:23:41 CST
(In reply to comment #194)
> Vitaliy, is there any chance of us getting a force-box option like suggested in
> comment 128? This would really benefit a couple of games that use dinput in
> their menus aswell, like Crysis for example.
> 

Hell, just change the 'Allow DirectX apps to stop mouse from leaving their window' option to this...it hasn't worked in years anyway.
Comment 196 haarp 2008-12-22 13:29:23 CST
(In reply to comment #195)

> Hell, just change the 'Allow DirectX apps to stop mouse from leaving their
> window' option to this...it hasn't worked in years anyway.

That's different. Crysis' problem is that in the menu, the mouse is forced into the middle because the 'force' option is permanently active. It won't even go near the the window edge.
That's where force-box would help, only activating when needed (mouse near edge)
Comment 197 Austin English 2008-12-22 14:40:07 CST
(In reply to comment #196)
> (In reply to comment #195)
> 
> > Hell, just change the 'Allow DirectX apps to stop mouse from leaving their
> > window' option to this...it hasn't worked in years anyway.
> 
> That's different. Crysis' problem is that in the menu, the mouse is forced into
> the middle because the 'force' option is permanently active. It won't even go
> near the the window edge.
> That's where force-box would help, only activating when needed (mouse near
> edge)
> 

No. I'm saying remove that option from winecfg and replace it with the force hack.
Comment 198 Vitaliy Margolen 2008-12-23 08:54:28 CST
(In reply to comment #194)
That won't work. Mouse will escape especially in FPS type of games where mouse moves are fast and long.

The combination of fixing PointerGrab and this might work.

(In reply to comment #197)
See comment #82 and comment #83. Don't know if those patches still apply to current GIT.
Comment 199 Tomasz Sałaciński 2008-12-28 10:37:40 CST
Anything new on this? I've tried to patch it, almost did it. Tried under Star Wars: Knights of the Old Republic.

The problem is, that mouse warping SHOULD be done by winex11.drv.

The other problem is, that it cannot be in fixed positoin on the middle of the screen, because most games won't work (like KOTOR, we cannot rely on some function that one game does but other not). Workaround for all games seems to me like that:

If I move the cursor outside the virtual desktop, game is not receiving any mouse events - that's good. Warping mouse all the time will break normal applications running in virtual desktop mode (for example, if user will click the titlebar and try to drag the window outside of the desktop - mouse will jump back to the middle and confuse the user)

If I right-click and try to turn, mouse cursor disappears, and the game is receiving events event if the mouse cursor is outside of the game's screen (checked it - MotionNotify event in winex11.drv - dumps mouse position on every move).

There's how I did it:

Game window size is 1024x768. If the x coordinate of mouse pointer is > 1024, then XWarpPointer moves it back to 1024 - it gives smooth turn in KOTOR (moving it to the middle of the screen, eg. 512 makes turning choppy, because the game thinks that user moved the mouse back to 512). The same with x < 0, if it reaches value less than zero it jumps back to 0. Thanks to that, mouse look is smooth in this game, user can scroll 360 ten times without moving mouse back to the view. Mouse events are received only when mouse is grabbed, so it won't affect normal desktop apps, and in the menu, mouse will just stop when it reaches the edge of the screen (winex11.drv will stop it, not the xserver).

There is one disadvatange, though:
It works only, when the desktop window is on the middle of the screen. When it is in fullscreen mode, mouse touches physical edge of the screen, thus it's not receiving events (actually it is, but mouse moves by 4 pixels only - seems that it's the window border). So, the movement is slow, but still works.

X will not send events if mouse pointer moves outside the desktop.

So, my patch is almost done, but it needs one thing:

- X should send mouse events to WINE even if the pointer goes x = -112 (this happens when the virtual desktop window is on the middle of the screen - -112 is relative to the virtual desktop window) - IMHO best solution
- Fullscreen apps should have bigger border - it won't be visible on fullscreen apps, but will allow to receive mouse events. One disadvatange: won't work in virtual desktop mode placed on the left side of the screen.

I've made a lot of testing yesterday, so I think this approach will be the best one. Warping mouse all the time (especially to the middle of the window) will break a lot of desktop apps.
Comment 200 Tomasz Sałaciński 2008-12-28 11:03:41 CST
Update:

The game Pariah IS grabbing the mouse. Just try the demo:

http://www.fileshack.com/file.x/7324/Pariah+Singleplayer+Demo

I've tested it and confirmed on Windows XP Professional. Just go to Video Options->Advanced->Windowed mode. When in menu, the mouse is not grabbed. When the game loads, the mouse IS grabbed and user cannot move it outside of the game's screen (needs to alt-tab). On WINE, mouse just goes out of the game's window (as on windows, but in the game's menu). Pariah is touching the mouse pointer and it is grabbing it. At some point, WINE should grab the mouse.

So, the approach WINE developers took is ok, but avoiding mouse grabbing is too restrictive. I'll try to discover what function is making the grab.
Comment 201 Jan Zerebecki 2009-01-05 15:43:03 CST
I included a modified version (option to enable it) of attachment 15638 [details] which is based on attachment 11303 [details] in the hacks repo. It is similar to attachment 12943 [details] and attachement 13101 (it uses 30px instead of 2; is this useful?). A similar patch is also included in attachment 17157 [details] and attachment 17342 [details] . So that means the only patches it's not related to are attachment 13153 [details] and Vitaliy Margolen his patches.

http://repo.or.cz/w/wine/hacks.git?a=commitdiff;h=refs/patches/master/dinput_mouse_warp
Comment 202 Tomasz Sałaciński 2009-01-05 15:56:30 CST
@Jan

Any patch that won't work automatically will be IMHO rejected. Pariah needs warping only when in game, the same with KOTOR - warping needs to work only when user will press and hold RMB. AFAIK these games are using NONEXCLUSIVE mode, so it means they are taking control over the mouse but they allow other applications to work with it (so you can alt-tab).
Comment 203 kemelzaidan 2009-01-05 16:59:58 CST
Created attachment 18509 [details]
terminal output for SWAT4 game
Comment 204 Mariusz 2009-01-06 05:37:21 CST
(In reply to comment #201)
> I included a modified version (option to enable it) of attachment 15638 [details] which
> is based on attachment 11303 [details] in the hacks repo. It is similar to attachment
> 12943 [details] and attachement 13101 (it uses 30px instead of 2; is this useful?). A
> similar patch is also included in attachment 17157 [details] and attachment 17342 [details] . So
> that means the only patches it's not related to are attachment 13153 [details] and
> Vitaliy Margolen his patches.
> 
> http://repo.or.cz/w/wine/hacks.git?a=commitdiff;h=refs/patches/master/dinput_mouse_warp
> 


The 30px instead of 2 is there because in Gothic 3 mouse still goes out of edge on right side which causes character to spin. I have tested (played whole game) and with resolution 1024x768 it seems to do the work perfectly. Problem is only that this is just workaround. It looks like the screen it self is moved to bottom right compare with actual (visible) screen and that why mouse is in wrong position. You can notice this sometimes when game crashes or loads.
Comment 205 Vitaliy Margolen 2009-01-06 09:22:43 CST
*** Bug 16819 has been marked as a duplicate of this bug. ***
Comment 206 Daniel Scharrer 2009-01-13 11:42:54 CST
Created attachment 18681 [details]
Hack to read raw mouse movement from /dev/input/mice

I know XInput 2.0 will make this all obsolete, but being impatient I created a hack that somewhat works with Star Wars: Knights of the Old Republic:
- I'm guessing this is Linux specific and won't work on Mac and *BSD.
- Obviously you need read access to /dev/input/mice, which at least on my distro you don't have by default.
- Moving the mouse when right clicked works as expected even when leaving the window / hitting the edge of the screen.
- However, at least with SW:KOTR, when releasing the right mouse button while the cursor is over the window (well, it's hidden) the game locks up until you left-click the window. When the mouse is not over the window while releasing the RMB everything works fine.
Removing the read(...) from line 318 fixes this, but obviously makes the patch useless.

I'm guessing the input hook is the wrong place to read the mouse from, but at least it ensures the mouse movement is properly updated (minimize overflows) and prevents unnecessary read()'s like you would get when placing the read() directly into SysMouseAImpl_GetDeviceState().
Comment 207 Mikael Åkersund 2009-01-14 09:02:11 CST
(In reply to comment #185)
> Created an attachment (id=17157) [details]
> Patch for mouse problems in Fallout 3
> 

Bethseda just released a Fallout 3 patch (1.1.0.35) which amazingly fixes this bug for FO3. Shooting/Menues/Bartering etc works out of the box with todays's wine git. IMO this bug no longer applies to (patched) Fallout 3.

Comment 208 Austin English 2009-01-15 10:51:01 CST
Removing deprecated CVS/GIT version tag. Please retest in current git. If still present, update version field to earliest known version of wine that had this bug. Thanks!
Comment 209 Tomasz Sałaciński 2009-01-15 17:18:30 CST
This bug does exist in the current git, but I think that WINE has been doing this all the time (I don't remember WINE version that did this correctly). Too bad, this makes a LOT of games unplayable.
Comment 210 Marc Mengel 2009-01-16 13:30:31 CST
So I've been reading the discussion for this bug, and I hope this isn't an old, already ruled out idea, but instead of all of this discussion of mouse-warping,
how about an option that runs the Wine application in a window which is nested centered inside a surrounding mouse-dmz window, say about 50px wider than the app window.  If your mouse is in the mouse-dmz, but outside the application's window, the mouse events still go to the application; but if the user drags the mouse outside of the mouse-dmz, you pretend the mouse is still at the edge of the mouse-dmz until it comes back inside.  Then you could set the width of the mouse-dmz wider for apps that need out-of-window mousing.

Comment 211 Tomasz Sałaciński 2009-01-16 13:51:04 CST
I think this might be the best solution - I wrote a patch that worked flawlessly with all games but only when app's window was on the center of the screen <- tested it with many applications and it worked like a charm. The only problem was the mouse dmz - I don't know how to make mouse events readable by the app if it leaves the window.

From my experience on fast moves you'll need at least ~200 pixels.
Comment 212 Vitaliy Margolen 2009-01-17 01:35:44 CST
(In reply to comment #210)
Explain how will that work for full-screen apps? And what part of _never_ warping mouse is so hard to understand?

ANY REAL solution should NOT warp mouse. And report MOUSE movements not the POINTER movements.
Comment 213 Tomasz Sałaciński 2009-01-17 06:40:51 CST
(In reply to comment #212)

I think he meant creating a bigger window that is located on -200, 200 and have size of fullscreen width + 200, fullscreen height + 200.

And, you're right and we totally agree - there should be no mouse warping at all. Mouse pointer stay on the edge of the window, but it must give us mouse events - I think this should be done by reading /dev/input/mice or from X mouse driver (if it's possible).

And what with patch from Daniel Scharrer 2009-01-13? Have someone tested it? It seems it doesn't wrap mouse.

And for ppl posting patched that are warping the mouse:

There is no real difference between mouse mode in menu and mouse mode in game (for games like KOTOR, Pariah or Fallout 3).

WINE should NOT warp the mouse, because the mouse will be stuck on the middle of the screen in menu. It should allow mouse pointer to travel across the screen (so it will work in menus) and after reaching edge - pointer should stay there and not move at all, but WINE should get mouse move events. In the menu game will ignore it, but in game (if the game is FPP type) it will just move the character properly (the cursor is hidden so there is no real difference for the user if it stays on the middle or it's on the edge).

The real problem is - how to get mouse stop moving away from the window and read mouse events if it's on the edge of the screen.
Comment 214 Reyn 2009-01-17 07:51:25 CST
(In reply to comment #213)
> (In reply to comment #212)
> 
> And what with patch from Daniel Scharrer 2009-01-13? Have someone tested it? It
> seems it doesn't wrap mouse.
> 

If it doesn't wrap mouse and nothing else happens it probably means that reading right on /dev/input/mice is not set.

But with correct rights it still does not work for me in Mount an Blade. 
The patch leads to 60 sec freeze after any mouse movement. It seems something blocks a thread that tries to read directly from  mice.

Comment 215 Forest Hale 2009-01-17 09:22:04 CST
I reiterate my point that winecfg should have a checkbox for DGA Mouse Grab, if it doesn't work for some people, then they'll have to wait for Input2, if it does work, they're happy.  It does not make it WORSE for anyone.

XF86DGADirectVideo(display, screen, XF86DGADirectMouse);

It reports relative motion and freezes the mouse pointer in place (this is unfortunate, but it does prevent it from leaving the window).
Comment 216 Tomasz Sałaciński 2009-01-17 15:02:34 CST
(In reply to comment #215)

I've told it previously - it CAN'T wrap the mouse pointer. Do you really want to have different profile for every game and navigate through game menus with keyboard? Mouse warping means that it WON'T work in menu. It should work as  Vitaliy said. I'm not a WINE developer, but I would reject all patches that warp mouse in this case. WINE should stop mouse from leaving the box and it should pass the mouse (not pointer) movement.

Imagine mouse is stuck on the middle of the screen, or it goes back to the middle when it leaves the box. Try to start a new game in Pariah or KOTOR then.
Comment 217 Forest Hale 2009-01-17 19:38:10 CST
From your comment I think I may have a misunderstanding about DirectInput - does it lock the mouse cursor position like DGA does?  Or does it still allow the mouse cursor to move around, yet still report relative motion even if the mouse cursor is confined (by ClipCursor)?

If it locks the mouse cursor position, then DGA does exactly what is wanted, if it does not lock the mouse cursor position then it is indeed a missing feature in the xlib and xorg API.

If that's the case, the only solution short of Input2 is to do full emulation of the X mouse cursor using DGA - using DGA to capture relative motion, and updating the X cursor by warping, thus achieving an identical behavior.  (Obviously only while DInput is acquired in the app)

Perhaps someone who has free time (not in the core wine team obviously) would like to take a stab at this DGA mouse cursor emulation, it would work far more reliably than any of these game-specific hacks that keep being contributed.

I hope Input2 is coming quickly, but it's been pushed off more than once.
Comment 218 Vitaliy Margolen 2009-01-17 21:05:13 CST
(In reply to comment #217)
> From your comment I think I may have a misunderstanding about DirectInput -
> does it lock the mouse cursor position like DGA does?  Or does it still allow
> the mouse cursor to move around, yet still report relative motion even if the
> mouse cursor is confined (by ClipCursor)?

Both, depending on cooperative level exclusive (mouse cursor hidden and doesn't move) or non-exclusive (mouse cursor behaves as usual). Some games mean to use exclusive mode but due to bugs end up acquiring mouse in non-exclusive mode (ex: quake, quake 2). On windows this is not a problem for full-screen games.

The DGA won't help - it covers exclusive mode only. And is currently disabled on most distros.
Comment 219 Forest Hale 2009-01-17 22:30:12 CST
(In reply to comment #218)
> The DGA won't help - it covers exclusive mode only. And is currently disabled
> on most distros.

I just stated that DGA could be used for non-exclusive mode by having the wine code warp the mouse cursor around according to the relative motion detected via DGA, it's a hack but it at least behaves correctly in all cases (the mouse is already clipped to the window by ClipCursor, this just gives wine full control of the cursor behavior while it is locked in that window).

But this all depends on whether anyone is interested in contributing such a patch.

As for it being disabled - to my knowledge it is enabled and working on all distributions if you use the mouse driver in xorg, but all distributions have had very hit-or-miss compatibility on evdev until recently.

This is why I suggested it be a checkbox - it either works or it doesn't (and the user can make it work with xorg.conf changes in my experience), so it's a useful workaround feature until Input2 is out.
Comment 220 Vincent Povirk 2009-01-17 22:37:59 CST
I don't think that such a patch is likely to be accepted, even if it works. If the thread with the DGA mouse grab becomes nonresponsive, it becomes impossible to move the mouse until that program is killed (and maybe longer). I've been told that Wine won't do X mouse grabs for a similar reason.
Comment 221 Forest Hale 2009-01-17 22:50:08 CST
(In reply to comment #220)
> I don't think that such a patch is likely to be accepted, even if it works. If
> the thread with the DGA mouse grab becomes nonresponsive, it becomes impossible
> to move the mouse until that program is killed (and maybe longer). I've been
> told that Wine won't do X mouse grabs for a similar reason.

Pretty much every native Linux game does exactly this (X mouse grab, and often DGA as well), so arguably this is an X problem and not one peculiar to wine.

We can't demand that a game in wine to work better than a native game.

I assume this will all be fixed with XInput2, but until then I think the current situation is fixable, at least for a majority of users, and it would end the steady stream of hacks being contributed.
Comment 222 Jon R 2009-01-26 09:55:07 CST
To add my 2 cents, I just picked up a copy of Hitman 2 and am experiencing this bug with it.  Hitman 2 is version 1.02 and I got this error via command line: fixme:dinput:SysMouseAImpl_Acquire Clipping cursor to (0,0)-(800,600)  This game was running 'windowed' on a screen that size, so I'm not sure what that is suppose to look like.
Comment 223 Austin English 2009-01-27 14:10:35 CST
*** Bug 17157 has been marked as a duplicate of this bug. ***
Comment 224 Tomasz Sałaciński 2009-01-27 17:33:34 CST
(In reply to comment #218)

Mouse is NOT behaving normally in non-exclusive mode.

While in exclusive mode, mouse is grabbed and no other application can use it in exclusive mode. In non-exclusive mode, the mouse is grabbed too, but can be restored for other applications (for example by pressing alt-tab). In both cases, mouse IS grabbed. It's not grabbed in foreground and background modes only.

Lots of games are using non-exclusive mode to allow alt-tabbing out of them, it's not because of some bugs.
Comment 225 Vitaliy Margolen 2009-01-27 21:40:11 CST
(In reply to comment #224)
> In both cases, mouse IS grabbed.
Nope. Read MSDN. Use sample apps (like the one from DXSDK).

Don't forget about DISCL_FOREGROUND / DISCL_BACKGROUND. Which talk about totally different aspect of access. However they have no affect of grabbing the pointer.
Comment 226 GreatEmerald 2009-02-21 07:18:12 CST
This bug still persists in Wine 1.1.15, tested with Unreal II XMP on OpenSUSE. Is there a working fix yet?
Comment 227 Jake 2009-02-24 20:04:01 CST
I can confirm that on a 64 bit Lenny, downloading Wine 1.1.15 (you have to add the repository) and setting the dinput key to 'force' fixes the problem! At least on Unreal Tournament 2004.

Also: I tried forcing the key on version 1.0.1.1 or whatever. (the highest Lenny showed normally) Didn't work at all for Unreal Tournament 2004. I even tried disabling it, it didn't affect Deus Ex, an Unreal engine game which DID grab the mouse properly. And UT2004 didn't work normally with the updated Wine - it had to have both the update AND the force key.

Good luck, hope this helps.

P.S. to be specific, my problem was the "mouse gets stuck when it reaches the edge of screen"
Comment 228 Zhenya 2009-03-08 03:13:16 CDT
Mouse works bad in Wine 1.1.16 in S.T.A.L.K.E.R. Shadow Of Chernobyl. In previous versions of Wine mouse works fine, and in S.T.A.L.K.E.R. Clear Sky it works bad in all versions of Wine. After applying of patch mouse becomes very soft that it was before bug appears in Wine 1.1.16! This is funny, it is better to try it personally. I tried to hand down you this nice present effect.
http://rapidshare.com/files/206716642/Soft_mouse_in_S.T.A.L.K.E.R._with_patch.ogv
Comment 229 chourmovs 2009-03-11 08:24:30 CDT
why it's so difficult to fix mouse behaviour !!!!!
I can't understand :(
Comment 230 Xavier Perignon 2009-03-12 14:19:06 CDT
Same problem in GTAIII. The mouse leaves the windows... And with versions 0.9.7, 1.1.9, 1.1.16.
Comment 231 Zhenya 2009-03-15 02:21:05 CDT
It fixes, but makes mouse soft. This is not bad, this is beautiful. But this is stand on the way to comfortable way. You can use patch with Windows (just rename it to dinput.dll), I need to do more correct video.
Comment 232 Jayme 2009-03-15 08:40:47 CDT
In Ryzom the "Hack to read raw mouse movement from /dev/input/mice" is leading to ~1 sec. freeze every 3-5 sec. (wine 1.1.15)
Comment 233 Vitaliy Margolen 2009-03-15 15:27:58 CDT
*** Bug 17751 has been marked as a duplicate of this bug. ***
Comment 234 Vitaliy Margolen 2009-03-20 10:45:03 CDT
*** Bug 17801 has been marked as a duplicate of this bug. ***
Comment 235 Paul "TBBle" Hampson 2009-03-22 10:05:43 CDT
XInput2 is starting to firm up (http://lists.x.org/archives/xorg-devel/2009-March/000514.html via Phoronix) so it might be a good time to investigate a preliminary XInput2-based solution to this bug, and ensure that the XInput2 API is sufficient (while it's still malleable enough to fix) to cover the requirements.

As I understand it, the issue here is that when dinput is being used to capture the mouse exclusively (ie. using DirectInput's Acquire with DISCL_EXCLUSIVE and hence DISCL_FOREGROUND) no other X events should be sent for that mouse, and the cursor's position should no longer affect anything that happens (ie the cursor becomes uninteresting and invisible, and all mouse events are sent back via directinput) which includes not changing focus to other windows, and this state needs to be cleared when focus is lost.

If DISCL_NONEXCLUSIVE is used, then the application needs to be able to start reading events from the mouse either at any time (DISCL_BACKGROUND) or only when it has focus (DISCL_FOREGROUND) but in this case the cursor remains tied to the mouse (unless something else has it acquired with DISCL_EXCLUSIVE) and free to move about the screen.

I'm not sure from reading this bug if it also covers programs that capture the mouse using ClipCursor, I take it from comment 67 that XGrabPointer is already used to cover this method, as programs using this do not expect to receive movement events from the cursor that would take it outside the clip rectangle.

On initial consideration, it seems to me that this interface should be exported from winex11.drv (and alternative display/input drivers) for use by dinput.dll.

http://msdn.microsoft.com/en-us/library/bb147211(VS.85).aspx (briefly) documents a sample program in the DirectX SDK which exercises the various modes of using the mouse under DirectInput.
Comment 236 Paul "TBBle" Hampson 2009-03-22 11:26:38 CDT
(In reply to comment #235)
> I'm not sure from reading this bug if it also covers programs that capture the
> mouse using ClipCursor, I take it from comment 67 that XGrabPointer is already
> used to cover this method, as programs using this do not expect to receive
> movement events from the cursor that would take it outside the clip rectangle.

On looking at the actual code, this is not how ClipCursor currently works. Currently, it just keeps track of the rectangle requested, and if we receive a mouse move event that would take us outside that window, we reset our cusor position (but not the X mouse position or the position reported in the WM_MOUSEMOVE event). This seems to me to have three problems. We don't actually lock the mouse within the requested rectangle, if we don't see the mouse event we can't even clip the cursor (but in that case the cursor wouldn't move anyway) and we report a possibly-unexpected position (outside the clip) in WM_MOUSEMOUSE, which doesn't match our cursor position.

I'm not sure that last one is actually incorrect -- from the ClipCursor MSDN page and my recollections of its behaviour, other applications can override your ClipCursor at any time, and do not have to be in the foreground to do so. MSDN says they musn't, though... So in theory any application which relies on being able to do so is incorrect, but conversely no application can rely on its mouse input actually being limited to where its ClipCursor is set.

The problem with using XGrabPointer for this (which is what attachment 11735 [details] from comment 82 appears to be doing) is that (as far as I understand from the manpage, I haven't tried this) it also affects what windows actually receive X11 events, which isn't actually true of ClipCursor, although it will produce the correct results for the general use-case of a Win32 program calling ClipCusor with its own window rectangle or client-area rectangle.

Anyway, if ClipCursor does have any issues, it probably should be addressed in a seperate bug, or this bug just gets too conflated.
Comment 237 Peter Kovacs 2009-03-26 16:20:23 CDT
From what I understand the main Problem is that we only have absolute position on the mouse, but for the Game interface we need vector oriented presentation. Right? So I started to look for a way to get Vectored Events from X.
I stumbled across XTrap. They talk of Vectorevents ...
Cant we make use of that?
Sorry if I get the issue wrong. I am quite unskilled in C/C++ and have no Idea of X. I just researched a bit and read stuff that could help. (I did not even ask anyone :P ) So for me this is a shot into the Blue.

Excerpt from perso.tls.cena.fr/jestin/Video/Docs/XTrap_Arch.ps.gz

Event Vectoring
In recording X protocol either for performance measurements or record/playback functionality, it often
becomes necessary to capture more than just the core input events (Keyboard & Pointer). Further, it’s
often critical to capture events before the determination is made by the server to not deliver the event.
Of course, this could be done by a client by configuring "interest" for all events in all windows (includ-
ing the root); however, the overhead associated with keeping track of the entire server’s volatile win-
dow hierarchy is typically too expensive (especially for performance monitoring clients).
As discussed earlier in this document, a ProcVector approach was implemented in X11 for all requests
and byte-swapped events. One can only deduce that normal events weren’t vectored for performance
reasons. With this in mind and the requirement to capture all events before the server drops any on the
floor, the following are excerpts of experimental changes to events.c and devices.c to facilitate event
vectoring

Hope it helps!
Peter
Comment 238 Paul "TBBle" Hampson 2009-03-27 08:21:32 CDT
I don't think XTrap is compiled into Xservers normally... In fact, a quick browse through the X.org git repo suggests it might not actually be implemented in Xorg, though the headers, library and protocol repositories are there.

So I might be looking in the wrong place for the actual extension implemented. But certainly the xserver-xorg-core package on Debian/unstable doesn't list XTrap in xdpyinfo by default.
Comment 239 Paul "TBBle" Hampson 2009-03-27 08:23:19 CDT
Ignore that, I confused XTrap and XTest. It's compiled, but not enabled by default.
Comment 240 Paul "TBBle" Hampson 2009-03-29 03:49:18 CDT
http://wiki.winehq.org/DInput has some XInput2 information.
Comment 241 Paul "TBBle" Hampson 2009-03-31 07:00:57 CDT
Xorg has dropped XTrap as of Xserver 1.6.

http://www.x.org/wiki/Server16Branch#head-b1f125722e5fa755198eaff3e42c1cfffc861f90
Comment 242 Joey Forgues Forget 2009-04-06 12:38:57 CDT
Created attachment 20315 [details]
add a toggle with the middle mouse button for the mouse wrapping.

Here a small patch i did based on those with mouse wrapping , but instead of requiring you to hold the key. its a toggle. 

work perfectly fine with most games since you can toggle it off with the middle mouse button (its used in some games, but rarely an important action). 

Obviously, this is only meant as a temporary solution, but its enough for me.
Comment 243 Yvan Da Silva 2009-04-26 06:02:12 CDT
Created attachment 20721 [details]
mouse patch modified only recenter mouse when right,left or middle click is down.

This patch is a version modified on one that is actually present here.

The only change is that when right/left/middle click is not pressed, center the mouse on the screen is not applied.

Like warhammer online other games only have problems with mouse when right or left clic is used.
Some games use this function with middle click so I added middle click too.

This is a sort of hack, so it's not a really usable patch...
But it can help for some games at moment, so I post my changes added to this patch here.
Comment 244 Yvan Da Silva 2009-04-26 06:30:55 CDT
(In reply to comment #243)
> Created an attachment (id=20721) [details]
> mouse patch modified only recenter mouse when right,left or middle click is
> down.
> 
> This patch is a version modified on one that is actually present here.
> 
> The only change is that when right/left/middle click is not pressed, center the
> mouse on the screen is not applied.
> 
> Like warhammer online other games only have problems with mouse when right or
> left clic is used.
> Some games use this function with middle click so I added middle click too.
> 
> This is a sort of hack, so it's not a really usable patch...
> But it can help for some games at moment, so I post my changes added to this
> patch here.
> 

For information I use Playonlinux to install all my software even not supported.
It's a great tool because each install have is own directory with his own register, it's own setup to explain everything, and you can set up a different wine version for each software.

So with this patch, all my games who I don't set in registery  force_edge  even if I use the same wine version (system), I don't have any problems, even for FPS likes etc...

enjoy.
Comment 245 James Stone 2009-05-04 11:26:25 CDT
Given the wide range of apps that are affected by this bug, it's severity should probably be upped from Normal to Major.
Comment 246 LBM 2009-05-11 14:00:52 CDT
Created attachment 21031 [details]
Output during lag/freeze when using patch id=18681

(In reply to comment #206)
> Created an attachment (id=18681) [details]
> Hack to read raw mouse movement from /dev/input/mice
> 
> ...
> 

I thought I'd give this patch a try since it seems to be the only one that doesn't wrap the mouse, however I experienced the same lag/freeze as others here.

I'm no expert when it comes to the dinput code in Wine but I thought maybe someone else might have use for output when running a game like Mount & Blade with WINEDEBUG=+dinput and this patch.

The output is what's dumped to my terminal every time (and only when) the application freezes.

Any thoughts?
Comment 247 giovanni.nicola 2009-06-04 12:05:53 CDT
Created attachment 21554 [details]
Patch for mouse for bug 6971
Comment 248 giovanni.nicola 2009-06-04 12:38:28 CDT
Comment on attachment 21554 [details]
Patch for mouse for bug 6971

to activate
WINEFORCEMOUSEWARP=yes wine proggy.exe
Comment 249 giovanni.nicola 2009-06-04 12:44:10 CDT
The Patch that i have proposed works for all Ut3 engine games, Crysis and Crysis Warhead and all those ut2004 engine games, this i my firts try at wines mouse but i hope this patch can be useful to all the community
Comment 250 Vitaliy Margolen 2009-06-04 19:38:45 CDT
*** Bug 18774 has been marked as a duplicate of this bug. ***
Comment 251 Alessandro Pedarra 2009-06-19 12:17:41 CDT
Please how can I implement this patch? I'm not a programmer so if you can explain it to me... many thanks.
Comment 252 sheen 2009-06-19 12:45:56 CDT
(In reply to comment #251)
> Please how can I implement this patch? I'm not a programmer so if you can
> explain it to me... many thanks.

take the patch, get the source via git, apply the patch, compile, install.
it should be approximatively this :

create a file patch.diff and copy the patch inside 
install git-core
git clone git://source.winehq.org/git/wine.git ~/user/wine-git
cd ~/user/wine-git
patch -p1 < /locationofthepatch/patch.diif
make depend
make
make install

(Don't forget to install all the needed library, you should find them on the wiki)
Comment 253 Alessandro Pedarra 2009-06-19 13:24:17 CDT
(In reply to comment #252)
> (In reply to comment #251)
> > Please how can I implement this patch? I'm not a programmer so if you can
> > explain it to me... many thanks.
> 
> take the patch, get the source via git, apply the patch, compile, install.
> it should be approximatively this :
> 
> create a file patch.diff and copy the patch inside 
> install git-core
> git clone git://source.winehq.org/git/wine.git ~/user/wine-git
> cd ~/user/wine-git
> patch -p1 < /locationofthepatch/patch.diif
> make depend
> make
> make install
> 
> (Don't forget to install all the needed library, you should find them on the
> wiki)

I got stopped here: alessandro@alessandro-desktop:~/user/wine-git$ make depend
make: *** Nessuna regola per creare l'obiettivo «depend».  Arresto.
alessandro@alessandro-desktop:~/user/wine-git$ 

(?)
Comment 254 sheen 2009-06-19 14:31:22 CDT
(In reply to comment #253)
> I got stopped here: alessandro@alessandro-desktop:~/user/wine-git$ make depend
> make: *** Nessuna regola per creare l'obiettivo «depend».  Arresto.
> alessandro@alessandro-desktop:~/user/wine-git$ 
> 
> (?)

Sorry I've forgotten the ./configure line (before make depend), but you'll need all the library
The best way for you is here : http://wiki.winehq.org/WineOn64bit
All is explained, for all environment.
Comment 255 Alessandro Pedarra 2009-06-19 16:29:18 CDT
(In reply to comment #254)
> (In reply to comment #253)
> > I got stopped here: alessandro@alessandro-desktop:~/user/wine-git$ make depend
> > make: *** Nessuna regola per creare l'obiettivo «depend».  Arresto.
> > alessandro@alessandro-desktop:~/user/wine-git$ 
> > 
> > (?)
> 
> Sorry I've forgotten the ./configure line (before make depend), but you'll need
> all the library
> The best way for you is here : http://wiki.winehq.org/WineOn64bit
> All is explained, for all environment.

Tried to do it but with no success.. maybe because I made everything (even WineOn64bit) in ~/user/wine-git ? 

Anyway for me it's too much, I do not really understand the process. I think I have to wait for the next official build, hoping that the patch will be integrated.

Thanks anyway for your support sheen. ;)
Comment 256 Brian 2009-06-20 06:54:10 CDT
(In reply to comment #248)
> (From update of attachment 21554 [details])
> to activate
> WINEFORCEMOUSEWARP=yes wine proggy.exe

Does this patch only effect the builtin dinput?  I was trying to get Halo to work, and the mouse lags quite a bit unless I use a native dinput8.  Using the native dll of course causes the mouse to escape the window...

I tried this patch but it didn't seem to change anything.
Comment 257 Valeriy Malov 2009-07-09 12:17:28 CDT
Is xinput2 support already implemented somewhere (git?)? Like, if still there is no grab support, maybe it can work with fullscreen?
Comment 258 Jake 2009-07-29 20:38:21 CDT
as anyone tried making a mouse warping program for xorg?

When a game receives mouse inputs, we know it receives relative inputs.

Why not make a program that could be a taskbar program, and whenever wine is running, it forces the xorg pointer to the middle of the screen? That way, the game would still receive relative inputs, but the actual pointer couldn't reach the edge.

It would allow games with menus and FPSes to work at the same time.

Unfortunately, a 2d game that didn't make it's own mouse cursor (or any program that didn't) would have the mouse stuck in the middle, but then you could just have a simple like ctrl-F12 or something turn it off.

I don't know if it could be done, but a program that placed the pointer in the center of the screen, then say, 20 pixels in a +/- direction would shove it back to the middle would work perfectly.

I know someone will get confused/not understand and say "but the mouse would get stuck in the middle of the screen" NO, THIS SOLUTION DOES NOTHING TO WINE. IT WOULD JUST WARP THE POINTER IN Xorg, completely bypassing regedits and patches for wine.

For a starting point, probably at least the mouse would need to be moved on a tenth or a hundredth of a second basis, because in FPSes the mouse may need to be moved fast.
Comment 259 Jack Diaz 2009-08-10 21:32:08 CDT
Raziel recommended using HKEY_CURRENT_USER --> Software --> Wine, Key=DirectInput, String=MouseWarpOverride, Value=force. I'm testing it right now on Wine 1.1.27 its working with no patch. I have not tested this on other games yet but it does fix the mouse problem while playing Bioshock.
Comment 260 Giovanni Ongaro 2009-08-23 16:10:44 CDT
(In reply to comment #253)
> (In reply to comment #252)
> > (In reply to comment #251)
> > > Please how can I implement this patch? I'm not a programmer so if you can
> > > explain it to me... many thanks.
> > 
> > take the patch, get the source via git, apply the patch, compile, install.
> > it should be approximatively this :
> > 
> > create a file patch.diff and copy the patch inside 
> > install git-core
> > git clone git://source.winehq.org/git/wine.git ~/user/wine-git
> > cd ~/user/wine-git
> > patch -p1 < /locationofthepatch/patch.diif
> > make depend
> > make
> > make install
> > 
> > (Don't forget to install all the needed library, you should find them on the
> > wiki)
> 
> I got stopped here: alessandro@alessandro-desktop:~/user/wine-git$ make depend
> make: *** Nessuna regola per creare l'obiettivo «depend».  Arresto.
> alessandro@alessandro-desktop:~/user/wine-git$ 
> 
> (?)

Alessandro:
Download the patch
Download the WineCVS.sh script this will allow you to have more wines on your system
as root issue WineCVS.sh. download the latest wine
put the patch in your /root/.WineCVS/sources/yourwine/wine directory
issue a patch -p1 < mypatch.diff whre mypatch is the downloaded patch
check that all the hunks are succesful
now as root start WineCVS.sh select your wine and do a recompile
when the process is done
you are done for the moment

to activate the patch instead of typing yourwine game.exe
type WINEFORCEMOUSEWARP=yes yourwine game.exe
Comment 261 Giovanni Ongaro 2009-08-23 16:15:12 CDT
(In reply to comment #253)
> (In reply to comment #252)
> > (In reply to comment #251)
> > > Please how can I implement this patch? I'm not a programmer so if you can
> > > explain it to me... many thanks.
> > 
> > take the patch, get the source via git, apply the patch, compile, install.
> > it should be approximatively this :
> > 
> > create a file patch.diff and copy the patch inside 
> > install git-core
> > git clone git://source.winehq.org/git/wine.git ~/user/wine-git
> > cd ~/user/wine-git
> > patch -p1 < /locationofthepatch/patch.diif
> > make depend
> > make
> > make install
> > 
> > (Don't forget to install all the needed library, you should find them on the
> > wiki)
> 
> I got stopped here: alessandro@alessandro-desktop:~/user/wine-git$ make depend
> make: *** Nessuna regola per creare l'obiettivo «depend».  Arresto.
> alessandro@alessandro-desktop:~/user/wine-git$ 
> 
> (?)

Alessandro:
Download the patch
Download the WineCVS.sh script this will allow you to have more wines on your system
as root issue WineCVS.sh. download the latest wine
put the patch in your /root/.WineCVS/sources/yourwine/wine directory
issue a patch -p1 < mypatch.diff whre mypatch is the downloaded patch
check that all the hunks are succesful
now as root start WineCVS.sh select your wine and do a recompile
when the process is done
you are done for the moment

to activate the patch instead of typing yourwine game.exe
type WINEFORCEMOUSEWARP=yes yourwine game.exe




(In reply to comment #256)
> (In reply to comment #248)
> > (From update of attachment 21554 [details] [details])
> > to activate
> > WINEFORCEMOUSEWARP=yes wine proggy.exe
> 
> Does this patch only effect the builtin dinput?  I was trying to get Halo to
> work, and the mouse lags quite a bit unless I use a native dinput8.  Using the
> native dll of course causes the mouse to escape the window...
> 
> I tried this patch but it didn't seem to change anything.

Did You Activate the Patch by prefixing wine with WINEFORCEMOUSEWARP=yes?
Yes this of course affects only the buitin dinput
Comment 262 Manuel Soukup 2009-10-25 11:13:37 CDT
Hi

There is the programm xwarppointer

You can set the cursor pos with it like:

./xwarppointer abspos 50 50

I'll try that you later

cu
Comment 263 Manuel Soukup 2009-10-25 14:57:52 CDT
Hi

I found a workaround for the mouse escape bug.

First: get xwarppointer from the internet and compile it.

Second: Change the Game Res to 1280xYYYY

Third use this script to start:

---------------------------------
#!/bin/bash

# Resolution in game : 1280xYYYY !!!!!!

cd /mnt/daten/wine/win_c/programme/Thief3/

MWINE_VERSION=wine1132 WINEPREFIX=~/.wine/thief3 mwine System/T3.exe &

while [ 1 = 1 ]
do

getX=$(./xwarppointer get | cut -d" " -f1,1)
getY=$(./xwarppointer get | cut -d" " -f2,2)
#echo $getX

if [ $getX -lt 2 ]; then
./xwarppointer abspos 1277 .
else

if [ $getX -gt 1278 ]; then
./xwarppointer abspos 3 .

fi

fi

#if [ $getY -lt 10 ]; then
# ./xwarppointer abspos . 385
# else

#if [ $getY -gt 758 ]; then
# ./xwarppointer abspos . 385

# fi

# fi

# ./System/xwarppointer abspos 700 450
done


--------------------------------- 

This works for Thief 3 , Deadly Shadows
Comment 264 haarp 2009-10-25 15:03:36 CDT
This is not a good solution, since it will waste a LOT of CPU time running that loop. On top of that, it will not catch fast mouse movements. It's essentially the same as Attachment 11303 [details], only slower since it's based on bash. And even for 11303, Vitaliy said that it could be too slow.
Comment 265 Austin English 2009-11-01 20:45:04 CST
Also affects borderlands.
Comment 266 Austin English 2009-11-06 14:43:36 CST
*** Bug 20593 has been marked as a duplicate of this bug. ***
Comment 267 Valeriy Malov 2009-11-12 11:47:39 CST
Also affects "Point blank". Rude hack with permanent mouse wrapping makes menu unusable
Comment 268 Vitaliy Margolen 2009-11-13 08:15:13 CST
*** Bug 20582 has been marked as a duplicate of this bug. ***
Comment 269 Thanos Chatziathanassiou 2009-11-17 08:07:26 CST
Created attachment 24805 [details]
Add force-box option to MouseWarpOverride registry key

Here's a patch to add ``force-box'' option to current MouseWarpOverride registry key against current (2009/11/17) git.
You can also add a ``BoxPixels'' key with values 1-999 to define the size of the box (it defaults to 10) that'll wrap the mouse.
It works quite nicely for me in Borderlands, much better than ``force'' at least. I've written it during a lunch break and I'm not familiar with wine internals at all (basically I just retro-fitted an existing patch http://bugs.winehq.org/attachment.cgi?id=11303), so someone more knowledgeable please take a look at it and fix if necessary.
Comment 270 haarp 2009-11-19 15:53:24 CST
Wow, thank you. This may prove to be quite useful, considering the Wine dev's reluctance to include any workarounds, even when a real fix is months/years away (and it wouldn't interfere with anything unless activated) :)
Comment 271 Denis Rut'kov 2009-11-22 11:05:05 CST
*** Bug 20796 has been marked as a duplicate of this bug. ***
Comment 272 Xavier Vachon 2009-12-03 20:15:31 CST
As of current git, this hack : http://bugs.winehq.org/attachment.cgi?id=21554 does not compile anymore.

xavier@xavier-pc /wine-git $ patch -p1 < mouseut3engine.diff
patching file dlls/dinput/device.c
patching file dlls/dinput/mouse.c
Hunk #8 FAILED at 328.
Hunk #9 FAILED at 425.
2 out of 17 hunks FAILED -- saving rejects to file dlls/dinput/mouse.c.rej

When I attempt to apply the hack by Thanos, I get this:

xavier@xavier-pc /wine-git $ patch -p1 < warp-force-box.patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- dlls/dinput/mouse.c.orig   2009-11-17 15:47:35.000573211 +0200
|+++ dlls/dinput/mouse.c        2009-11-17 15:53:05.590802272 +0200
--------------------------
File to patch:

Thanos, how did you apply your hack to your tree?
Comment 273 Thanos Chatziathanassiou 2009-12-04 06:29:29 CST
> xavier@xavier-pc /wine-git $ patch -p1 < warp-force-box.patch
> can't find file to patch at input line 3
> Perhaps you used the wrong -p or --strip option?

Exactly what it says on the tin :)

> The text leading up to this was:
> --------------------------
> |--- dlls/dinput/mouse.c.orig   2009-11-17 15:47:35.000573211 +0200
> |+++ dlls/dinput/mouse.c        2009-11-17 15:53:05.590802272 +0200
> --------------------------
> File to patch:
> 
> Thanos, how did you apply your hack to your tree?

try ``patch -p0 < warp-force-box.patch''
Comment 274 Xavier Vachon 2009-12-04 21:38:20 CST
(In reply to comment #273)
> > xavier@xavier-pc /wine-git $ patch -p1 < warp-force-box.patch
> > can't find file to patch at input line 3
> > Perhaps you used the wrong -p or --strip option?
> 
> Exactly what it says on the tin :)
> 
> > The text leading up to this was:
> > --------------------------
> > |--- dlls/dinput/mouse.c.orig   2009-11-17 15:47:35.000573211 +0200
> > |+++ dlls/dinput/mouse.c        2009-11-17 15:53:05.590802272 +0200
> > --------------------------
> > File to patch:
> > 
> > Thanos, how did you apply your hack to your tree?
> 
> try ``patch -p0 < warp-force-box.patch''

"patch -p0 < warp-force-box.patch" did worked. I wanted to try it with Assassin's Creed, but I most likely made a mistake somewhere because it does not work. In regedit I have:

1) HKEY_CURRENT_USER/Software/Wine/DirectInput
2) BoxPixels value=10
3) MouseWarpOverride value=force-box

Is that how it is supposed to be?
Comment 275 Thanos Chatziathanassiou 2009-12-05 06:10:52 CST
> 1) HKEY_CURRENT_USER/Software/Wine/DirectInput
> 2) BoxPixels value=10
> 3) MouseWarpOverride value=force-box
> 
> Is that how it is supposed to be?

This is pretty much what I have.
Did you compile wine after patching ? Installed ? 
I tried it yesterday against 1.1.34 as soon as it was released with Borderlands and it worked like it used to.
Comment 276 Xavier Vachon 2009-12-05 07:09:22 CST
(In reply to comment #275)
> > 1) HKEY_CURRENT_USER/Software/Wine/DirectInput
> > 2) BoxPixels value=10
> > 3) MouseWarpOverride value=force-box
> > 
> > Is that how it is supposed to be?
> 
> This is pretty much what I have.
> Did you compile wine after patching ? Installed ? 
> I tried it yesterday against 1.1.34 as soon as it was released with Borderlands
> and it worked like it used to.

I did compiled and installed wine after applying the bunch of hacks I use (including yours).

I will be away this weekend, I will try to find more information for you once I get back.
Comment 277 Warren Dumortier 2009-12-06 16:47:37 CST
Does the 'force-box' option allow to use the menus using the mouse or is it just an alternative to 'force'? What is the difference then?
Comment 278 Rob Whalley 2009-12-06 18:17:14 CST
Just some feedback: I was using the patch from http://bugs.winehq.org/attachment.cgi?id=21554 on 1.1.33 to get mouse working on Mass Effect (via Steam). This was working well.

As Xavier notes above, this patch no longer works with 1.1.34. I have successfully built Wine 1.1.34 with the newer warp-force-box.patch, however it does not work for Mass Effect. When you try and use the mouse it snaps immediately back to the centre of the screen, even with different box sizes specified in the registry.

I did consider trying to modify the older 21554 patch but am afraid it's way over my head :(
Comment 279 Rob Whalley 2009-12-06 20:04:48 CST
Created attachment 25097 [details]
New version of giovanni.nicola patch (21554) to work with Wine 1.1.34
Comment 280 Rob Whalley 2009-12-06 20:07:13 CST
Ok, even though I can't claim to understand quite how the two patches works, I've created a new version of the patch http://bugs.winehq.org/attachment.cgi?id=21554 that should work on 1.1.34.

It incorporates elements from both patches, but I don't think that it will reproduce the behaviour of the force-box patch (someone with a better understanding would need to take a look!) - it would be nice if we could combine the two.

Tested patch and confirmed behaviour from 21554 patch restored - I now have a working mouse in Mass Effect! :)

Under /home/$USERNAME/.wine/user.reg, following settings did not reproduce the restricted mouse movement, so guessing it now ignores "force-box":

[Software\\Wine\\DirectInput] 1258814435
"MouseWarpOverride"="force-box"
"BoxPixels"="10"

Basic howto (as root) - you can see I've made the patch against the bz2 file from sourceforge rather than from git:

wget http://downloads.sourceforge.net/project/wine/Source/wine-1.1.34.tar.bz2
tar xjvf wine-1.1.34.tar.bz2
cd wine-1.1.34
wget http://bugs.winehq.org/attachment.cgi?id=25097 -O mousewarp-1.1.34.patch
#Download other patches you may want at this point
patch -p1 < mousewarp-1.1.34.patch
autoreconf
./configure
make depend && make
make install

To run Mass Effect from Steam, I use: 
WINEFORCEMOUSEWARP=yes wine "C:\Program Files\Steam\steam.exe"

Then I start it up from the My Games list.

Hope this helps someone. Apologies for not being clearer, it's late and I need sleep! ;)
Comment 281 Xavier Vachon 2009-12-06 20:49:16 CST
(In reply to comment #280)
> Ok, even though I can't claim to understand quite how the two patches works,
> I've created a new version of the patch
> http://bugs.winehq.org/attachment.cgi?id=21554 that should work on 1.1.34.
> 
> It incorporates elements from both patches, but I don't think that it will
> reproduce the behaviour of the force-box patch (someone with a better
> understanding would need to take a look!) - it would be nice if we could
> combine the two.
> 
> Tested patch and confirmed behaviour from 21554 patch restored - I now have a
> working mouse in Mass Effect! :)
> 
> Under /home/$USERNAME/.wine/user.reg, following settings did not reproduce the
> restricted mouse movement, so guessing it now ignores "force-box":
> 
> [Software\\Wine\\DirectInput] 1258814435
> "MouseWarpOverride"="force-box"
> "BoxPixels"="10"
> 
> Basic howto (as root) - you can see I've made the patch against the bz2 file
> from sourceforge rather than from git:
> 
> wget http://downloads.sourceforge.net/project/wine/Source/wine-1.1.34.tar.bz2
> tar xjvf wine-1.1.34.tar.bz2
> cd wine-1.1.34
> wget http://bugs.winehq.org/attachment.cgi?id=25097 -O mousewarp-1.1.34.patch
> #Download other patches you may want at this point
> patch -p1 < mousewarp-1.1.34.patch
> autoreconf
> ./configure
> make depend && make
> make install
> 
> To run Mass Effect from Steam, I use: 
> WINEFORCEMOUSEWARP=yes wine "C:\Program Files\Steam\steam.exe"
> 
> Then I start it up from the My Games list.
> 
> Hope this helps someone. Apologies for not being clearer, it's late and I need
> sleep! ;)

I tested the patch with Assassin's Creed. If I play full screen I have not experienced problems so far, but if I play in windowed mode the mouse still escapes during gameplay. I run the game with :

env WINEDEBUG=-all WINEFORCEMOUSEWARP=yes wine "AssassinsCreed_Launcher.exe"
Comment 282 Vitaliy Margolen 2009-12-06 21:10:50 CST
People please keep this dirty hacks outside of bugzilla. And do not turn it into a forum for clueless people about how to compile Wine!
Comment 283 Clarence Risher 2009-12-07 10:48:18 CST
I concur on the subject of compilation instructions.

However, I disagree regarding patches/hacks.  If there is a bug that affects 5 games, and we have no global solution, where other than in that bug report do you suggest keeping the 5 distinct-but-related patches that solve the problem in thos particular games?  Assuming that the contents of the patches are of use to a developer who might finally fix the bug, keeping them on 5 separate appdb pages seems counterproductive.

Also, marking the patches obsolete is both inaccurate and spam-generating.
Comment 284 haarp 2009-12-07 10:49:24 CST
(In reply to comment #282)
> People please keep this dirty hacks outside of bugzilla. And do not turn it
> into a forum for clueless people about how to compile Wine!

Sorry, but I don't think that's the right thing to do. I agree with the help forum part. But disallowing 'hacks' is not really the right course If you ask me.
People come here looking for progress and solutions for their problem. The real fix is still months (years?) away and you can't expect them to wait for that long. The hack is a temporary solution. Hacks get posted in other bugs every day. Hell, even Wine itself already contains a 'force' hack. force-box is simply the logical extension of that, and works well so far for many people. I don't see why it should be forbidden.
Yes - it's no proper fix. The current Wine philospohy is not to adopt such things. I accept that. But for the sake of completeness, keep it in Bugzilla.

I know that you, Vitaliy, have far more experience on that matter than anybody else. I'm not doubting your authority on this. But I don't agree either.
Comment 285 Tobias Jakobi 2009-12-07 11:04:01 CST
(In reply to comment #282)
> People please keep this dirty hacks outside of bugzilla. And do not turn it
> into a forum for clueless people about how to compile Wine!
Don't you think it's a bit arrogant to be the one to define what's a dirty hack and what is not?

If everything that resembles a hack should disappear from wine we could deleted a large percentage of the codebase - see e.g. the current discussion about the soundsystem on the mailing list.

Considering how long this bug here has existed and considering even more the time it will STILL exist, it's VERY counterproductive to discourage the creation of such (what YOU call) "hacks"....
Comment 286 GreatEmerald 2009-12-07 11:11:43 CST
Indeed, this is a very serious bug that affects entire game engines and make them for the most part frustrating to use. Anything that can improve the situation should be welcome, whether they are hacks or not.
Though I do agree that the attachment list is cluttered and could be a lot better organised, since right now there are a lot of patches to choose from yet there isn't much information on what they do and what they don't.
Comment 287 Tobias Jakobi 2009-12-07 11:53:23 CST
Then someone should step up and organize the "hacks" in a Wiki entry, so that you can decide which one to use for a specific situation / game / application. Obviously this has to be someone else than Vitaliy.
Comment 288 Tomasz Sałaciński 2009-12-07 12:06:47 CST
(In reply to comment #287)
> Then someone should step up and organize the "hacks" in a Wiki entry, so that
> you can decide which one to use for a specific situation / game / application.
> Obviously this has to be someone else than Vitaliy.

Something that may be called winehacks.org? :> I understand Vitaliy's approach, because neither users or developers want "hacky" code in WINE. But, there are some other hacks in WINE that work for now (fallback to X server - DIB engine not present). IMHO discussion about hacks should be somewhere else, maybe there should be another section like "Hacks" in WINE's website menu? With information that WINE developers DO NOT SUPPORT these hacks and if someone is using hacked WINE must not post bugs. This could help some people to play the game they really want without thinking that their copy of wine won't run another game because they don't really want to play it.
Comment 289 Rob Whalley 2009-12-07 12:48:23 CST
(In reply to comment #282)
> People please keep this dirty hacks outside of bugzilla. And do not turn it
> into a forum for clueless people about how to compile Wine!

Now then. That's all fine, but look at it from a user's point of view. They may need a patch to make a game or other application work. It may be a hack but most people won't care if it let's them play a game without having to dual boot with Windows.

I'm happy to abide by any suggestions regarding hacks and advice. Where would you rather this information be posted and how draconian are you going to be? - for example, I can host a 'hack' and instructions on a different website, but are you going to complain if links are posted? I'm not getting at you, I want a logical, sensible approach to sharing information with people who simply want to get a game / program working. Whatever you suggest is what I'll do - I have no problem with authority.

One more thing though - the use of the term "clueless" is a bit unfortunate. We all have to learn sometime. That's a little elitist to people who are just starting out with Linux / wine and it's not a good attitude. My post was there to help people, so regardless of the result, my intention was good. I thought that was one of the motivations behind FOSS - encouraging community participation. Why discourage it?
Comment 290 haarp 2009-12-07 12:52:44 CST
(In reply to comment #289)
> One more thing though - the use of the term "clueless" is a bit unfortunate. We
> all have to learn sometime. That's a little elitist to people who are just
> starting out with Linux / wine and it's not a good attitude.

Well, Vitaliy wasn't elitist. Bugzilla is not the place for that. That's all he said, and it's true.
Neither is this discussion, when you think about it. People voiced their valid concerns, but please leave it at that and don't clutter this bug even more.
Comment 291 Forest Hale 2009-12-08 09:12:59 CST
The simple fact is, this bug matters to a great many people, the pile of hacks dispersed here added value to the many gamers who needed them to be able to play their favorite games, regardless of any technical review process, opinion, or conflict issues.

I am all for openness, reasoned discourse, and solving bugs that matter to people.

While I do not agree with the hacks either, I do see a strong need for a solution to this problem, I look forward to the supposed XInput2 solution, but for many users this problem can not wait.

For this reason I must bring up the topic of DGA mouse grab again, so here is a proposal for pre-XInput2 xorg versions:

Lock the mouse using DGA to grab raw mouse deltas, provide the illusion of normal mouse movement using XWarpPointer, release grab whenever a mouse click occurs outside the game window or the application focus changes (due to window manager shortcuts).

DGA disables mouse movement and grabs the raw deltas, so this satisfies both aspects of the cooperative mode (mouse moves around with XWarpPointer, while deltas are captured even at borders), there might be a one-refresh pointer lag involved but this is not perceptible, no keyboard grab is used so the standard window manager shortcuts work (alt-tab and so on) to defocus the application, and it might eat a mouse click when clicking outside the game window to defocus the application but this is not a critical problem.

I can confirm that DGA works on OpenSUSE 11.2 and Ubuntu 9.10 (both current distributions), and this seems far more robust than any of the hacks released thus far.

It's clear that this discussion will only end when users can play their games without game-specific hacks.
Comment 292 Jouni Järvinen 2009-12-08 09:35:33 CST
(In reply to comment #291)
> The simple fact is, this bug matters to a great many people, the pile of hacks
> dispersed here added value to the many gamers who needed them to be able to
> play their favorite games, regardless of any technical review process, opinion,
> or conflict issues.
> 
> I am all for openness, reasoned discourse, and solving bugs that matter to
> people.
> 
> While I do not agree with the hacks either, I do see a strong need for a
> solution to this problem, I look forward to the supposed XInput2 solution, but
> for many users this problem can not wait.
> 
> For this reason I must bring up the topic of DGA mouse grab again, so here is a
> proposal for pre-XInput2 xorg versions:
> 
> Lock the mouse using DGA to grab raw mouse deltas, provide the illusion of
> normal mouse movement using XWarpPointer, release grab whenever a mouse click
> occurs outside the game window or the application focus changes (due to window
> manager shortcuts).
> 
> DGA disables mouse movement and grabs the raw deltas, so this satisfies both
> aspects of the cooperative mode (mouse moves around with XWarpPointer, while
> deltas are captured even at borders), there might be a one-refresh pointer lag
> involved but this is not perceptible, no keyboard grab is used so the standard
> window manager shortcuts work (alt-tab and so on) to defocus the application,
> and it might eat a mouse click when clicking outside the game window to defocus
> the application but this is not a critical problem.
> 
> I can confirm that DGA works on OpenSUSE 11.2 and Ubuntu 9.10 (both current
> distributions), and this seems far more robust than any of the hacks released
> thus far.
> 
> It's clear that this discussion will only end when users can play their games
> without game-specific hacks.

Brilliant idea ! That's what I call being serious with resolving the problem.
Comment 293 Robert Munteanu 2009-12-08 09:40:03 CST
On one hand, the developers are correct when asking not to be spammed with dozens of emails which are not related to the final resolution of the bug.

On the other hand, the users are correct in saying that for them this problem is solved with such patches.

My suggestion would be for one the patch submitters or another commenter to create a git ( GitHub? ) repo where this patch is to be hosted. Judging from the comments it's relatively easy to rebase it on each wine release and this way a place for retrieving the patch can be indicated, perhaps in the issue description: "Unsupported patch at ... , use at your own risk".
Comment 294 Toni Spets 2009-12-08 10:53:59 CST
(In reply to comment #291)
> The simple fact is, this bug matters to a great many people, the pile of hacks
> dispersed here added value to the many gamers who needed them to be able to
> play their favorite games, regardless of any technical review process, opinion,
> or conflict issues.
> 
> I am all for openness, reasoned discourse, and solving bugs that matter to
> people.
> 
> While I do not agree with the hacks either, I do see a strong need for a
> solution to this problem, I look forward to the supposed XInput2 solution, but
> for many users this problem can not wait.
> 
> For this reason I must bring up the topic of DGA mouse grab again, so here is a
> proposal for pre-XInput2 xorg versions:
> 
> Lock the mouse using DGA to grab raw mouse deltas, provide the illusion of
> normal mouse movement using XWarpPointer, release grab whenever a mouse click
> occurs outside the game window or the application focus changes (due to window
> manager shortcuts).
> 
> DGA disables mouse movement and grabs the raw deltas, so this satisfies both
> aspects of the cooperative mode (mouse moves around with XWarpPointer, while
> deltas are captured even at borders), there might be a one-refresh pointer lag
> involved but this is not perceptible, no keyboard grab is used so the standard
> window manager shortcuts work (alt-tab and so on) to defocus the application,
> and it might eat a mouse click when clicking outside the game window to defocus
> the application but this is not a critical problem.
> 
> I can confirm that DGA works on OpenSUSE 11.2 and Ubuntu 9.10 (both current
> distributions), and this seems far more robust than any of the hacks released
> thus far.
> 
> It's clear that this discussion will only end when users can play their games
> without game-specific hacks.

Though, with KMS/DRI2, DGA is finally killed for good. It's not enabled by default yet, but it's going to happen sometime soon.

Maybe Intel had KMS enabled for Ubuntu 9.10? Radeon is still a little behind.

DGA would not be even a good short term solution.

But on (radeon) KMS/DRI2 I didn't even need DGA in native Quake 2 to keep my cursor inside the window, I don't know what else has changed or is my sensitivity just too slow.

My two cents.
Comment 295 Forest Hale 2009-12-08 11:24:43 CST
(In reply to comment #294)
> Though, with KMS/DRI2, DGA is finally killed for good. It's not enabled by
> default yet, but it's going to happen sometime soon.
> 
> Maybe Intel had KMS enabled for Ubuntu 9.10? Radeon is still a little behind.
> 
> DGA would not be even a good short term solution.
> 
> But on (radeon) KMS/DRI2 I didn't even need DGA in native Quake 2 to keep my
> cursor inside the window, I don't know what else has changed or is my
> sensitivity just too slow.
> 
> My two cents.

I highly doubt that KMS/DRI2 has killed DGA mouse, please do not confuse DGA mouse with DGA video (which has been dead for some time already, as it required root access).

DGA mouse is a useful and usable extension.

The citation of native Quake2 is irrelevant, because it has an invisible mouse pointer and thus can do whatever warping it pleases, hence it can work without DGA (but DGA has the advantage of disabling mouse acceleration).

The topic is DI cooperative mouse, where the mouse must both be visible and report deltas (even when hitting borders of the clipping area), and mouse emulation is necessary at some level, utilizing the existing mouse pointer sprite via DGA mouse is the easiest option until XInput2.

Also, I do not think that the politics of xorg regarding DGA mouse and XInput2 are even relevant to the topic at hand: users want to be able to play their games properly, they do not care for the specifics, only the results.

A basic list of possible approaches:
DGA Mouse - warp pointer to emulate real mouse movement.
XInput2 - not relevant yet.
Hidden Mouse - hide real mouse pointer, capture mouse movement and display a fake mouse pointer using additional drawing commands before glXSwapBuffers each frame (this is okay because cooperative mouse is chiefly used by games which continuously refresh the window).

The solution is not any one of these approaches but all of them, for broadest xserver compatibility.
Comment 296 Paul "TBBle" Hampson 2009-12-08 21:38:31 CST
(In reply to comment #295)
> A basic list of possible approaches:
> XInput2 - not relevant yet.

To whom? Ubuntu's pulled Xorg 7.5 for Lucid, Fedora 12 shipped with Xorg 7.5. Gentoo has it available, to the best of my limited knowledge. Debian only has it in experimental, but it's pretty danged close to hitting unstable from what I've seen.

> DGA Mouse - warp pointer to emulate real mouse movement.

If _I_ was writing the patch, I'd do the XInput 2 version, because it's the least work in Wine and also cleans up the somewhat messy DInput exclusive-mode handling, and then see if I could implement a DGA fallback usefully under the resulting structure. If neither of those was available, I'd suggest Wine just refuse to provide whatever mode the application is asking for.

> Hidden Mouse - hide real mouse pointer, capture mouse movement and display a
> fake mouse pointer using additional drawing commands before glXSwapBuffers each
> frame (this is okay because cooperative mouse is chiefly used by games which
> continuously refresh the window).

This one sounds like a DInput/WineD3D-specific hack, which relies on certain features ("capture mouse movement" for example), the lack of which prompted us to focus on XInput2 in the first place. The key for spotting a hack is the parenthetical qualification which addresses the chief use only.

What games use co-operative mouse, anyway? I thought co-operative mouse would generally be used by non-game things that want to read the mouse while something else is nominally in charge (VoIP software, things like that program with the cat chasing your mouse cursor around the screen)
Comment 297 Forest Hale 2009-12-09 12:09:07 CST
(In reply to comment #296)
> (In reply to comment #295)
> > A basic list of possible approaches:
> > XInput2 - not relevant yet.
> 
> To whom? Ubuntu's pulled Xorg 7.5 for Lucid, Fedora 12 shipped with Xorg 7.5.
> Gentoo has it available, to the best of my limited knowledge. Debian only has
> it in experimental, but it's pretty danged close to hitting unstable from what
> I've seen.

This assumes that everyone runs the very latest and chooses their distribution based on how recently the latest release occurred (switching distribution according to the whims of release cycles), an inappropriate assumption in my view.

> > DGA Mouse - warp pointer to emulate real mouse movement.
> 
> If _I_ was writing the patch, I'd do the XInput 2 version, because it's the
> least work in Wine and also cleans up the somewhat messy DInput exclusive-mode
> handling, and then see if I could implement a DGA fallback usefully under the
> resulting structure. If neither of those was available, I'd suggest Wine just
> refuse to provide whatever mode the application is asking for.

To require XInput2 is unreasonable for the above reason, but to implement support for it before implementing fallbacks is perfectly reasonable.

> > Hidden Mouse - hide real mouse pointer, capture mouse movement and display a
> > fake mouse pointer using additional drawing commands before glXSwapBuffers each
> > frame (this is okay because cooperative mouse is chiefly used by games which
> > continuously refresh the window).
> 
> This one sounds like a DInput/WineD3D-specific hack, which relies on certain
> features ("capture mouse movement" for example), the lack of which prompted us
> to focus on XInput2 in the first place. The key for spotting a hack is the
> parenthetical qualification which addresses the chief use only.

It is extremely common for any game to use DirectInput, and it is always in cooperative mode unless the game is fullscreen.

This affects nearly all games that have a mouse-controlled view turning behavior.

> What games use co-operative mouse, anyway? I thought co-operative mouse would
> generally be used by non-game things that want to read the mouse while
> something else is nominally in charge (VoIP software, things like that program
> with the cat chasing your mouse cursor around the screen)

I do not know of very many applications that use DirectInput, but I know of many games, I do not need to list the many affected games as they should all be linked to this bug already.

Here is the usage pattern in question:
1. Open a window.
2. Attach D3D context.
3. Activate DI cooperative mode.
4. Each frame, poll DI events and utilize either the current mouse position (for a mouse-driven user interface such as in RTS and RPG games, as well as in menus of all games) or the delta (to look around) - wine is not notified of which information is desired.
5. The mouse pointer is hidden or shown according to the whims of the game, Wine does not reliably know which behavior the game is using at any given moment, and both pieces of data (position and delta) must be valid at all times.

When operating with plain X11 input, the only data that can be obtained is the current mouse position, and measuring deltas from this causes border problems.

When I do ports of games to Linux, I have to replace the DI cooperative mode mechanism used in the game with two different modes of operation in X11 - show mouse pointer and behave normally like an application, or hide pointer and warp it back to center frequently frame to get deltas (or use DGA to get the deltas directly without acceleration).

The problem I mentioned is that Wine may have to show the mouse pointer and report deltas at the same time on plain X11 (no DGA, no XInput2), and to this end it might have to draw a mouse pointer before the glXSwapBuffers occurs (in both D3D and GL cases), however this does not help regular applications.

With DGA the mouse movement can be reliably faked based on the deltas.

I do not know if XInput2 will live up to the promises and solve this bug, I certainly hope so and I fully support the idea of implementing an XInput2 solution first - but I still see a need to solve this bug with DGA and plain X11 as well, for users who do not have XInput2 yet.



Note for implementors of delta reading on plain X11:
Each time a mouse move is parsed, it produces a delta from the previous position, however if the mouse position is getting dangerously near the borders (typically whenever it's out of the middle area of the window) a warp is needed to re-center it, this warp produces a move as well and must be ignored - to do this, XSendEvent is used to produce a fake mouse move event in the X11 stream, which updates the "last known" position variables but does not produce a delta (by checking the .send_event flag on the event these fake moves can be filtered out, it is always True if the event is produced by XSendEvent), then when the real mouse move from XWarpPointer comes in immediately after the fake one, it produces no delta because the "last known" position is already the same.  This is the basic mode of operation of all Linux games that require delta movement when DGA is not available.
Comment 298 Vincent 2009-12-09 19:13:14 CST
I once had this very strange bug with Doom3 on Windows XP (not Wine). From that very bug I came to understand how Windows XP handles the mouse in FPS games:

It keeps track of the position of the mouse cursor but simplay doesn't display it and reads out the movement of the mouse too.

So when I played doom, the mouse cursor was displayed. When I moved my mouse to the right, the camera turned right. When I turn it left, the camera turned left, etc, etc.. When the mouse hit the side of the screen, the camera kept going in the direction I moved the mouse.

So... Mouse movement used by DirectInput and also by whatever handles the cursor, but the cursor just isn't displayed and can't focus...

I am not an experienced programmer but this should be extremely easy to implement correctly, in a non ugly manner...
Comment 299 Vitaliy Margolen 2009-12-09 22:13:11 CST
(In reply to comment #297)
If you so want to have DGA mouse - why don't you actually look at what it is, how it works, and if it meats the DInput requirements? If it's freezing pointer in place - it's automatically won't work for Wine. that mode already works just fine. It's the non-exclusive background coop level that's needed by soo many apps that doesn't work.

Also you seems to totally ignore what I said here numerous times - warping mouse is out of the question period end of story. You can not make all applications work this way. You will fix one type and break another type.

The best example are all Quake 2+ engine based games that use dinput (Half-Life even tho based on Q2 engine doesn't use dinput at all). These games incorrectly acquire mouse in game mode as non-exclusive background coop. If you start warping mouse in this coop mode you'll break all programs that show system cursor in the menu for example.

XInput2 does exactly what Wine needs and that's what Wine will use to fix this bug no matter if you like it or not. This means you'll be getting XOrg 7.5 sooner then you wanted.
Comment 300 Warren Dumortier 2009-12-10 06:45:25 CST
I'm very happy to see this bug is being discusses to find a solution, however i have a question, not really important to post in this bur report, but i ask! ;)

Vitaliy Margolen: Do you already have a prototype using XInput 2 or not? But if you have something beginning to work i would really like to test it out.
Comment 301 Forest Hale 2009-12-10 11:30:37 CST
(In reply to comment #299)
> (In reply to comment #297)
> If you so want to have DGA mouse - why don't you actually look at what it is,
> how it works, and if it meats the DInput requirements? If it's freezing pointer
> in place - it's automatically won't work for Wine. that mode already works just
> fine. It's the non-exclusive background coop level that's needed by soo many
> apps that doesn't work.

Actually I was saying that DGA mouse freezes the mouse pointer but it can still be forcefully warped by wine, to mimic normal movement and interact with other applications - but it disables mouse acceleration in doing so, so such behavior is only acceptable when the active window has cooperative dinput active, in all other situations the DGA mouse grab must be released and normal mouse movement used.

To the user the only difference between having a cooperative dinput window active and having a normal window active, is that mouse acceleration changes, and there might be a very slight lag (1 refresh).

All normal application interaction would be preserved.

> Also you seems to totally ignore what I said here numerous times - warping
> mouse is out of the question period end of story. You can not make all
> applications work this way. You will fix one type and break another type.

I did say that DGA support is necessary, I only brought up the "hidden mouse" fallback (where warping is required and the pointer MUST be hidden) as a possible fallback that has many undesirable side effects, I recommended against using such a method if at all possible, because it is not robust at all.

It was only in a summary of possible solutions, and noted as having many problems.

Where as DGA + mouse warping to mimic real movement would be at least somewhat robust.

> The best example are all Quake 2+ engine based games that use dinput (Half-Life
> even tho based on Q2 engine doesn't use dinput at all). These games incorrectly
> acquire mouse in game mode as non-exclusive background coop. If you start
> warping mouse in this coop mode you'll break all programs that show system
> cursor in the menu for example.

You are clearly not understanding what I am talking about then.

This cooperative mode using DGA would ALTER the mouse movement behavior (because wine is really doing the movement), but not disable it, it would still be able to interact with all normal applications even while the cooperative app is focused - but as soon as the app is defocused it would return to normal movement to restore expected behavior (mouse acceleration).

> XInput2 does exactly what Wine needs and that's what Wine will use to fix this
> bug no matter if you like it or not. This means you'll be getting XOrg 7.5
> sooner then you wanted.

I look forward to seeing an XInput2 solution.

However users will continue this discussion until everyone is running xorg 7.5 - and I do not expect that to happen for years, there are still people running debian stable and expecting wine to work.
Comment 302 Valeriy Malov 2009-12-13 09:24:14 CST
(In reply to comment #301)
> However users will continue this discussion until everyone is running xorg 7.5
> - and I do not expect that to happen for years, there are still people running
> debian stable and expecting wine to work.

Is it possible to make optional support for xinput2? I believe that people who are running Debian Stable can wait for stabilization.
Comment 303 Vitaliy Margolen 2009-12-13 12:04:27 CST
> Is it possible to make optional support for xinput2?
Yes, of course for both compile and runtime. However this means DIinput will revert back to the current (broken) behavior.
Comment 304 Valeriy Malov 2009-12-13 12:54:53 CST
(In reply to comment #303)
>However this means DIinput will revert back to the current (broken) behavior.

Do you mean "it just won't work" or "XI2 solution will leave systems without libXi-1.3 at current dinput state"? I'm incompetent here, but I don't really believe that any way of warping will totally solve this problem somehow. Again, I don't know for sure, but I guess that warping brings out other problems (i.e. lithtech games spot warping making aim intermittent)
Comment 305 Vitaliy Margolen 2009-12-13 23:04:58 CST
"current (broken) behavior" means as it is today.
Comment 306 Manuel Soukup 2009-12-21 15:57:09 CST
The patch for 34 works with wine 35 as well

http://bugs.winehq.org/attachment.cgi?id=25097
Comment 307 Manuel Soukup 2010-01-10 09:06:47 CST
patch works with 36 as well
Comment 308 Forest Hale 2010-01-10 15:52:27 CST
(In reply to comment #304)
> (In reply to comment #303)
> >However this means DIinput will revert back to the current (broken) behavior.
> 
> Do you mean "it just won't work" or "XI2 solution will leave systems without
> libXi-1.3 at current dinput state"? I'm incompetent here, but I don't really
> believe that any way of warping will totally solve this problem somehow. Again,
> I don't know for sure, but I guess that warping brings out other problems (i.e.
> lithtech games spot warping making aim intermittent)

That is a different kind of warping than I described.

I am describing a situation where the movement is captured transparently and passed to wine, without updating the mouse pointer location at all, then wine moves the mouse pointer to mimic the expected behavior (while imposing restrictions such as mouse clip rects), as far as all programs (both wine and X11 apps) can tell, it is moving normally.

How this is done is not important, whether it is DGA or XInput2, the result is the same.

What we really want (and XInput2 supposedly delivers) is feedback on movement even when the mouse is pressing against the borders of the clip rect, this is what DirectInput cooperative mode expects.
Comment 309 Warren Dumortier 2010-01-10 16:28:41 CST
Wasn't someone here working on a patch to implement XInput 2?
If so, i'd like to test it...
Comment 310 miche1 2010-01-29 18:18:12 CST
Worked on UT3 for a few days - temporarily got full 360deg motion but it was soon gone (not sure why).  Running wine 1.1.37-2 opensuse 11.1 x86_64 NVidia 9800GT, AMD Phenom quad core, 4GB.  Tried MouseWarpOverride=force and force-box, 
also:
 
env WINEPREFIX="/home/patti/.wine" WINEFORCEMOUSEWARP=yes wine "Z:\PUBLIC\ut3\Binaries\UT3.exe" 
...and...
env WINEPREFIX="/home/patti/.wine" wine "Z:\PUBLIC\ut3\Binaries\UT3.exe" 
...with same result (180deg only)

waaaaaaa....
Comment 311 Darren Thompson 2010-02-03 11:04:10 CST
(In reply to comment #307)
> patch works with 36 as well

Works in 37 fine
Comment 312 miche1 2010-02-03 14:02:59 CST
I'm sorry - I'm noob-ish enough that I don't know how to use the patch.  I suspect it has to be saved as a file and added into the compile sequence for wine?  Can someone point to a fairly simple D.I.Y. on how to incorporate that patch?
http://bugs2.winehq.org/attachment.cgi?id=25097

TY  Patti
Comment 313 Nick Bowler 2010-02-03 15:33:04 CST
I apologize for the noise, but I have to post this.

Please stop using bugzilla as a support forum, or for posting pointless updates such as "patch X still applies, just like it did two weeks ago, as it did two weeks before that, and ...".  People who care whether the patch still applies can try applying it.  Out of the 134 people CC'd to this bug, I am sure that I'm not the only who doesn't like getting wine support questions sent to my personal inbox.

The mailing lists (http://www.winehq.org/forums) exist for a reason.  I think there's even an IRC channel somewhere.

Thanks.
Comment 314 Berillions 2010-02-06 05:09:32 CST
Hello,

I have a problem with the mouse patch because, i applied the patch, compile and make correctly but when i play at game, i have always the mouse problem. I can't turn my characters at 360°.

To play on windowed mode is the problem?

Thanks and sorry for my english, i'm french.
Comment 315 Kirov 2010-02-06 15:12:43 CST
Created attachment 26091 [details]
Resolves mouse problems for ME / ME 2
Comment 316 Kirov 2010-02-06 15:13:39 CST
Uploaded patch for mouse fix.

It was originally made (not by me) for Mass Effect 1, but it works just as well with Mass Effect 2.

No need to set mouse warping to "forced" in the registry.
Comment 317 Berillions 2010-02-07 15:43:05 CST
(In reply to comment #316)
> Uploaded patch for mouse fix.
> 
> It was originally made (not by me) for Mass Effect 1, but it works just as well
> with Mass Effect 2.
> 
> No need to set mouse warping to "forced" in the registry.

Patch doesn't work for me. When i launch the game (Mass Effect 2 or Borderlands) i have an error message.

For Borderlands :
Error told me that i have a problem with Directx9 who is not installed. But i installed it with winetricks before to install the game.

For Mass Effect 2 :
Error told me that i have a problem with my hardware who are bad. 
Without your patch, i can launch and play at this game.
Comment 318 Vitaliy Margolen 2010-02-07 20:22:21 CST
Comment on attachment 26091 [details]
Resolves mouse problems for ME / ME 2

What part of NO HACKS don't you Bontas Marcel understand?
Comment 319 Gilboa Davara 2010-02-07 23:25:11 CST
(In reply to comment #318)
> (From update of attachment 26091 [details])
> What part of NO HACKS don't you Bontas Marcel understand?

Vitally,

Not trying to get into the hack vs. patch solution - but you do understand that as long as there is not official solution and/or officially sanctioned hack to solve this issue this bugzilla entry (or anyone that follows it) will continue to get flooded by hacks and semi-working patches, right?
Trying to fight it will not help, it'll simply increase the noise to signal ratio...

- Gilboa
Comment 320 Manuel Soukup 2010-02-08 08:46:34 CST
My 2 cents to the hack vs fix flamewar.

I know as a dev (I develop in python) it is important to have clean code without hacks and workarounds but this bug affects many applications and most of them are games.

And gamers want to play their games.

When this means to patch wine source so we can play our game than lets do it!

I would say:

Lets patch us __our__ wine version with hacks/patches wahtever so we can play or FIX it in the svn and stop moaning.

This is actually the idea behind open source everyone can submit a patch to make the application work again for him.

I know that there was a discussion that this bug is fixed in a new Xorg release or something but till this is here and the Distros are using it we can patch our versions.

I dont see the point as long as the patches are not pasted into svn there is no problem in the svn code with hacks and stuff and this is actually only a place where ppl submit their solution to a problem. If devs read this thread and think omg another hack they have 2 choices:

1. Get angry because of a patch that is not in svn and is not seen in the actual code

2. See that others try to help other people with a problem in __their__ wine version and be glad to see the open source spirit around. Then close this thread and continue to work on clean wine code

just my thoughts
Comment 321 Sven 2010-02-08 09:30:56 CST
(In reply to comment #320)
> My 2 cents to the hack vs fix flamewar.
> 
> I know as a dev (I develop in python) it is important to have clean code
> without hacks and workarounds but this bug affects many applications and most
> of them are games.
> 
> And gamers want to play their games.
> 
> When this means to patch wine source so we can play our game than lets do it!

The problem is that it's a hack and that it also breaks things. People reporting bugs with this thing switched on waste a lot of valuable time. Then every week, or at the moment every day someone posting that the hack does, or doesn't work doesn't help. This is just some additional useless information in this bug and it's also useless for the devs entering their mailbox. About 90% of the last part of this page is spam and this bug is really hard to read like it is. This is bugzilla, not a forum.

> I would say:
> 
> Lets patch us __our__ wine version with hacks/patches wahtever so we can play
> or FIX it in the svn and stop moaning.

This is not something you do in a few days. It requires a lot of work.

> This is actually the idea behind open source everyone can submit a patch to
> make the application work again for him.

It also BREAKS things, which means it doesn't belong here. Some people will just apply the patch, see things are broken, and report bugs with their broken wine versions. Or they'll just post information about the hacks, which isn't what the bug report is about.

> I know that there was a discussion that this bug is fixed in a new Xorg release
> or something but till this is here and the Distros are using it we can patch
> our versions.
> 
> I dont see the point as long as the patches are not pasted into svn there is no
> problem in the svn code with hacks and stuff and this is actually only a place
> where ppl submit their solution to a problem. If devs read this thread and
> think omg another hack they have 2 choices:
> 
> 1. Get angry because of a patch that is not in svn and is not seen in the
> actual code
> 
> 2. See that others try to help other people with a problem in __their__ wine
> version and be glad to see the open source spirit around. Then close this
> thread and continue to work on clean wine code
> 
> just my thoughts

What someone SHOULD do is create a wiki page, post their hack there and write a clear disclaimer at the top of the wiki page and everywhere near a download link, because some people really do their best to miss every warning. Now if the patch is broken for a certain version of wine, one could edit the wiki page, and tell it's broken, so everyone who's interested knows it's broken. Then they can wait for someone to fix the hack for the newer version.

This would mean no more spam here, no more useless hacks here, and a clear disclaimer that this hack will break things. Then everyone who wants a hack can get their hack, and everyone who only cares about the actual bug and about REALLY fixing it can come here.
Comment 322 Berillions 2010-02-09 02:19:36 CST
In fact, if i play with Wine 1.1.38 not patched, i can move my mouse but i can't use it in the menu. 

But during a game, it's different. Left and Right clic don't work and move the mouse doesn't work too. Mainly when i want choose a conversation's option when Sheppard must to speak. 

You managed to resolve this problem with which patch? 
There are more patch and i don't find a good patch to play correctly at this game. 

I add that i play in windowed mode with wine 1.1.38. 

Thanks for your help.
Comment 323 giovanni.nicola 2010-02-10 05:38:20 CST
I want to clarify some point
The Patch i submitted is for use with FULL SCREEN i could not manage to
get it work in windowed mode
In Full Scrren it breaks some games but till now the mosat important i
found was spellforce.

I suggest you keep an original copy ow wine and use the pathed version
for what it is done for

I developed it for Unreal 3 Engine Games, Unreal 2 Engine Games and
Unreal Engine Games

I personally do not think that some 100hrs of code are a Hack
But if you do not want it i simply will no more publish my patches
Comment 324 Vitaliy Margolen 2010-02-10 08:36:06 CST
(In reply to comment #323)
> I personally do not think that some 100hrs of code are a Hack.
> The Patch i submitted is for use with FULL SCREEN i could not manage to
> get it work in windowed mode.
You said it yourself - if it doesn't cover all cases/fixes only one game - it's a hack.
Comment 325 GreatEmerald 2010-02-10 14:25:32 CST
He said that it covers three Unreal Engine generations, and that's basically what's being affected by this bug. Of course, if it doesn't work in windowed mode, it is a hack, but it's still better than nothing.

If you believe that it's better to post all of the patches/hacks in a Wiki, then you could create a page for it and give the link here, otherwise there's not much use of patches scattered all over the Internet.

By the way, why is this bug still unassigned? It seems that the status should be anything but "New" given that nearly 4 years have passed since the initial bug report...
Comment 326 Jouni Järvinen 2010-02-11 01:12:55 CST
(In reply to comment #325)
> He said that it covers three Unreal Engine generations, and that's basically
> what's being affected by this bug. Of course, if it doesn't work in windowed
> mode, it is a hack, but it's still better than nothing.
> 
> If you believe that it's better to post all of the patches/hacks in a Wiki,
> then you could create a page for it and give the link here, otherwise there's
> not much use of patches scattered all over the Internet.
> 
> By the way, why is this bug still unassigned? It seems that the status should
> be anything but "New" given that nearly 4 years have passed since the initial
> bug report...
I agree with you totally.

I predict a specific response from Vitaliy ...
Comment 327 Dmitry Timoshkov 2010-02-11 02:18:28 CST
(In reply to comment #325)
> By the way, why is this bug still unassigned? It seems that the status should
> be anything but "New" given that nearly 4 years have passed since the initial
> bug report...

http://wiki.winehq.org/Bugs:
Don't ask when the bug will be fixed. If a fix is in progress, it'll likely be posted in the bug.

Wine is an open source and volunteer driven project, feel free to work on
this bug on your own, hire or sponsor someone else to do the job for you.
Comment 328 haarp 2010-02-11 02:37:25 CST
Sorry for yet another mail...But I have to draw a line here. Stop it!
Bugzilla is not a forum. It's not here for discussing the relevance of hacks, other discussions and especially NOT for HELP questions! This page is for _fixing_ bug 6971, and only that.
And Wine is not a democracy. If Vitaliy doesn't want hacks in here, there better won't be any. While I agree that hacks are needed until Xinput 2 is available, it still doesn't justify spamming this bug with useless chatter
For all I care, make a Wiki page for your hacks and maybe link it here. 
The next time someone asks how to compile Wine or why his hack won't work with game xy, I'll go crazy.
Comment 329 Stefano Guidoni 2010-02-11 09:43:09 CST
This bug affects Lost Planet too. At least the demo. In windowed mode or virtual desktop, the mouse escapes the window, in fullscreen mode the mouse works only in menus and not in game (after a while you can't turn around). When using MouseWarpOverride=force, the mouse is stuck at the center of the screen in menus (you have to use the keyboard), but it works correctly in game.
Comment 330 Manuel Soukup 2010-02-11 12:04:01 CST
I created a wiki page.

Please test the patches here and include it with a description into the wiki.

I made a sample and it should be clear how it should be done

If another patch from here works with a special game or so please upload the patch again at the wiki and link it to the upload and create a new table with the patch link and so on.

If this is done the admins can delete some of the hacks here so it gets more clear and at the end only one attachment is in here. That for the FIX

Wikipage:

http://wiki.winehq.org/Bug6971

Manuel
Comment 331 Plague 2010-03-01 13:59:27 CST
I know this is not a forum, but I just have to say this...

Yes, the only proper way to fix this bug is using XInput2, no doubt. But the patch creating a new option "force-box" for MouseWarpOverride IS A PROPER SOLUTION also. Why? Because wine already has a MouseWarpOverride option that is there to go around some problems and it also breaks other applications. This patch only creates a solution for other apps (and breaks some other). So it should be part of wine main tree.

This issue should remain open until proper XInput2 is in wine, but "force-box" option should be added to main branch also.
Comment 332 Vitaliy Margolen 2010-03-05 23:55:29 CST
Created attachment 26631 [details]
A possible Xi2 patch

Here is a possible patch that might work (a bit hackish for now). However will have to wait until these two bugs are fixed:
https://bugs.freedesktop.org/show_bug.cgi?id=26921
https://bugs.freedesktop.org/show_bug.cgi?id=26922
Comment 333 Austin English 2010-03-06 02:49:47 CST
(In reply to comment #332)
> Created an attachment (id=26631) [details]
> A possible Xi2 patch
> 
> Here is a possible patch that might work (a bit hackish for now). However will
> have to wait until these two bugs are fixed:
> https://bugs.freedesktop.org/show_bug.cgi?id=26921
> https://bugs.freedesktop.org/show_bug.cgi?id=26922

It looks like you forgot the test program in https://bugs.freedesktop.org/show_bug.cgi?id=26921
Comment 334 Henri Verbeet 2010-03-06 07:24:02 CST
(In reply to comment #332)
> Here is a possible patch that might work (a bit hackish for now). However will
> have to wait until these two bugs are fixed:
> https://bugs.freedesktop.org/show_bug.cgi?id=26921
> https://bugs.freedesktop.org/show_bug.cgi?id=26922
That's more or less by design. If you want raw events you should select them on the individual slaves. It would probably be better if master devices didn't send raw events at all to avoid confusing people though. (Fwiw, I do have some partial XI2 patches as well, but they have some issues still.)
Comment 335 Vitaliy Margolen 2010-03-06 13:04:20 CST
(In reply to comment #334)
> That's more or less by design. If you want raw events you should select them on
> the individual slaves.
That's broken. The whole idea about selecting individual device to get more events comparing to _all_ devices and not getting all events is wrong.

Besides there is seems to be no way to actually get the mouse device ID. There are always some other stuff that has nothing to do with mouse:

Virtual core pointer                           id=2    [master pointer  (3)]
   Virtual core XTEST pointer                  id=4    [slave  pointer  (2)]
   Logitech USB Gaming Mouse                   id=7    [slave  pointer  (2)]
   Microsoft Comfort Curve Keyboard 2000       id=8    [slave  pointer  (2)]
Comment 336 Vitaliy Margolen 2010-05-16 22:16:08 CDT
*** Bug 22729 has been marked as a duplicate of this bug. ***
Comment 337 Alexandre Julliard 2010-06-16 08:13:22 CDT
XI2 support won't happen for 1.2.
Comment 338 Dan Kegel 2010-06-28 11:57:41 CDT
Roderick reports that Vitaliy's patch is still good, makes Microsoft's DirectInput test program called mouse.exe happy, and helps games Mass Effect 2 and Dead Space.
Comment 339 Dan Kegel 2010-06-28 11:58:32 CDT
Oh, and he says he tested on Ubuntu 10.04.
Comment 340 Manuel Soukup 2010-06-28 14:29:27 CDT
Hi

I can't confirm that.

Vitaliy's patch and Borderlands are not working.Cant turn mouse 360°

some info:

wine-1.2-rc5
X.Org X Server 1.7.7
Release Date: 2010-05-04
2.6.34 kernel
Vitalies patch applied no errors during that.

Thanks
Comment 341 Johan Palmqvist 2010-06-28 15:48:41 CDT
Hard Truck Apocalypse and Hard Truck Apocalypse: Rise Of Clans are not improved even when using Vitaliy's patch (none of the other mouse patches has helped either). It's impossible to rotate the cannons freely, which makes the games more or less unplayable. What's the difference between the games that works and the ones that doesn't work?
Comment 342 Vitaliy Margolen 2010-06-28 19:28:24 CDT
(In reply to comment #340)
> Vitaliy's patch and Borderlands are not working.Cant turn mouse 360°
> X.Org X Server 1.7.7
Your xorg doesn't have Xi2. Upgrade to 1.8
Comment 343 Evgenii Burmentev [:virus_found] 2010-06-29 12:42:37 CDT
I built wine from the latest commit with "A possible Xi2 patch" by Vitaliy. In mount&blade warband all the main menu entries aren't clickable. I hear a sound of a click, but I go nowhere from the menu. Frustrating.
Comment 344 Dan Kegel 2010-06-29 12:53:41 CDT
What distro/version?  If you're not on ubuntu 10.04, your X server is probably too old to support XInput2, which his patch requires.
Comment 345 Evgenii Burmentev [:virus_found] 2010-06-29 14:36:32 CDT
(In reply to comment #344)
> What distro/version?  If you're not on ubuntu 10.04, your X server is probably
> too old to support XInput2, which his patch requires.

Arch Linux, xorg-server 1.8.1.902
What else can be to blame?
Comment 346 Valeriy Malov 2010-06-29 15:53:20 CDT
I'm not a developer, but some time ago elsewhere it was mentioned that current Xi2 lacks some functionality. See wiki page for Bug 6971
Comment 347 Luke Bratch 2010-06-30 17:37:52 CDT
I've tested the Xi2 patch with Mass Effect 1, Mass Effect 2 demo [1] and AvP 2 MP demo [2], using Xorg 1.8.1.902.

ME2 demo:
Mouse seems to work perfectly - movement and click registering.

ME1:
Mouse doesn't really work at all.  It doesn't seem to register any clicks at all when in game, but it did register *a couple* when clicking furiously in the menu.  Movement doesn't really work at all, but when in game and waving the mouse area furiously, the camera does twitch by a pixel or two in certain directions.  These things are true in windowed mode and fullscreen, and whether or not the pointer is within the window.

AvP 2 MP demo:
Mouse works well in the menu, but not well in game.  In game left click appears to become stuck down after using it once.  When the pointer is inside the window (including in fullscreen mode) the camera spins around wildly.  In windowed mode, with the pointer outside the window, the camera works as expected relative to mouse movements - until you move the pointer back inside the window, at which point it goes wild again.

I find the two Mass Effect results interesting, as they both use Unreal Engine 3.

[1] http://static.cdn.ea.com/bioware/u/f/eagames/bioware/masseffect2/ME2_DEMO/MassEffect2DemoEN.exe
[2] http://www.fileplanet.com/80808/80000/fileinfo/Aliens-Vs.-Predator-2-Multiplayer-Demo
Comment 348 Luke Bratch 2010-06-30 18:59:33 CDT
Additionally, the Xi2 patch causes the X11 pointer to always be visible in Anarchy Online (it should be hidden).  It seems reasonable to assume that this affects other games too.
Comment 349 Austin English 2010-07-02 04:11:56 CDT
(In reply to comment #338)
> Roderick reports that Vitaliy's patch is still good, makes Microsoft's
> DirectInput test program called mouse.exe happy, and helps games Mass Effect 2
> and Dead Space.

Works pretty well for Singularity as well, but doesn't work at all when using the sniper rifle. You're stuck wherever you were aiming before zooming.
Comment 350 Nagy Gergő 2010-07-03 07:36:59 CDT
In Steam download Thief - Deadly Shadows the mouse cannot turn around in X axis is still an issue.

Wine 1.2rc6
Comment 351 Vitaliy Margolen 2010-07-03 08:11:17 CDT
Created attachment 29313 [details]
Xi2 patch with xorg bug workaround

Here is another patch that works around xorg bug. Try with with. Make sure you do have Xorg 1.8 (aka 7.5).
Comment 352 Luke Bratch 2010-07-03 08:54:27 CDT
Hi

That patch fixes the click registering issues in ME1 and AvP 2 MP Demo, but still both have the same mouse movement issues (ME1 - no movement, AvP 2 - crazy movement with mouse inside window, normal movement with mouse outside window) as describribed above.
Comment 353 Nagy Gergő 2010-07-03 09:07:22 CDT
I will ignore patch's. THIS is wine's problem. A patch should be not needed in normal usage. Please fix this so no patch or other magic needed.
Comment 354 Danila Sentyabov 2010-07-03 09:22:06 CDT
(In reply to comment #353)
If you want something fixed - fix it yourself or help those who could fix it (by testing patches, for example). If you can't or won't help - refrain from posting, please.
Comment 355 haarp 2010-07-03 09:22:21 CDT
A patch is one of the steps towards fixing Wine. Don't complain about it, it will find its way into Wine soon enough.
Be thankful that with XI2 it's actually possible to fix this and that somebody is working on this!
Having said that: Thank you Vitaliy so far!
Comment 356 Tobias Jakobi 2010-07-03 09:23:55 CDT
(In reply to comment #353)
> I will ignore patch's. THIS is wine's problem. A patch should be not needed in
> normal usage. Please fix this so no patch or other magic needed.
Go fix it yourself or pay someone to fix it. If you don't want to do that, than just STFU, k?! ;)
Comment 357 Nagy Gergő 2010-07-03 10:15:35 CDT
(In reply to comment #356)
> (In reply to comment #353)
> > I will ignore patch's. THIS is wine's problem. A patch should be not needed in
> > normal usage. Please fix this so no patch or other magic needed.
> Go fix it yourself or pay someone to fix it. If you don't want to do that, than
> just STFU, k?! ;)

You are very intelligent!

So if I'm not a coder and a tech guru who will not patching and debugging, because I cannot, than I should "STFU".

If you also could not say anything useful please do not comment more.

I just noticed that this bug is still exist.

Everybody can download a free demo from the game:
http://www.gamershell.com/download_6062.shtml

From me that is all.
Comment 358 Dan Kegel 2010-07-03 10:23:05 CDT
Right, people who are not helping solve this problem, but instead are just asking for somebody else to solve it, should avoid posting in Bugzilla.
Comment 359 Manuel Soukup 2010-07-03 10:28:12 CDT
Hi 

Thanks for the patch Vitaly.

I will recompile wine while i get some food and post the result.

Does the patch work with:

manuel@think:/mnt/data$ X -version
+
X.Org X Server 1.7.7
Release Date: 2010-05-04
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.32-5-amd64 x86_64 Debian
Current Operating System: Linux think 2.6.34-0.slh.9-sidux-amd64 #1 SMP PREEMPT
Sat Jun 12 23:27:41 UTC 2010 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.34-0.slh.9-sidux-amd64
root=/dev/mapper/cryptVG-root ro quiet
Build Date: 03 June 2010  03:01:44PM
xorg-server 2:1.7.7-2 (Julien Cristau <jcristau@debian.org>) 
Current version of pixman: 0.16.4
    Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.

Or is it just for X Server 1.8 ? And if so when will be X 1.8 in Debian
unstable ?

Another note: the patch http://bugs.winehq.org/attachment.cgi?id=25097 does not
work anymore with wine greater than 42. I dont know if this is because my X
version has changed and i have now X2 input or if wine has changed and it is
not working anymore. This affects Borderlands version 1.2 of the game.

If my X is not Xinput 2 and the patch from Vitaly is only for X2 then please
submit a new patch for the older X versions without X2.

Thanks for your great support on this really long living bug in wine.
Comment 360 Dan Kegel 2010-07-03 10:32:28 CDT
We are focused on XInput2 because that's how X.org is providing the needed
relative motion events.   In other words, there will probably be *no*
fix provided for X versions below 1.8.  If you want to help test these
patches, the easiest way at the moment may be to install Ubuntu 10.04,
which is the first distro that ships with X 1.8.
Comment 361 Rich 2010-07-03 10:39:17 CDT
(In reply to comment #360)
> We are focused on XInput2 because that's how X.org is providing the needed
> relative motion events.   In other words, there will probably be *no*
> fix provided for X versions below 1.8.  If you want to help test these
> patches, the easiest way at the moment may be to install Ubuntu 10.04,
> which is the first distro that ships with X 1.8.

Speaking as someone running 10.04, isn't it the case that it's running X 1.7 with a lot of backported 1.8 features?

Also, up to date 10.04 currently thinks I have
$ X -version

X.Org X Server 1.7.6
Release Date: 2010-03-17
X Protocol Version 11, Revision 0

Is there an update I missed somewhere, or is this sufficient for testing patches from this bug?
Comment 362 Dan Kegel 2010-07-03 11:55:33 CDT
Sigh.  I guess I'm poorly informed about exact version numbers, but I'm pretty sure Ubuntu 10.04 is sufficient for testing XInput2-based patches.
Comment 363 James Eder 2010-07-03 12:23:43 CDT
Alternatively, both Fedora 13 and openSUSE 11.3 (to be released 15 Jul 2010)
both report 1.8.0 in their version strings.  Hopefully other distributions are
not far behind if not already there.
Comment 364 Austin English 2010-07-03 12:37:41 CDT
(In reply to comment #351)
> Created an attachment (id=29313) [details]
> Xi2 patch with xorg bug workaround
> 
> Here is another patch that works around xorg bug. Try with with. Make sure you
> do have Xorg 1.8 (aka 7.5).

Works fine with Singularity, in lucid, with wine 1.2-rc6 and Xorg 1.7.6:
X.Org X Server 1.7.6
Release Date: 2010-03-17
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-27-server x86_64 Ubuntu
Current Operating System: Linux midna 2.6.31-11-rt #154-Ubuntu SMP PREEMPT RT Wed Jun 9 13:40:34 UTC 2010 x86_64
Kernel command line: root=UUID=e1074dbb-7170-4709-b092-f49b773a2898 ro quiet splash 
Build Date: 16 June 2010  09:34:29AM
xorg-server 2:1.7.6-2ubuntu7.2 (For technical support please see http://www.ubuntu.com/support) 
Current version of pixman: 0.16.4
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.


the sniper bug from the first patch is fixed (zooming would not allow you to move the mouse). Mouse also works in the menu's, where it did not with mwo=force.

One nitpick, you forgot this from configure.ac:
+AC_ARG_WITH(xinput2,    AS_HELP_STRING([--without-xinput2],[do not use the Xinput extension]),
+            [if test "x$withval" = "xno"; then ac_cv_header_X11_extensions_XInput2_h=no; fi])
Comment 365 Manuel Soukup 2010-07-03 12:45:07 CDT
It seem like Ubuntu 10.04 does not ship X 1.8:

"
X Server 1.8 with its HAL replacement and new configuration system can be found in Fedora 13 and openSUSE 11.3 once released. Distributions shipping soon like Ubuntu 10.04 LTS are sticking to using X Server 1.7.x, but X Server 1.8 (or ideally X Server 1.9 / X.Org 7.6) will be picked up by the release of Ubuntu 10.10 later in the year
"
Form Phornix (http://www.phoronix.com/scan.php?page=article&item=xorg_server_18&num=1)

Also this Post is backing up that Lucid will ship the older X
(http://www.phoronix.com/scan.php?page=news_item&px=ODA5OA)

But as Ubuntu changed their homepage layout and they go more for normal user without tech specs anymore i could not verify what features lucid has.
Comment 366 MCpaul34 2010-07-04 14:40:06 CDT
Mouse in the S.T.A.L.K.E.R game series new works very well with the patch!
Great work!

For ubuntu lucid lynx users who want to test the patch: the best way to have the latest xorg is to use the xorg-edgers ppa.
Comment 367 Roman Tetelman 2010-07-05 12:50:16 CDT
the patch allows the mouse to escape the window when running in a virtual desktop or windowed, so warping the mouse to the window's border is probably still needed (or is there a better way? if you only warp the mouse it's possible (if a little unlikely) to click outside and make the window lose focus). also games will continue to receive mouse events when they don't have focus.
Comment 368 Vitaliy Margolen 2010-07-09 14:27:54 CDT
*** Bug 23579 has been marked as a duplicate of this bug. ***
Comment 369 Paul "TBBle" Hampson 2010-07-10 09:12:44 CDT
Debian has Xorg 1.8 in their "experimental" tree: http://packages.debian.org/search?keywords=xserver-xorg-core
Comment 370 Matt Chisholm 2010-07-13 10:15:58 CDT
I'm running Mac OS X and thanks to the wonderful work of doh123 (Wineskin developer) Mac OS X users can now easily patch wine source using Terminal...I'm trying to use the Xi2 patch but I am unsure as to why I cannot successfully complete the build. What is the optimal wine source for the Xi2 patch? It shows as unspecified at the top of the page...It just hasn't worked for me (although I have patched source for, and played the STALKER series without any issues using the "dlls/dinput/mouse.c patch). I've also broken down the patch and created separate patches for every diff that is included in the new Xi2 patch...creating 10 different patches...all except 2 of the diffs give me a successful message except the "dlls/winex11.drv/winex11.drv.spec" and the "dlls/winex11.drv/x11drv_main.c"  diffs which gives me an error message of a malformed line. Can anyone offer me insight on this or perhaps tell me what source this patch was written for?

This is the my Terminal input while trying to patch the 1.2rc7 source

[spoiler] can't find file to patch at input line 40
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|From 53cebc206afab1684c432a1eda224ea9f568c3cf Mon Sep 17 00:00:00 2001
|From: Vitaliy Margolen <wine-patches@kievinfo.com>
|Date: Sat, 3 Jul 2010 07:06:46 -0600
|Subject: Dinput/x11drv: Use Xi2 extension if available.
| Workaround current xorg bug that results in duplication of events.
|Reply-To: wine-devel@winehq.org
|X-Identity-Key: id6
|To: wine-patches@winehq.org
|MIME-Version: 1.0
|Content-Type: multipart/mixed; boundary="------------1.7.1"
|
|This is a multi-part message in MIME format.
|--------------1.7.1
|Content-Type: text/plain; charset=UTF-8; format=fixed
|Content-Transfer-Encoding: 8bit
|
|---
| configure                         |   56 ++++++++
| configure.ac                      |   12 ++
| dlls/dinput/dinput_main.c         |   47 ++++++-
| dlls/dinput/mouse.c               |    8 +-
| dlls/winex11.drv/event.c          |    3 +-
| dlls/winex11.drv/mouse.c          |  260 +++++++++++++++++++++++++++++++++++--
| dlls/winex11.drv/winex11.drv.spec |    2 +
| dlls/winex11.drv/x11drv.h         |    3 +
| dlls/winex11.drv/x11drv_main.c    |    1 +
| include/config.h.in               |    6 +
| 10 files changed, 378 insertions(+), 20 deletions(-)
|
|
|--------------1.7.1
|Content-Type: text/x-patch; name="0001-Dinput-x11drv-Use-Xi2-extension-if-available.patch"
|Content-Transfer-Encoding: 8bit
|Content-Disposition: attachment; filename="0001-Dinput-x11drv-Use-Xi2-extension-if-available.patch"
|
|diff --git a/configure b/configure
|index 37b3a7d..45a3648 100755
|--- a/configure
|+++ b/configure
--------------------------
File to patch: wine-1.2-rc7/configure
patching file wine-1.2-rc7/configure
can't find file to patch at input line 114
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/configure.ac b/configure.ac
|index 61f376e..74b8f88 100644
|--- a/configure.ac
|+++ b/configure.ac
--------------------------
File to patch: wine-1.2-rc7/configure.ac
patching file wine-1.2-rc7/configure.ac
can't find file to patch at input line 144
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/dlls/dinput/dinput_main.c b/dlls/dinput/dinput_main.c
|index 04c62f8..c9f20d1 100644
|--- a/dlls/dinput/dinput_main.c
|+++ b/dlls/dinput/dinput_main.c
--------------------------
File to patch: wine-1.2-rc7/dlls/dinput/dinput_main.c
patching file wine-1.2-rc7/dlls/dinput/dinput_main.c
Hunk #3 succeeded at 892 (offset -46 lines).
Hunk #4 succeeded at 1035 (offset -46 lines).
can't find file to patch at input line 224
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/dlls/dinput/mouse.c b/dlls/dinput/mouse.c
|index e05d9e2..278d8e6 100644
|--- a/dlls/dinput/mouse.c
|+++ b/dlls/dinput/mouse.c
--------------------------
File to patch: wine-1.2-rc7/dlls/dinput/mouse.c
patching file wine-1.2-rc7/dlls/dinput/mouse.c
can't find file to patch at input line 250
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/dlls/winex11.drv/event.c b/dlls/winex11.drv/event.c
|index 8fc955a..c4b90a8 100644
|--- a/dlls/winex11.drv/event.c
|+++ b/dlls/winex11.drv/event.c
--------------------------
File to patch: wine-1.2-rc7/dlls/winex11.drv/event.c
patching file wine-1.2-rc7/dlls/winex11.drv/event.c
can't find file to patch at input line 266
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/dlls/winex11.drv/mouse.c b/dlls/winex11.drv/mouse.c
|index cf988c9..681d20b 100644
|--- a/dlls/winex11.drv/mouse.c
|+++ b/dlls/winex11.drv/mouse.c
--------------------------
File to patch: wine-1.2-rc7/winex11.drv/mouse.c
wine-1.2-rc7/winex11.drv/mouse.c: No such file or directory
Skip this patch? [y] n
File to patch: wine-1.2-rc7/dlls/winex11.drv/mouse.c
patching file wine-1.2-rc7/dlls/winex11.drv/mouse.c
can't find file to patch at input line 556
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/dlls/winex11.drv/winex11.drv.spec b/dlls/winex11.drv/winex11.drv.spec
|index ab61f54..b6f85d1 100644
|--- a/dlls/winex11.drv/winex11.drv.spec
|+++ b/dlls/winex11.drv/winex11.drv.spec
--------------------------
File to patch: wine-1.2-rc7/winex11.drv/winex11.drv.spec
wine-1.2-rc7/winex11.drv/winex11.drv.spec: No such file or directory
Skip this patch? [y] n
File to patch: wine-1.2-rc7/dlls/winex11.drv/winex11.drv.spec
patching file wine-1.2-rc7/dlls/winex11.drv/winex11.drv.spec
can't find file to patch at input line 566
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/dlls/winex11.drv/x11drv.h b/dlls/winex11.drv/x11drv.h
|index 1cd610d..f52f65b 100644
|--- a/dlls/winex11.drv/x11drv.h
|+++ b/dlls/winex11.drv/x11drv.h
--------------------------
File to patch: wine-1.2-rc7/dlls/winex11.drv/x11drv.h
patching file wine-1.2-rc7/dlls/winex11.drv/x11drv.h
can't find file to patch at input line 587
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/dlls/winex11.drv/x11drv_main.c b/dlls/winex11.drv/x11drv_main.c
|index b07061c..546ea7d 100644
|--- a/dlls/winex11.drv/x11drv_main.c
|+++ b/dlls/winex11.drv/x11drv_main.c
--------------------------
File to patch: wine-1.2-rc7/dlls/winex11.drv/x11drv_main.c
patching file wine-1.2-rc7/dlls/winex11.drv/x11drv_main.c
can't find file to patch at input line 599
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/include/config.h.in b/include/config.h.in
|index f365fca..7b69c9f 100644
|--- a/include/config.h.in
|+++ b/include/config.h.in
--------------------------
File to patch: wine-1.2-rc7/include/config.h.in
patching file wine-1.2-rc7/include/config.h.in
Matt-Chisholms-MacBook-Pro-15:WS3CustomBuild DankOS$ ./build wine-1.2-rc7
Build environment being moved into place [/spoiler]
Comment 371 Vitaliy Margolen 2010-07-13 23:12:23 CDT
(In reply to comment #370)
> Matt Chisholm <matthewdchisholm@gmail.com>

You must be the most selfish and dumb or ignorant person of all the 150 people who are monitoring this bug!

Admin please remove his post and remove his account from bugzilla. Obviously he has no clue what bugzilla is for and can not read!
Comment 372 Austin English 2010-07-14 00:57:12 CDT
(In reply to comment #371)
> (In reply to comment #370)
> > Matt Chisholm <matthewdchisholm@gmail.com>
> 
> You must be the most selfish and dumb or ignorant person of all the 150 people
> who are monitoring this bug!
> 
> Admin please remove his post and remove his account from bugzilla. Obviously he
> has no clue what bugzilla is for and can not read!

While I agree that comment doesn't belong on this bug, I see no reason why his account should be removed. A warning is in order, not a ban.
Comment 373 Matt Chisholm 2010-07-14 14:05:51 CDT
(In reply to comment #371)
> (In reply to comment #370)
> > Matt Chisholm <matthewdchisholm@gmail.com>
> 
> You must be the most selfish and dumb or ignorant person of all the 150 people
> who are monitoring this bug!
> 
> Admin please remove his post and remove his account from bugzilla. Obviously he
> has no clue what bugzilla is for and can not read!

Actually Vitaliy I'm none of those...and I still don't think you're pompous even though that's how you just presented yourself to me. Please direct me to the rules page so I don't make the same mistake twice.

Warning noted.

How can I present my findings of this bug if the source information is unspecified.
Comment 374 Daniel Harvison 2010-07-14 16:05:06 CDT
(In reply to comment #371)
> (In reply to comment #370)
> > Matt Chisholm <matthewdchisholm@gmail.com>
> 
> You must be the most selfish and dumb or ignorant person of all the 150 people
> who are monitoring this bug!
> 
> Admin please remove his post and remove his account from bugzilla. Obviously he
> has no clue what bugzilla is for and can not read!

No disrespect to your technical skills...but someone needs to make you calm down.
Comment 375 Dan Kegel 2010-07-14 16:50:47 CDT
re comment 371:
"If you think that by threatening me you can get me to do what you want... 
Well, that's where you're right. But - and I am only saying that because I care -
there's a lot of decaffeinated brands on the market that are just as tasty as the real thing."
(Real Genius, 1985)
Comment 376 Dan Kegel 2010-07-17 08:36:15 CDT
*** Bug 22282 has been marked as a duplicate of this bug. ***
Comment 377 madscientist 2010-07-18 10:07:22 CDT
Created attachment 29687 [details]
Fix for mouse "escapes" window

this patch fixes over the window edge/border bugs in scrolling games. it was tested on warcraft iii. awaiting feedback for other games/applications.

cheers,
Comment 378 Nagy Gergő 2010-07-18 13:59:00 CDT
(In reply to comment #377)
> Created an attachment (id=29687) [details]
> Fix for mouse "escapes" window
> 
> this patch fixes over the window edge/border bugs in scrolling games. it was
> tested on warcraft iii. awaiting feedback for other games/applications.
> 
> cheers,

Maybe I made something wrong I patch the wine 1.2 final source as:
patch -p1 > madscientist-X11DRV_LeaveNotify.patch

It made 4-5 lines, so it was patched...
I tested in Thief-Deadly Shadows and America's Army 3, both has the same mouse could not escape from the window so you could not turn around, this patch DID NOT WORK.
Everybody can test it at least America's Army is totally free!
Comment 379 Berillions 2010-07-18 15:26:58 CDT
(In reply to comment #378)
This patch doesn't work with Wine 1.2 source.
Comment 380 Manu 2010-07-18 15:36:26 CDT
(In reply to comment #378)
> Maybe I made something wrong I patch the wine 1.2 final source as:
> patch -p1 > madscientist-X11DRV_LeaveNotify.patch

I don't know if it works with wine 1.2 (stable), but even if it does, you should read the patch file to the patch command, not write into the file.
wrong: patch -p1 > foo.patch
correct: patch -p1 < foo.patch
Comment 381 Ruslan Kabatsayev 2010-07-18 15:55:27 CDT
(In reply to comment #380)
> (In reply to comment #378)
> > Maybe I made something wrong I patch the wine 1.2 final source as:
> > patch -p1 > madscientist-X11DRV_LeaveNotify.patch
> 
> I don't know if it works with wine 1.2 (stable), but even if it does, you
> should read the patch file to the patch command, not write into the file.
> wrong: patch -p1 > foo.patch
> correct: patch -p1 < foo.patch

And even better, to not confuse read&write of a file, use
patch -p1 -i foo.patch
Comment 382 Nagy Gergő 2010-07-18 16:00:45 CDT
> And even better, to not confuse read&write of a file, use
> patch -p1 -i foo.patch

Thank, but I patch it good just the posting was wrong....
I do patch it, and it is not working on 1.2 final.
Comment 383 madscientist 2010-07-19 00:17:01 CDT
(In reply to comment #378)
> Maybe I made something wrong I patch the wine 1.2 final source as:
> patch -p1 > madscientist-X11DRV_LeaveNotify.patch
> 
> It made 4-5 lines, so it was patched...
> I tested in Thief-Deadly Shadows and America's Army 3, both has the same mouse
> could not escape from the window so you could not turn around, this patch DID
> NOT WORK.
> Everybody can test it at least America's Army is totally free!

this fix does nothing to warp or prevent regular mouse motion outside windows. instead it properly notifies them with a simulated WM_MOUSEMOVE clipped to their client edge when the pointer leaves the window, which fixes edge scrolling.

patch was diff'd and tested against 1.2 final so i'm not sure why it wouldn't apply. please post some more details.
Comment 384 Berillions 2010-07-19 02:24:52 CDT
(In reply to comment #383)
> this fix does nothing to warp or prevent regular mouse motion outside windows.
> instead it properly notifies them with a simulated WM_MOUSEMOVE clipped to
> their client edge when the pointer leaves the window, which fixes edge
> scrolling.
> 
> patch was diff'd and tested against 1.2 final so i'm not sure why it wouldn't
> apply. please post some more details.

Hello,
I retry your patch with Wine source 1.2.
If i use "patch -p0 < your_patch.patch", I have 5 errors (Hunk failed)
But i use "patch -p1 < your_patch.patch", It's succeeded.
Comment 385 ultrageek.lloyd 2010-07-19 19:59:44 CDT
(In reply to comment #351)
> Created an attachment (id=29313) [details]
> Xi2 patch with xorg bug workaround
> 
> Here is another patch that works around xorg bug. Try with with. Make sure you
> do have Xorg 1.8 (aka 7.5).

Tested and confirmed working with Xorg 1.8.1.902 and latest wine git, using Mass Effect 2 as the test case.  I was actually just looking into this with the intent to fix it.  Guess you beat me to it :P  Nice work in any case.

My only gripe with the patch is the profusion of magic numbers.  I would suggest using #define's to make the code more readable and more robust, but it looks like that is not common practice in the wine code base.  One other thought is that it might be a good idea to translate the rest of the dinput API implimentation to XInput2.  It seems like there is already a pretty straightforward 1:1 correspondence between a lot of the dinput functions and XInput2 functions.

Just my 2 cents.  Thanks for the patch, and keep up the good work.  Now off to play some ME2
Comment 386 J.Nicolaisen 2010-08-04 09:06:10 CDT
I applied the Xi2 patch with xorg bug workaround by Vitaliy Margolen to wine 1.3.0 source (via edited gentoo ebuild). It applied OK.

In Tomb Raider: Anniversary (wine desktop), the mouse can still leave the window and in addition, the mouse movement is totally crazy - as if the sensitivity was super high, but I couldn't look up or down properly anymore, and the view would just spin like crazy (always in the same direction) and jitter quickly on top of that. Without this patch, the game works fine, just the mouse leaves the window sometimes on really fast moves.

TRA without winedesktop, in fullscreen (I didn't find out how to run this game windowed, so I basically NEED wine desktop to keep the resolution to something my graphics card is happy with), still has the weird mouse issue. Lara keeps spinning counterclockwise, no matter in which direction I move the mouse.

Same problem with TR: Legend (same engine).

In Far Cry (wine desktop), the X cursor is outside the window during the menu; most of the menu doesn't work because of this. I was unable to load a saved game or even start a new game using the menu, so could not test ingame. I get a lot of:

fixme:dinput:SysMouseAImpl_Acquire Clipping cursor to (240,217)-(1046,842)

Far Cry without wine desktop, in windowed mode, only allows me to use the menu when I make sure the X cursor is *also* in the window... during the game, when I turn, of course the x cursor leaves the window, and pressing Fire (mouse1) focuses the underlying window and the FarCry window goes to the back. Not really playable like this; movement in game is normal though.

A GL Quake derivative (no wine desktop) worked OK with the patched wine.

Baldur's Gate II (wine desktop) still can't scroll - the X cursor leaves the window.

BG II run without wine desktop, in windowed mode, does scroll - x cursor still leaves the window, but wine cursor doesn't, and the game scrolls properly.

Looks like "we're getting there". Problems with games that are run in wine desktop though; Far Cry should ignore the X cursor for its menu input and for actions in game; TR:A / TR:L have continuous spinning view problem.
Comment 387 madscientist 2010-08-04 09:21:38 CDT
(In reply to comment #386)
> ...
> jitter quickly on top of that. Without this patch, the game works fine, just
> the mouse leaves the window sometimes on really fast moves.
> ...
> Baldur's Gate II (wine desktop) still can't scroll - the X cursor leaves the
> window.
> ...
can you confirm that these aren't fix under this patch? http://bugs.winehq.org/attachment.cgi?id=29687
Comment 388 Dan Kegel 2010-08-04 09:39:54 CDT
(In reply to comment #386)
> I applied the Xi2 patch with xorg bug workaround by Vitaliy Margolen to wine
> 1.3.0 source (via edited gentoo ebuild). It applied OK.

Which version of X are you running?
Comment 389 J.Nicolaisen 2010-08-04 10:18:50 CDT
(In reply to comment #388)
> (In reply to comment #386)
> > I applied the Xi2 patch with xorg bug workaround by Vitaliy Margolen to wine
> > 1.3.0 source (via edited gentoo ebuild). It applied OK.
> 
> Which version of X are you running?

X.Org X Server 1.8.1.902 (1.8.2 RC 2)
Comment 390 J.Nicolaisen 2010-08-04 10:20:26 CDT
(In reply to comment #387)
> (In reply to comment #386)
> > ...
> > jitter quickly on top of that. Without this patch, the game works fine, just
> > the mouse leaves the window sometimes on really fast moves.
> > ...
> > Baldur's Gate II (wine desktop) still can't scroll - the X cursor leaves the
> > window.
> > ...
> can you confirm that these aren't fix under this patch?
> http://bugs.winehq.org/attachment.cgi?id=29687

Do I have to remove the other patch before applying this one?
Comment 391 madscientist 2010-08-04 10:34:08 CDT
(In reply to comment #390)
> Do I have to remove the other patch before applying this one?

yes, would be better if you tested it on a clean source. it should fix most of the bugs you described.
Comment 392 J.Nicolaisen 2010-08-04 11:24:36 CDT
madscientist, that patch did not fix those problems. The behaviour is practically identical to unpatched wine.
Comment 393 Dmitry Timoshkov 2010-08-08 04:45:52 CDT
*** Bug 13603 has been marked as a duplicate of this bug. ***
Comment 394 quaker 2010-09-01 13:44:57 CDT
i use the "Xi2 patch with xorg bug workaround" applied in wine-git and i have no mouse problems since, the cursor doesn't stay in window but it always catches the right events, so i can turn however i want :) thx madscientist. It works for all stalker games for example.
Comment 395 Dušan Hokův 2010-09-04 06:03:08 CDT
With wine 1.3.2 and using small change from bug 13087 comment 2 is game Hard truck apocalypse very near to be playable. But mouselook cannot rotate 360° :-(

Tested on fedora 13 - Xorg 1.8.2
Comment 396 Ruslan Kabatsayev 2010-09-04 06:22:05 CDT
(In reply to comment #395)
> With wine 1.3.2 and using small change from bug 13087 comment 2 is game Hard
> truck apocalypse very near to be playable. But mouselook cannot rotate 360° :-(
> 
> Tested on fedora 13 - Xorg 1.8.2

Have you tried "Xi2 patch with xorg bug workaround"? Comment #394 states it helps with 360° rotation.
Comment 397 Dušan Hokův 2010-09-04 07:29:14 CDT
(In reply to comment #396)
> (In reply to comment #395)
> > With wine 1.3.2 and using small change from bug 13087 comment 2 is game Hard
> > truck apocalypse very near to be playable. But mouselook cannot rotate 360° :-(
> > 
> > Tested on fedora 13 - Xorg 1.8.2
> 
> Have you tried "Xi2 patch with xorg bug workaround"? Comment #394 states it
> helps with 360° rotation.

Patch not helped to me. Rotation work about 200°, on the radar in game looks like I can rotate from North only small to left, then look stops and to right I can rotate to 190-200°, then rotation stops. Same behavior was without this patch. HTA RoC have same problem.
Comment 398 quaker 2010-09-04 09:06:55 CDT
(In reply to comment #397)
> (In reply to comment #396)
> > (In reply to comment #395)
> > > With wine 1.3.2 and using small change from bug 13087 comment 2 is game Hard
> > > truck apocalypse very near to be playable. But mouselook cannot rotate 360° :-(
> > > 
> > > Tested on fedora 13 - Xorg 1.8.2
> > 
> > Have you tried "Xi2 patch with xorg bug workaround"? Comment #394 states it
> > helps with 360° rotation.
> 
> Patch not helped to me. Rotation work about 200°, on the radar in game looks
> like I can rotate from North only small to left, then look stops and to right I
> can rotate to 190-200°, then rotation stops. Same behavior was without this
> patch. HTA RoC have same problem.

to make xi2 patch work properly, there are a few conditions:

1) you must have recent enough xorg (1.8 or bigger, in debian it works currently in testing, unstable, experimental, in ubuntu it works since lucid, on others: i don't know)
2) you must have xinput dev package installed (on debian/ubuntu: libxi-dev)
3) then you can apply patch to wine source, run configure, then check generated include/config.h and search for xinput2, it should define HAVE_XINPUT2_LIB to 1.
4) if it's 1, then wine will be built with xi2 support, you can do make, make install, you're done

.. and you shouldn't apply any patches for mouse warp when using xi2 and also, registry changes in directinput are useless and may cause problems.
Comment 399 Berillions 2010-09-04 13:10:21 CDT
(In reply to comment #398)
> 1) you must have recent enough xorg (1.8 or bigger, in debian it works
> currently in testing, unstable, experimental, in ubuntu it works since lucid,
> on others: i don't know)

Are you sure that this patch works correctly on Debian Unstable?
Because i use it and the Xorg version is the 1.7.7 and it's not Xorg 1.8 or bigger :s

Thanks
Comment 400 quaker 2010-09-04 13:19:38 CDT
(In reply to comment #399)
> (In reply to comment #398)
> > 1) you must have recent enough xorg (1.8 or bigger, in debian it works
> > currently in testing, unstable, experimental, in ubuntu it works since lucid,
> > on others: i don't know)
> 
> Are you sure that this patch works correctly on Debian Unstable?
> Because i use it and the Xorg version is the 1.7.7 and it's not Xorg 1.8 or
> bigger :s
> 
> Thanks

it does also on 1.7.x, that contains xinput2 too, but it's well tested on 1.8 and unreleased 1.9 (i use 1.9 RC5)

xinput2 = Xorg 7.5 feature, and Xorg 7.5 first shipped with X Server 1.7.x
Comment 401 Dušan Hokův 2010-09-04 13:34:51 CDT
(In reply to comment #398)
> (In reply to comment #397)
> > (In reply to comment #396)
> > > (In reply to comment #395)
> > > > With wine 1.3.2 and using small change from bug 13087 comment 2 is game Hard
> > > > truck apocalypse very near to be playable. But mouselook cannot rotate 360° :-(
> > > > 
> > > > Tested on fedora 13 - Xorg 1.8.2
> > > 
> > > Have you tried "Xi2 patch with xorg bug workaround"? Comment #394 states it
> > > helps with 360° rotation.
> > 
> > Patch not helped to me. Rotation work about 200°, on the radar in game looks
> > like I can rotate from North only small to left, then look stops and to right I
> > can rotate to 190-200°, then rotation stops. Same behavior was without this
> > patch. HTA RoC have same problem.
> 
> to make xi2 patch work properly, there are a few conditions:
> 
> 1) you must have recent enough xorg (1.8 or bigger, in debian it works
> currently in testing, unstable, experimental, in ubuntu it works since lucid,
> on others: i don't know)
> 2) you must have xinput dev package installed (on debian/ubuntu: libxi-dev)
> 3) then you can apply patch to wine source, run configure, then check generated
> include/config.h and search for xinput2, it should define HAVE_XINPUT2_LIB to
> 1.
> 4) if it's 1, then wine will be built with xi2 support, you can do make, make
> install, you're done
> 
> .. and you shouldn't apply any patches for mouse warp when using xi2 and also,
> registry changes in directinput are useless and may cause problems.

Still same problem, but I made some tests with adjusting mouse sensitivity in Hard Truck Apocalypse game. When I set highest sensitivity, cannon can rotate > 360° - looks like 2x turn around, but still stops, its impossible rotate freely without stop. When I decrease to minimum mouse sensitivity, cannon can rotate for example only 90°.
Comment 402 Dušan Hokův 2010-09-04 14:07:36 CDT
Some other test I made in the HTA game. When rotation of cannon stops, I tried with Esc go to game menu and see mouse cursor in left side (cannon cannot rotate left - anticlockwise). Same when cannon stop rotation to right(clockwise), mouse appear on the right side in game menu.
Comment 403 Ruslan Kabatsayev 2010-09-04 14:50:13 CDT
"Xi2 patch with xorg bug workaround" doesn't help with GTA III. Mouse still escapes the window, and then camera isn't controlled. The same problem is with fullscreen mode where mouse stops on the screen border and camera stops rotating.
Comment 404 Ruslan Kabatsayev 2010-09-04 15:55:49 CDT
(In reply to comment #403)
> "Xi2 patch with xorg bug workaround" doesn't help with GTA III. Mouse still
> escapes the window, and then camera isn't controlled. The same problem is with
> fullscreen mode where mouse stops on the screen border and camera stops
> rotating.

Oops. Posted too early. It appeared i had built wine without Xi2 support. Now, as wine has been built with Xi2 support, the patch works like a charm. I can move the cursor out of the window, and it still controls the camera. So, IT WORKS! ;)
Thanks for the patch, Vitaliy. Is it a proper patch which could be merged into wine?
Comment 405 Dan Kegel 2010-09-04 16:22:20 CDT
The rumor I hear is that it would take a few weeks of a senior developer's time to whip it into shape.
Comment 406 quaker 2010-09-04 18:08:34 CDT
(In reply to comment #404)
> (In reply to comment #403)
> > "Xi2 patch with xorg bug workaround" doesn't help with GTA III. Mouse still
> > escapes the window, and then camera isn't controlled. The same problem is with
> > fullscreen mode where mouse stops on the screen border and camera stops
> > rotating.
> 
> Oops. Posted too early. It appeared i had built wine without Xi2 support. Now,
> as wine has been built with Xi2 support, the patch works like a charm. I can
> move the cursor out of the window, and it still controls the camera. So, IT
> WORKS! ;)
> Thanks for the patch, Vitaliy. Is it a proper patch which could be merged into
> wine?

as you can guess from name, it workarounds some xorg bug. So when xorg is without that bug AND most of people will have the right version, then it'll get merged in, AFAIK.

This bug won't be solved in any other way than xinput2 support, because it's useless. Xinput2 is proper solution for this bug and should work for every application. So let's wait till Xinput2 is widespread and then we'll get this fixed without patching wine.

Personally, i don't care much about patching - i use wine from git, and it automatically generates packages for my distro, and properly patches.
Comment 407 Brian Vuyk 2010-09-04 21:23:59 CDT
I tested Vitaly's patch (#351), and it 'mostly' fixed the outstanding mouse issues with Moutnt & Blade: Warband. However, as I have to run the game in a wine desktop for the resolution not to be messed up, every time the X mouse would pass out of the desktop, a click would click out of the game.

I attempted using madscientist's patch (#377) to try to fix it. Unfortunately, after compiling with that patch (in addition to Vitaliy's, the mouse clicks would register in the game menu. Plus, the mouse cursor would still move outside the wine desktop.
Comment 408 Berillions 2010-09-05 03:47:46 CDT
I have a problem with Vitaliy patch.
- I use Debian Unstable (Xorg 1.7.7) and the package libxi-dev is installed.
- I apply the patch in the source Wine correctly and i launch /configure.

But, when i check on /include/config.h, i haven't a line with HAVE_XINPUT2_LIB 1.
So i think that this patch doesn't work with Xorg 1.7.7 (cf quaker message)
Comment 409 quaker 2010-09-05 04:55:37 CDT
(In reply to comment #408)
> I have a problem with Vitaliy patch.
> - I use Debian Unstable (Xorg 1.7.7) and the package libxi-dev is installed.
> - I apply the patch in the source Wine correctly and i launch /configure.
> 
> But, when i check on /include/config.h, i haven't a line with HAVE_XINPUT2_LIB
> 1.
> So i think that this patch doesn't work with Xorg 1.7.7 (cf quaker message)

the patch is most likely applied incorrectly, because without xi2, it should define to 0 ..

+ i named the var incorrectly, it's HAVE_LIBXINPUT2.
Comment 410 Berillions 2010-09-05 08:27:41 CDT
I tried this patch and it doesn't work with Mass Effect 1&2. I can't move the character during the game and left clik in the menu and game doesn't work completly too.
Comment 411 brian willian 2010-09-07 14:21:34 CDT
(In reply to comment #410)
> I tried this patch and it doesn't work with Mass Effect 1&2. I can't move the
> character during the game and left clik in the menu and game doesn't work
> completly too.

me too and didn't work with Silent Hill Homecoming and Medal of Honor - Airbourne
when i try to move like 360 omg! completly mess.
Comment 412 Ruslan Kabatsayev 2010-09-18 13:31:30 CDT
Just tested "Xi2 patch with xorg bug workaround" on GTASA. While this patch works with all other GTA versions (III, VC & IV), it makes camera uncontrollable in GTASA. Any mouse move leads to "jumps" of camera angle. But when i press Super+Tab (shift window switcher in Compiz), so that the window doesn't get mouse pointer events, camera rotation works correctly.
Also, now i cannot use a game after another one has started while first was running. Looks like second games takes mouse from first one.
And, when using Compiz, if mouse pointer goes to the screen border (i just have to rotate camera so long so that the pointer reaches the border), the game doesn't get keyboard events (because the pointer is not in its window in this case).
Comment 413 Kai Arne 2010-09-29 06:53:20 CDT
Discovered the weird mouse action with Dragon Age under wine.
I tried the patch from Vitaliy (comment 351) with Wine 1.3.3 on stock Ubuntu 10.04 (X-Version 1.7.6) and it completely solved the problem for me. The patch in comment 377 did not seem to have any effect.
Comment 414 Evan Goers 2010-10-08 03:03:11 CDT
(In reply to comment #351)
> Created an attachment (id=29313) [details]
> Xi2 patch with xorg bug workaround
> 
> Here is another patch that works around xorg bug. Try with with. Make sure you
> do have Xorg 1.8 (aka 7.5).

This patch appears to not apply cleanly to the latest git anymore as of today(some previous revisions probably don't work either). The bug has not been fixed as a result and I am hoping that this patch could be updated to the latest git.
Comment 415 quaker 2010-10-08 07:36:39 CDT
Created attachment 31187 [details]
xinput2 patch fixed for latest wine git (after-1.3.4)

i've fixed the xinput patch for latest wine git so it applies cleanly (basically copied my wine tree, applied what was possible to apply, manually resolved conflicting diff and diff'd again)

it now works in post-1.3.4 wine
Comment 416 elloet 2010-10-12 10:13:38 CDT
The patch's author does not seem to take in account that there may be two separate applications run in virtual desktop simultaneously. The patch is much likely to handle the first started window alone, whereas the second window keep on conducting as if there was not a patch applied. Can anybody reproduce?
Comment 417 Vitaliy Margolen 2010-10-16 11:28:51 CDT
> The patch's author does not seem to take in account that there may be two
> separate applications run in virtual desktop simultaneously.
Correct, this patch doesn't handle all cases. That's why it's here not in Wine. You are welcome to fix it.
Comment 418 quaker 2010-10-16 11:48:25 CDT
(In reply to comment #416)
> The patch's author does not seem to take in account that there may be two
> separate applications run in virtual desktop simultaneously. The patch is much
> likely to handle the first started window alone, whereas the second window keep
> on conducting as if there was not a patch applied. Can anybody reproduce?

i run steam first and then some game; the game gets input correctly. But it's true i don't run it in virtual desktop.
Comment 419 paulo 2010-10-16 21:14:01 CDT
So what's the progress on this. Is is going into trunk soon now that Ubuntu 10.10 is out?
Comment 420 quaker 2010-10-20 12:56:03 CDT
Created attachment 31403 [details]
updated xinput2 patch for wine git (after-1.3.5)

Updated the patch so it applies and works again. Applies cleanly on rev f8e4a0f3b9d220b3242489d35399230245fa3287 (http://source.winehq.org/git/wine.git/?a=commit;h=f8e4a0f3b9d220b3242489d35399230245fa3287)
Comment 421 Johan Palmqvist 2010-10-20 16:09:05 CDT
Created attachment 31405 [details]
xinput2 patch fixed for wine git from 20101020 (after-1.3.5)
Comment 422 Johan Palmqvist 2010-10-20 16:14:28 CDT
Comment on attachment 31405 [details]
xinput2 patch fixed for wine git from 20101020 (after-1.3.5)

Oops, looks like i did some duplicated work. :P
Comment 423 Valeriy Malov 2010-10-21 16:04:43 CDT
Tried xi2 patch with latest git on AvP2. Clicks and menu seem to work well, but any small ingame mouse movement is considered as a movement in bottom-right direction when mouse is in the screen (mouse movements outside the game screen works just fine, probably it works fine too inside it, but makes no noticeable difference because the glitch effect is way stronger)

Feels like this broken behavior is unrelated to the discussed bug, because without Xi2 support game had some mouse issues with moving in top-left direction, but probably they were overlapped by cursor warping.
Comment 424 bes.internal 2010-10-24 08:19:58 CDT
Tried latest xi2 patch with latest git on Mount & Blade Warband. Works great!
xorg-server (1.9.0), xinput (1.5.2), wine (nearly after 1.3.5 )
Works great! Yeah!
Comment 425 Gustavo Conte 2010-10-26 15:39:22 CDT
Instead of applying patches, I tried to solve the problem at X11

I configured COMPIZ to switch desktops when the mouse reaches de edge of the screen, with 0 delay. Then set the game window to display in all desktops.

Its a bit more playable now, I'm just concerned if this could cause brain damage or something.. lol don't do it with the CUBE
Comment 426 Evan Goers 2010-11-03 00:29:19 CDT
Latest patch doesn't apply anymore with the latest git as of today.
Comment 427 ultrageek.lloyd 2010-11-03 00:48:59 CDT
Created attachment 31693 [details]
Add Xinput2 support

updated patch to apply against current git
Comment 428 quaker 2010-11-11 16:26:11 CST
Created attachment 31863 [details]
xi2 patch fixed 11/11/2010 c138970ea2ce0661ebb80a5e0079e284a19d3176

Updated xinput2 patch for today's git. Applies cleanly again.
Tested on commit c138970ea2ce0661ebb80a5e0079e284a19d3176 (winmm/tests: Fix test failure in multi-byte locale. Jörg Höhle <hoehle@users.sourceforge.net>
Wed, 10 Nov 2010 17:45:27 +0000 (18:45 +0100))
Comment 429 Brian Vuyk 2010-12-10 11:15:18 CST
I applied the patch in #428 to a git checkout, and it applied cleanly (albeit with some fuzz on a few hunks).

It seems to work fine in my usage when using a single monitor. However, I am running a dual monitor setup with Wine running in a 1920x1080 virtual desktop in my left monitor. I have 'Allow DirectX apps to stop the mouse leaving their window' checked in winecfg.

In the game Mount & Blade: Warband, as I turn my character, the mouse tends to exit the virtual desktop area into the right monitor. While in the right monitor, relative mouse motions are still read correctly in-game. However, if I happen to click on anything while the mouse is outside of the game window, the game loses focus.
Comment 430 H3g3m0n █▓▒☢☣☠⚛▒▓█ 2010-12-29 01:34:00 CST
I understand that the patch isn't in main Wine because it's still a bit of a hack and can cause problems with some applications, with multiple programs and so on. 

But would it be possible to get it in there as some kind of an optional per-exe regedit override? Similar to the MouseWarpOverride one.

After all this effects a fairly large number of apps and users. Quite a few games would be platinum with it. It's also been a bug since 2006 so I don't really see a solution anytime soon (although we didn't have Xinput2 before).

An optional slightly hacky fix that solves %95 of the problems is better than no solution that solves nothing.

Or are we likely to see a fix soonish now XInput2 is around?
Comment 431 quaker 2010-12-29 05:03:11 CST
yes, i agree, it solved for now ALL problems with mouse in games; no overriding and stuff anymore. It could be added at least as compilation option. Even now, when you apply the patch, it compiles only if you have xi2 available, otherwise you get normal wine. So new option --with-xinput2-experimental passed to configure could be done and the patch applied like that.
Comment 432 Dan Kegel 2010-12-29 06:31:45 CST
Alexandre is probably just waiting for the right time to spend the needed
couple weeks to properly implement the demonstrated fix.

Nominating for 1.4 to reflect the fact that it's probably going to happen before the next release.
Comment 433 Dan Kegel 2010-12-29 06:40:26 CST
(Well, "probably going to happen before next release" might be a bit strong,
but it seems likely to me.)
Comment 434 Itzamna 2011-01-07 23:40:32 CST
Created attachment 32768 [details]
Xinput2 patch, fixed for commit 179b862738aae3b84b87c8e421cef868fe60e87e (01/08/2011)

IDirectInputDevice2AImpl was renamed to IDirectInputDeviceImpl.
Comment 435 Valeriy Malov 2011-01-22 10:13:53 CST
Again on AvP2: seems like the game is warping mouse manually (ignoring any wine options). On every motion/mouse entering notify it sends cursor to the middle of window and somehow breaks ingame aim (even with MotionNotify code commented out, i.e. recieving no events after the manual warp?).

Xi2 patch with SetCursorPos code commented out fixes this problem, but breaks mouse capture in virtual desktop mode.

So I wonder if I should open a separate bug for this, or this manual warping is broken by design?

P.S. I've tested this with Blood 2 demo too and probably same problem affects other Lithtech games (like NOLF)
Comment 436 Jin 2011-01-29 12:18:40 CST
*** Bug 25855 has been marked as a duplicate of this bug. ***
Comment 437 Michael Abbott 2011-02-27 14:40:05 CST
(In reply to comment #434)
> Created an attachment (id=32768) [details]
> Xinput2 patch, fixed for commit 179b862738aae3b84b87c8e421cef868fe60e87e

I do see one issue with this patch: as the mouse moves outside the game window rather odd things can happen to mouse clicks.  I haven't tested very thoroughly yet, but it looks as if both the game with focus *and* the window under the cursor receive clicks.  

This may be a bit window manager dependent.  I'll try and do some more careful testing, but there may be a problem here...
Comment 438 André H. 2011-03-01 14:52:32 CST
*** Bug 26274 has been marked as a duplicate of this bug. ***
Comment 439 Dan Kegel 2011-03-08 15:41:24 CST
Created attachment 33574 [details]
Rediffed to apply to today's git
Comment 440 Michael Abbott 2011-03-09 06:13:43 CST
Is it possible for this patch to be modified so that the mouse is warped back into the application window, at least when the application thinks it's running full screen?

If you run a program with this patch which relies on the current behaviour in a virtual desktop which doesn't cover the entire Linux desktop then while the cursor is outside the application window mouse key presses are being sent to outside windows or the desktop.  This can end up triggering all sorts of accidents if you're not paying attention!
Comment 441 Valeriy Malov 2011-03-09 06:45:26 CST
(In reply to comment #440)
> Is it possible for this patch to be modified so that the mouse is warped back
> into the application window, at least when the application thinks it's running
> full screen?

I guess that mouse warping is not failproof and moreover it's breaking apps that do not need it at all. Vitaliy commented before that "any real solution should not warp mouse".
Comment 442 Michael Abbott 2011-03-09 08:54:42 CST
(In reply to comment #441)
> (In reply to comment #440)
> > Is it possible for this patch to be modified so that the mouse is warped back
> > into the application window, at least when the application thinks it's running
> > full screen?
> I guess that mouse warping is not failproof and moreover it's breaking apps
> that do not need it at all. Vitaliy commented before that "any real solution
> should not warp mouse".

I've no good idea how to solve this problem.  The mouse goes wandering all over the screen, and it's very easy to end up giving the focus away.

The problem only arises, I guess, when the application thinks it's full screen but is being run in a virtual desktop.  Is there some way for the application to gain exclusive capture of mouse events so that mouse clicks don't get sent to other applications?  Of course, this would mean that it's *impossible* to click away from the application, you'd have to use a desktop manager key binding (eg Alt-Tab).
Comment 443 Jouni Järvinen 2011-03-09 09:35:15 CST
(In reply to comment #442)
> (In reply to comment #441)
> > (In reply to comment #440)
> > > Is it possible for this patch to be modified so that the mouse is warped back
> > > into the application window, at least when the application thinks it's running
> > > full screen?
> > I guess that mouse warping is not failproof and moreover it's breaking apps
> > that do not need it at all. Vitaliy commented before that "any real solution
> > should not warp mouse".
> 
> The problem only arises, I guess, when the application thinks it's full screen
> but is being run in a virtual desktop.  Is there some way for the application
> to gain exclusive capture of mouse events so that mouse clicks don't get sent
> to other applications?  Of course, this would mean that it's *impossible* to
> click away from the application, you'd have to use a desktop manager key
> binding (eg Alt-Tab).
Ain't that the purpose ?
Comment 444 Roderick Colenbrander 2011-03-13 20:11:28 CDT
*** Bug 26408 has been marked as a duplicate of this bug. ***
Comment 445 Brian Vuyk 2011-03-14 11:29:42 CDT
(In reply to comment #442)
> The problem only arises, I guess, when the application thinks it's full screen
> but is being run in a virtual desktop.

This is also the case when you are using two monitors with Nvidia's TwinView mode turned on. This gives you a desktop resolution of (in my case) 3200x1080. With a fullscreen game on one monitor running at 1920x1080, the mouse will stray into my other desktop screen and clicks will change focus onto other items running on that desktop.

The solution in this case is to only run on a single monitor for now, but I agree, if a fullscreen app has focus, the mouse should not be able to leave that window.
Comment 446 Michael Abbott 2011-03-14 11:51:23 CDT
(In reply to comment #445)
> The solution in this case is to only run on a single monitor for now, but I
> agree, if a fullscreen app has focus, the mouse should not be able to leave
> that window.

Is it possible with xinput2 to configure the mouse for exclusive capture *when* the application has keyboard focus?  Or is this going to require delicate negotiation with the window manager as well?  (Am painfully ignorant in this area.)

I think it will be better to implement exclusive mouse event capture rather than trying (and probably failing) to continually warp the mouse into the application window.  It would be nice (would presumably require Xserver support) if the mouse stayed inside the window as well, but with exclusive capture of mouse events that would be just a "nice to have", not necessary.

Can someone who understands the underlying API and interactions say what's current possible here?  The current patch seems *nearly* there!
Comment 447 William J May 2011-03-14 18:52:59 CDT
(In reply to comment #181)

Was it established that DOSBox mouse handling was DGA or otherwise unsuitable???

I noticed DOSBox integration was started on Wine 1.3.12
Comment 448 Brian Vuyk 2011-03-15 12:08:53 CDT
Comment on attachment 15638 [details]
Proposed mouse improvement for 'stuck menu problem

Marking this patch as obsolete as Xinput2 is definately the way to go.
Comment 449 Berillions 2011-03-18 20:15:50 CDT
(In reply to comment #439)
> Created an attachment (id=33574) [details]
> Rediffed to apply to today's git

For me, this patch resolv this bug (http://bugs.winehq.org/show_bug.cgi?id=7640) for Assassin's Creed, Assassin's Creed II and Assassin's Creed : Brotherhood
Comment 450 Berillions 2011-03-18 20:16:53 CDT
(In reply to comment #439)
> Created an attachment (id=33574) [details]
> Rediffed to apply to today's git

For me, this patch resolv this bug (http://bugs.winehq.org/show_bug.cgi?id=7640) for Assassin's Creed, Assassin's Creed II and Assassin's Creed : Brotherhood.

With it, the game is very playable and the mouse isn't slow.
Comment 451 zil 2011-03-26 06:01:19 CDT
In crysis 2 i cant turn 360 degrees with mouse.
winetricks mwo=force help but mouse in all menu stops work and need to use keybord.
Comment 452 Ivan 2011-04-11 13:58:24 CDT
*** Bug 22282 has been marked as a duplicate of this bug. ***
Comment 453 Ivan 2011-04-11 14:02:26 CDT
(In reply to comment #439)
> Created an attachment (id=33574) [details]
> Rediffed to apply to today's git

Your patch solved problems with mass effect 2, dragon age origins and dragon age 2. 
Thanks
Comment 454 Berillions 2011-04-12 13:21:00 CDT
I must to check if it's exact but on Debian Sid with the latest Xorg (version 1.9.5), this patch is useless for Mass Effect 2. 

Without this patch, i haven't problem with my mouse. But without/with this patch the mouse doesn't work in Mass Effect 1 and i have no solution...
Comment 455 Evan Goers 2011-04-15 02:23:59 CDT
Looks like it needs to be rediffed again.
Comment 456 GreatEmerald 2011-04-15 17:34:09 CDT
(In reply to comment #455)
> Looks like it needs to be rediffed again.

If I'm seeing this correctly, no - it's gone mainline! Which should mean that since 1.3.18 it's enabled by default. Well, I'm excited, and it's the perfect time to test this feature, too.
Comment 457 Austin English 2011-04-15 19:32:58 CDT
(In reply to comment #456)
> (In reply to comment #455)
> > Looks like it needs to be rediffed again.
> 
> If I'm seeing this correctly, no - it's gone mainline! Which should mean that
> since 1.3.18 it's enabled by default. Well, I'm excited, and it's the perfect
> time to test this feature, too.

It's not complete yet, but some applications may work better. I'd suggest waiting a while though before saying it's done ;-).
Comment 458 Xavier Vachon 2011-04-15 21:34:58 CDT
(In reply to comment #457)
> (In reply to comment #456)
> > (In reply to comment #455)
> > > Looks like it needs to be rediffed again.
> > 
> > If I'm seeing this correctly, no - it's gone mainline! Which should mean that
> > since 1.3.18 it's enabled by default. Well, I'm excited, and it's the perfect
> > time to test this feature, too.
> 
> It's not complete yet, but some applications may work better. I'd suggest
> waiting a while though before saying it's done ;-).

Emm, which commits are we talking about??
Comment 459 Zhenya 2011-04-15 21:42:00 CDT
Wine 1.3.18 changes doesn't work with Unreal Tournament 3. Now I using old patch for X Input 1.7 and older. http://bugs.winehq.org/attachment.cgi?id=15638 How to apply X Input 1.8 patch?
Comment 460 Xavier Vachon 2011-04-15 22:32:41 CDT
(In reply to comment #458)
> (In reply to comment #457)
> > (In reply to comment #456)
> > > (In reply to comment #455)
> > > > Looks like it needs to be rediffed again.
> > > 
> > > If I'm seeing this correctly, no - it's gone mainline! Which should mean that
> > > since 1.3.18 it's enabled by default. Well, I'm excited, and it's the perfect
> > > time to test this feature, too.
> > 
> > It's not complete yet, but some applications may work better. I'd suggest
> > waiting a while though before saying it's done ;-).
> 
> Emm, which commits are we talking about??

Nevermind, just read the news. Good stuff. Will wait for an announcement to test the new features.
Comment 461 rocko 2011-04-16 05:46:54 CDT
(In reply to comment #460)
> (In reply to comment #458)
> > (In reply to comment #457)
> > > (In reply to comment #456)
> > > > (In reply to comment #455)
> > > > > Looks like it needs to be rediffed again.
> > > > 
> > > > If I'm seeing this correctly, no - it's gone mainline! Which should mean that
> > > > since 1.3.18 it's enabled by default. Well, I'm excited, and it's the perfect
> > > > time to test this feature, too.
> > > 
> > > It's not complete yet, but some applications may work better. I'd suggest
> > > waiting a while though before saying it's done ;-).
> > 
> > Emm, which commits are we talking about??
> 
> Nevermind, just read the news. Good stuff. Will wait for an announcement to
> test the new features.

I just tried 1.3.18 (ie with the xinput2 raw mouse input enabled) and it didn't work for Crysis. xinput2 was initialising correctly but unless I press the mouse button, I still can't turn around 360 degrees.
Comment 462 Berillions 2011-04-16 15:43:26 CDT
Wine 1.3.18 doesn't works with Mass Effect too.
I must to use 1.2.3 with an old patch.
Comment 463 rocko 2011-04-17 00:32:59 CDT
And unfortunately the latest xinput2 patch from 2011-03-08 won't apply to 1.3.18. I tried cherry-picking the bits of the patch that look like they haven't yet been implemented in 1.3.18 (mostly in dinput_main.c) but without success (the mouse didn't work at all outside the menus).
Comment 464 Manuel Soukup 2011-04-17 07:58:12 CDT
I tried wine 1.3.18 with S.T.A.L.K.E.R. Clear Sky 1.5.10 and turning does not work ether.

Turning in 360° is not possible. If i set mouseOverride to force it works but, mouse is centered in the middle on the screen and you cant use in menu.
Comment 465 Dave M 2011-04-17 13:26:57 CDT
Unfortunately no improvement with DC Universe Online (Unreal Engine).
Comment 466 Jonathan 2011-04-17 22:43:53 CDT
I just tested Sanctum which uses Unreal engine. On 1.3.17 had to use MouseWarpOverride=force...  I can confirm that on 1.3.18 everything works as it should! Full rotation + cursor control.
Comment 467 David Rogers 2011-04-18 00:58:52 CDT
Uru: Ages Beyond Myst now works fine.
Comment 468 Jonathan 2011-04-18 07:00:00 CDT
UT3: Black (Steam) still requires MouseWarpOverride=force setting to achieve full 360+ rotations...
Comment 469 Luis Alvarado 2011-04-18 07:56:19 CDT
1.3.18 did NOT solve the problem with the mouse stuck in some kind of small square area. Games like GTA3, Vice City, Hitman and many others similar in the way they use the mouse ingame stil have the problem.
Comment 470 Jonathan 2011-04-18 08:45:38 CDT
I agree=not fixed. Though I'm getting very strange results = Sanctum was DEFINITELY working 100% with both mouse not leaving the game window (full-screen no vdesktop) AND I had full rotations... (I have witness here that assures me as well it WAS working as we both played a bit this afternoon) - but tonight I just tried playing again, and the full rotation has once again stopped. I haven't made any changes to the prefix or registry or anything else... it just stopped working. Have been trying every thing I can think to to get it working again.. no luck.  The only other wine app used today was the UT3 test in it's own separate wineprefix which didn't work either :(
Comment 471 Luis Alvarado 2011-04-18 10:18:08 CDT
I have tested the following for the mouse problem:

GTA3 - Had the problem before. Still has it on .18
Oblivion - Did not have the problem before. Does not have it on the 1.8
Hitman 1 - Did not have the problem before. Does not have it on the 1.8
Hitman 2 - Did not have the problem before. Does not have it on the 1.8
Hitman 3 - Had the problem before. Does not have it now. Fixed in .18
Hitman Blood Money - Had the problem before. Does not have it now. Fixed in .18
WOW - Did not have it before. Does not have it now with .18
Vice City - Had the problem before. Still has it on .18
SWAT4 - Had the problem before. Still has it on .18
ManHunt - Had the problem before. Still has it on .18 (Totally kills the game)
Thief 3 - Had the problem before. Still has it on .18
Splinter Cell (Pandora) - Had the problem before. Still has it on .18


Basically of the 12 games i could test right now, 8 games had the problem. 2 of them were solved with the 1.3.18 update. The rest still have it.
Comment 472 Berillions 2011-04-18 14:27:43 CDT
Assassin's Creed I, II and Brotherhood :

1.3.17 : Had a problem before, the mouse was slow when i turned Altaïr/Ezio.
1.3.17 + patch : No problem, the bug was corrected.
1.3.18 : Had the same problem which Wine 1.3.17 without patch.
Comment 473 Emery Finkelstein 2011-04-23 17:00:27 CDT
It looks like some of the xinput2 implementation provided by the patch went into Wine 1.3.18. However the Wine 1.3.18 doesn't fix the issue the patch solved in some games as noted by others.

The patch no longer applies cleanly, and I don't know the codebase well enough to create a new one.
Comment 474 David 2011-04-24 08:04:16 CDT
Im trying to get Mass Effect 2 working with 360 degress mouse rotation, but I still didnt succeed :(

I used wine 1.3.18 => didn't help at all

I applied the newest xinput2 patch (http://bugs.winehq.org/attachment.cgi?id=33574) to wine 1.3.17 (since the patch isn't compatible with wine 1.3.18) and It didn't matter at all either.

The thing is, I'm running the newest Ubuntu (11.04 beta 2) which uses a very new Xorg, and I wonder if the xinput2 patch is also compatible with this version?

(everything else works perfectly, it's just the **** mouse rotation that makes it SO hard to play the game)

I also tried to play Assassins Creed => same result as ME2 :(

Some extra info:
david@overlord:~$ Xorg -version

X.Org X Server 1.10.1
Release Date: 2011-04-15
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-29-server x86_64 Ubuntu
Current Operating System: Linux overlord 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.38-8-generic root=/dev/mapper/vg01-root ro quiet splash vt.handoff=7
Build Date: 19 April 2011  03:40:45PM
xorg-server 2:1.10.1-1ubuntu1 (For technical support please see http://www.ubuntu.com/support) 
Current version of pixman: 0.20.2
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.

david@overlord:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 11.04
Release:	11.04
Codename:	natty
Comment 475 Casey Jones 2011-05-02 18:57:57 CDT
(In reply to comment #474)
> Im trying to get Mass Effect 2 working with 360 degress mouse rotation, but I
> still didnt succeed :(
> 
> I used wine 1.3.18 => didn't help at all

I just tested ME2 on wine 1.3.18 and the mouse rotation works now.  I do remember testing 1.3.16 or .17 and the mouse would leave the window, but it works now.  I have the same Xorg and kernel, but I use Gentoo.  If it makes any difference, I played in windowed mode in a Wine virtual desktop.  Without the virtual desktop, the window sizes itself to only show the upper left corner of the game, but that's another bug.
Comment 476 Ivan 2011-05-03 01:23:45 CDT
(In reply to comment #475)
> I just tested ME2 on wine 1.3.18 and the mouse rotation works now.  I do
> remember testing 1.3.16 or .17 and the mouse would leave the window, but it
> works now.  I have the same Xorg and kernel, but I use Gentoo.  If it makes any
> difference, I played in windowed mode in a Wine virtual desktop.  Without the
> virtual desktop, the window sizes itself to only show the upper left corner of
> the game, but that's another bug.

I tried wine 1.3.19 - it does not work in mass effect 2 or unreal 3(but it works in dragon age 1 and 2). Wine 1.3.17 with xinput patch works fine.
Comment 477 David 2011-05-04 13:48:05 CDT
(In reply to comment #475)
> (In reply to comment #474)
> > Im trying to get Mass Effect 2 working with 360 degress mouse rotation, but I
> > still didnt succeed :(
> > 
> > I used wine 1.3.18 => didn't help at all
> 
> I just tested ME2 on wine 1.3.18 and the mouse rotation works now.  I do
> remember testing 1.3.16 or .17 and the mouse would leave the window, but it
> works now.  I have the same Xorg and kernel, but I use Gentoo.  If it makes any
> difference, I played in windowed mode in a Wine virtual desktop.  Without the
> virtual desktop, the window sizes itself to only show the upper left corner of
> the game, but that's another bug.

Thanks a lot for replying!

Well since you had a positive result I tried it again and I also tested ME2 in a virtual desktop, result:

wine 1.3.17 + dinput2 patch => NO 360 degrees rotation
wine 1.3.17 + dinput2 patch + virtual desktop => NO 360 degrees rotation
wine 1.3.18 => NO 360 degrees rotation
wine 1.3.18 + virtual desktop => NO 360 degrees rotation
wine 1.3.19 => NO 360 degrees rotation
wine 1.3.19 + virtual desktop => NO 360 degrees rotation

In conclusion I don't know how your setup differs from my setup, but apparently there is something that is making my setup fail :(

It might be that the applied Ubuntu patches broke something that the Gentoo kernel left intact. Or perhaps you compiled your kernel with different parameters than the default Ubuntu kernel build, which just make the difference. but I'm out of ideas :(

If you find anything special about your kernel or Xorg build, please let me know!

some more info about the patched wine 1.3.17:
I downloaded wine 1.3.17 from sourgeforge and patched wine 1.3.17 using the following commands:
  patch -p1 < lib/wine-src/extracted/wine-1.3.17
  ./configure
  make -j 4

And then I set the the correct wineprefix (using 'export WINEPREFIX=/dir_to_wine_prefix' )
and I ran ME2 using this new wine (when I'm in the correct dir) using its absolute path, as in:
  ~/lib/wine-src/extracted/wine-1.3.17/wine "MassEffect2.exe"

If anyone has a working Ubuntu 11.04 + wine + ME2 setup please let me know!
Comment 478 David 2011-05-04 13:51:16 CDT
oops, a little mistake in my post:
'patch -p1 < lib/wine-src/extracted/wine-1.3.17'

should be:
'patch -p1 < lib/wine-src/extracted/wine-1.3.17/bug6971-mar8.patch'
Comment 479 Ivan 2011-05-04 14:03:47 CDT
(In reply to comment #478)
> oops, a little mistake in my post:
> 'patch -p1 < lib/wine-src/extracted/wine-1.3.17'
> 
> should be:
> 'patch -p1 < lib/wine-src/extracted/wine-1.3.17/bug6971-mar8.patch'

Did it actually apply? It didn't for me, had to change all lines manually. Also, what is your xserver version?
Comment 480 David 2011-05-04 14:11:15 CDT
(In reply to comment #479)
> (In reply to comment #478)
> > oops, a little mistake in my post:
> > 'patch -p1 < lib/wine-src/extracted/wine-1.3.17'
> > 
> > should be:
> > 'patch -p1 < lib/wine-src/extracted/wine-1.3.17/bug6971-mar8.patch'
> 
> Did it actually apply? It didn't for me, had to change all lines manually.
> Also, what is your xserver version?

Thanks for replying and Yup it did:

david@overlord:~/lib/wine-src/extracted/wine-1.3.17$ patch -p1 < bug6971-mar8.patch 
patching file configure
Hunk #1 succeeded at 8035 (offset 5 lines).
Hunk #2 succeeded at 8232 (offset 5 lines).
patching file configure.ac
Hunk #1 succeeded at 937 (offset 5 lines).
Hunk #2 succeeded at 976 (offset 5 lines).
patching file dlls/dinput/dinput_main.c
patching file dlls/dinput/mouse.c
patching file dlls/winex11.drv/event.c
patching file dlls/winex11.drv/mouse.c
Hunk #3 succeeded at 146 (offset -2 lines).
Hunk #4 succeeded at 1094 (offset -7 lines).
patching file dlls/winex11.drv/winex11.drv.spec
Hunk #1 succeeded at 159 (offset 1 line).
patching file dlls/winex11.drv/x11drv.h
Hunk #1 succeeded at 728 (offset -2 lines).
Hunk #2 succeeded at 857 (offset -2 lines).
patching file dlls/winex11.drv/x11drv_main.c
patching file include/config.h.in
Hunk #1 succeeded at 371 (offset -6 lines).
Hunk #2 succeeded at 1097 (offset -6 lines).


Like I stated in my previous post, I use xorg-server 2:1.10.1-1ubuntu1

so the patching and compiling progress was fine, but it just didn't help :(

Did you make any good progress?
Comment 481 Ivan 2011-05-04 14:42:13 CDT
(In reply to comment #480)

> Like I stated in my previous post, I use xorg-server 2:1.10.1-1ubuntu1
> 
> so the patching and compiling progress was fine, but it just didn't help :(
> 
> Did you make any good progress?

Yes, I used 
> Dan Kegel  2011-03-08 15:41:24 CST 
> Created an attachment (id=33574) [details]
> Rediffed to apply to today's git
that patch with wine 1.3.17 and it fixed all games with issue I had(unreal 3, mass effect, dragon age)
Comment 482 David 2011-05-04 14:57:44 CDT
(In reply to comment #481)
> (In reply to comment #480)
> 
> > Like I stated in my previous post, I use xorg-server 2:1.10.1-1ubuntu1
> > 
> > so the patching and compiling progress was fine, but it just didn't help :(
> > 
> > Did you make any good progress?
> 
> Yes, I used 
> > Dan Kegel  2011-03-08 15:41:24 CST 
> > Created an attachment (id=33574) [details] [details]
> > Rediffed to apply to today's git
> that patch with wine 1.3.17 and it fixed all games with issue I had(unreal 3,
> mass effect, dragon age)

That is the exact same patch I used!

Ans what OS and Xorg version are you running if I may ask?
Comment 483 Ivan 2011-05-04 16:20:02 CDT
(In reply to comment #482)

> That is the exact same patch I used!
> 
> Ans what OS and Xorg version are you running if I may ask?

openSUSE 11.4 with xserver 1.9.3
Hope it is not offtopic here
Comment 484 Mark I. 2011-05-05 03:24:01 CDT
There appears to be a regression in 1.3.18 for Raven Shield. In 1.3.17 and earlier, setting MouseWarpOverride to force worked perfectly, but in 1.3.18 and 1.3.19 it doesn't work at all. The cursor is stuck in the middle of the main menu and the mouse escapes. The keyboard cannot be used to navigate the menu, so it's now unplayable.

I also have Unreal Tournament 3 and I haven't noticed any change in this bug for it. In this case MouseWarpOverride force works as before: prevents mouse from escaping, but locks it to center of menus and requires keyboard navigation.
Comment 485 David 2011-05-10 16:04:02 CDT
Well I tried about everything, but I'm still unable to get 360 degrees mouse rotation in ME2 and Assassins Creed.

wine 1.3.17 + xinput2 patch => no 360 degrees mouse rotation
wine 1.3.18 and wine 1.3.19 => no 360 degrees mouse rotation

I used the following command to test XInput2:
  david@overlord:~$ xinput test-xi2
And that works just fine! as soon as I leave the test window, it starts reading my raw mouse movement. So that should be fine...

I run one of the newest versions of Xorg "X.Org X Server 1.10.1" which was released on 2011-04-15

I seriously don't know what else I'm supposed to do to fix it.. does anyone has anything else to try?

I don't care if I have to patch or tweak wine, since its running in a separate wine prefix. so any ideas are welcome!

Another question that arises:
What are the exact requirements to get 360 mouse rotation working in the games that are affected by this bug?

some people get it working, some not, I'm really wondering what is the magic trick what's required?
Comment 486 André H. 2011-05-11 14:21:47 CDT
The mouse in UT3 works for me with todays git and the new checkbox in winecfg checked (didn't even tried without it)
Comment 487 David 2011-05-11 15:43:20 CDT
OMG! I got it working!

I'm such a ******* IDIOT!
Thanks to the last post about the winecfg (from André H.), I checked that GUI again, and I found out that I had lots of DLL overrides in place, including a 'native' override for 'dinput'!

So I removed ALL overrides, and it already worked much better with the newest release (wine 1.3.19) but with wine 1.3.17 + the latest XI2 patch it now works flawlessly! Both Assassins Creed and Mass Effect 2!

So to anyone who finds this bug page, and didn't get it to work yet, please try the following:

1 - Download wine 1.3.17
2 - Download the DI2 mouse patch:
      http://bugs.winehq.org/attachment.cgi?id=33574
3 - Patch wine 1.3.17 (using patch -p < <patch_file_name>)
4 - build this new patched wine (using ./configure, followed by make)
5 - launch the game using this freshly build wine!

And then it rocks! It all works! I've set everything setting to the highest possible and it all works (if your hardware is good enough ofcourse)

Thank you all, for all your thoughts and help!
Comment 488 Austin English 2011-05-11 16:15:24 CDT
(In reply to comment #486)
> The mouse in UT3 works for me with todays git and the new checkbox in winecfg
> checked (didn't even tried without it)

Bulletstorm demo works in wine-1.3.19-284-g35c743b with the option enabled (without it, I can rotate 180 degrees).

Also tried Mass Effect 2, but it seems the mouse work caused a regression there, see bug 27137.
Comment 489 Roman 2011-05-12 04:11:35 CDT
I have an issue with Aliens vs. Predator 2 with wine 1.3.17 + XInput2 patch from here. After loading a level, the picture starts to crazily rotate at high speed, although I do not touch mouse at all. The debug logs suggest that this happens because the game itself is contiuously warping the pointer to the screen center, calling (through wine) XWarpPointer. But this call triggers an XI_RawMotion event with *absolute* screen coordinates, as requested in XWarpPointer, rather then with their relative offset. This can be checked using a testcase from here:
http://comments.gmane.org/gmane.comp.freedesktop.xorg.devel/12204
The functions responsible for tracking xi2 interpret them as relative movements, so wine continuosly send dinput events as if the mouse was continuously jumping by (640,400) (for my resolution 1280x800), and this causes constant crazy rotation of the picture.

Comparing the behaviour of the game in different wine versions:
wine 1.3.17 - mose aiming is trembling; it is usable only with maximum "mouse smoothing" in-game setting
wine 1.3.17 + XInput2 patch - crazy rotation, as I described
wine 1.3.18 - mouse is almost stuck, the picture practically does not react on mouse moving; only some small shifts of the picture may occure from time to time (when rapidly moving mouse in various directions during a few seconds continuosly).
Comment 490 André H. 2011-05-12 12:12:10 CDT
please stop patching old wine, but test the fix in git (or wait until wine-1.3.20, most likely tomorrow) with your games
Comment 491 Brian Vuyk 2011-05-13 10:23:50 CDT
WWII Online: Battleground Europe no longer experiences any mouse issues under 1.3.19. The mouse problems are completely resolved. Thanks for all the hard work on this.
Comment 492 Jonathan Strander 2011-05-13 22:52:26 CDT
This issue is completely resolved for me in all tested cases except one:

Unless MouseWarpOverride is disabled Metro 2033 will completely lock up if the mouse is moved in any way. And when MouseWarp is set to disabled the mouse cursor can not be moved at all.

(Note: Tested a variety including Fallout:NV, Mass Effect 2, Crysis, etc)
Comment 493 Jonathan Strander 2011-05-13 23:36:23 CDT
(In reply to comment #492)
> This issue is completely resolved for me in all tested cases except one:
> 
> Unless MouseWarpOverride is disabled Metro 2033 will completely lock up if the
> mouse is moved in any way. And when MouseWarp is set to disabled the mouse
> cursor can not be moved at all.
> 
> (Note: Tested a variety including Fallout:NV, Mass Effect 2, Crysis, etc)

Tested one more: The Witcher.

In this instance the camera can be rotated 360 degrees but it appears to jump back to an old position randomly.
Comment 494 Jacques-Pascal Deplaix 2011-05-14 02:03:40 CDT
Unreal Tournament III: Works perfectly with Wine 1.3.20 (without MouseWarpOverride=force) !
Comment 495 rocko 2011-05-14 03:36:02 CDT
360 degree mouse rotation still doesn't work in Crysis for me with wine 1.3.20. (It does though with the patched 1.3.17.)
Comment 496 rocko 2011-05-14 03:49:46 CDT
A correction re my last post about Crysis:

1) 360 degree rotation DOES work if I tell wine 1.3.20 to allow DirectX apps to stop the mouse pointer leaving the window, but DOESN'T if I untick this option. (1.3.17 works with it unticked.)

2) I meant to say Crysis Warhead. Crysis is crashing under wine ATM for some reason so I can't test it.
Comment 497 Nagy Gergő 2011-05-14 08:08:28 CDT
Yipi, the 360 look around is really fine in:

Thief: Deadly Shadow (steam game)

BUT in Half-Life 2, Counter Strike Source , and other HL2 engine's game are really problematic. Namely the pointer is jumping position when moveing it about every secundum. When mouse is idle the game runing fine.
Almost good, but made the Most played game unplayable.

Keep up the good work.

Geri
Comment 498 Jonathan Strander 2011-05-14 08:20:38 CDT
(In reply to comment #496)
> A correction re my last post about Crysis:
> 
> 1) 360 degree rotation DOES work if I tell wine 1.3.20 to allow DirectX apps to
> stop the mouse pointer leaving the window, but DOESN'T if I untick this option.
> (1.3.17 works with it unticked.)
> 
> 2) I meant to say Crysis Warhead. Crysis is crashing under wine ATM for some
> reason so I can't test it.

To have 360 rotation work properly, yes this option will need to be ticked. It enables cursor clipping.

(In reply to comment #497)
> Yipi, the 360 look around is really fine in:
> 
> Thief: Deadly Shadow (steam game)
> 
> BUT in Half-Life 2, Counter Strike Source , and other HL2 engine's game are
> really problematic. Namely the pointer is jumping position when moveing it
> about every secundum. When mouse is idle the game runing fine.
> Almost good, but made the Most played game unplayable.
> 
> Keep up the good work.
> 
> Geri

This sounds like the exact same behavior I experienced in The Witcher (which uses the Aurora Engine).
Comment 499 Sven Arvidsson 2011-05-14 08:24:13 CDT
STALKER: Clear Sky is also improved with git master. You still need to start the game with "-i" to get any mouse movement at all, but now there's no need to toggle this option on and off the get mouse movement in the inventory screen.
Comment 500 Jacques-Pascal Deplaix 2011-05-14 10:04:41 CDT
Since 1.3.20 in Call of Duty 4 the mouse is crazy !
It's realy unplayable !
Comment 501 Berillions 2011-05-14 11:20:15 CDT
The 360 degree mouse rotation in Wine 1.3.20 on Mass Effect 2 works completly.
Comment 502 Erich E. Hoover 2011-05-14 12:50:53 CDT
(In reply to comment #501)
> The 360 degree mouse rotation in Wine 1.3.20 on Mass Effect 2 works completly.

I'm not sure if there's a way to "unlink" an application from a bug, but this issue is also fixed with Fallout 3 in Wine 1.3.20.
Comment 503 Austin English 2011-05-14 17:43:59 CDT
Since most games appear to be working, I think it's safe to mark this bug fixed. Keep in mind, there are a few more open bugs, namely bug 27156, which sounds like the problem most people are having with crazy jumping (Half Life/Bioshock/etc.).

Any other problems should be tracked in separate bugs (check for dupes first). If the behavior is different from a previous version of Wine, please run a regression test before filing a bug:
http://wiki.winehq.org/RegressionTesting
Comment 504 Austin English 2011-05-14 17:44:09 CDT
Since most games appear to be working, I think it's safe to mark this bug fixed. Keep in mind, there are a few more open bugs, namely bug 27156, which sounds like the problem most people are having with crazy jumping (Half Life/Bioshock/etc.).

Any other problems should be tracked in separate bugs (check for dupes first). If the behavior is different from a previous version of Wine, please run a regression test before filing a bug:
http://wiki.winehq.org/RegressionTesting
Comment 505 rocko 2011-05-14 19:39:12 CDT
@Jacques-Pascal Deplaix: I find that the crazy mouse jumping goes away in CoD4 if you untick the option to allow fullscreen applications to grab the mouse.


Although I guess it is true that this bug is resolved, I suspect it could be improved further. With 1.3.17 + xinput2 patch, there was no crazy mouse jumping, and auto-clipping was automatically enabled when the application wanted to use the mouse to let the player control his character, but disabled when you went back into the menus, so eg in Crysis you could press the escape key and go to another (Gnome) window.
Comment 506 Ahmed W. 2011-05-18 19:27:58 CDT
This bug still applies to Assassin's Creed.
Comment 507 Lev V. Babchenko 2011-05-19 00:25:53 CDT
now this bug appears in World of Warcraft session (with -opengl, yes):
when display mode is "window-on-whole-screen" then attempts of turn character's has unpredictable results
(normal/maximized window is all right)
tested with all values (force, disable, enable) for HKCU/Software/Wine/DirectInput/MouseWarpOverride 

1.3.19 -> has no bug
1.3.20 -> bug
Comment 508 Erik 2011-05-19 02:40:57 CDT
(In reply to comment #507)
> now this bug appears in World of Warcraft session (with -opengl, yes):
> when display mode is "window-on-whole-screen" then attempts of turn character's
> has unpredictable results
> (normal/maximized window is all right)
> tested with all values (force, disable, enable) for
> HKCU/Software/Wine/DirectInput/MouseWarpOverride 
> 
> 1.3.19 -> has no bug
> 1.3.20 -> bug

This is a regression, see also bug 27156 . Compiling without XInput2 support makes the jumping in WoW stop.
Comment 509 byteframe 2011-05-19 11:25:27 CDT
I have only xorg-server 1.7.7 and no xinput2 patch, but this bug was fixed (for all the games I play, with or without the new option, in window/fullscreen mode). I'm confused, Why was this not implemented earlier?
Comment 510 byteframe 2011-05-19 11:38:52 CDT
Oops. I quess xorg-1.7.7 has the xinput2 stuff. Nevermind then. Good work! The following games that had the bug are now fixed for m: Deus Ex 2, Thief 3, UT3, KillingFloor, Redorchestra.
Comment 511 Berillions 2011-05-22 13:16:47 CDT
(In reply to comment #506)
> This bug still applies to Assassin's Creed.

With wine 1.3.20, the bug has disappear. I can turn my character at 360° correctly.
Comment 512 Mark I. 2011-05-25 01:02:36 CDT
The capture option now works for me in UT3, but with it enabled I get excessive mouse lag when clicking, making it difficult to simultaneously aim and shoot. It's a slow refresh rate of the mouse, causing aim to jump about once or twice a second while holding a mouse button. Frame rate and keyboard are fine while it is happening.

This lag isn't an issue if the capture option is disabled. Has anyone else noticed this? It seems to be a regression related to the fix, though I'm not sure since I've barely touched UT3 before 1.3.20 and haven't done regression testing yet.
Comment 513 Alexandre Julliard 2011-05-27 13:36:55 CDT
Closing bugs fixed in 1.3.21.
Comment 514 Wylda 2011-07-31 14:52:28 CDT
*** Bug 27942 has been marked as a duplicate of this bug. ***
Comment 515 Zhenya 2012-04-15 16:48:18 CDT
Can anybody port one of this two patches to latest versions of Wine, 1.4 o 1.5.2? http://bugs.winehq.org/attachment.cgi?id=15638 http://bugs.winehq.org/attachment.cgi?id=29687 I haven't X Input 2 support on my Linux, and I want to play with X Input 1.
Comment 516 mrdeathjr28 2014-10-22 18:12:04 CDT
mouse escapes from windows in legend of korra with wine 1.7.28-1.7.29 with nvidia 343.22, in fullscreen only work in certain area


Hosted By CodeWeavers