*** Bug 6981 has been marked as a duplicate of this bug. ***

*** Bug 7005 has been marked as a duplicate of this bug. ***

(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).

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.

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!

Half-Life (all versions) don't use dinput and never did. This bug does not apply
to them.

yeah sorry you are right, hl2 just breaks regularly for me.

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

Rainbow Six: Raven Shield is almost playable now in WINE, and this is one of the
few bugs left that affects it.

Postal 2 is affected too

*** Bug 7450 has been marked as a duplicate of this bug. ***

*** Bug 7613 has been marked as a duplicate of this bug. ***

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?

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.

This bug does not depend on anything. It's other way around.

*** Bug 7958 has been marked as a duplicate of this bug. ***

*** Bug 7968 has been marked as a duplicate of this bug. ***

Rephrase the summary to include full screen programs.

*** Bug 8561 has been marked as a duplicate of this bug. ***

Native dinput8.dll also shows this issue for me in Quake Wars. Does this bug
cover this?

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.

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"

*** Bug 3219 has been marked as a duplicate of this bug. ***

i hav the same problem with various Unreal 2 Engine games(UT2003/2004, Unreal 
2, Brothers in Arms RTH30, Brothers in Arms EIB)

*** Bug 9244 has been marked as a duplicate of this bug. ***

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.

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.

*** Bug 9846 has been marked as a duplicate of this bug. ***

Well I don't want to nominate my own bug, but this really should be fixed by 1.0.0

i agree, tons of games are affected by this bug, fixing it will make a lot more of them playable.

It does seem to affect a lot of apps, so it's a good candidate for 1.0.

did a patch for this just go into GIT?

(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.

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.)

*** Bug 10553 has been marked as a duplicate of this bug. ***

*** Bug 10556 has been marked as a duplicate of this bug. ***

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.

I can confirm this in Unreal 2 with wine 0.9.51

I can confirm the patch fixes mouse behavior in the game XIII.

*** Bug 10927 has been marked as a duplicate of this bug. ***

*** Bug 7247 has been marked as a duplicate of this bug. ***

*** Bug 11089 has been marked as a duplicate of this bug. ***

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.

I got this problem with Wine 0.9.53 Raven Shield v1.0 and v1.6 and the patch does work effectively

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.

*** Bug 11381 has been marked as a duplicate of this bug. ***

FYI.
Still happens in Red Orchestra / OSF under wine 0.9.52. (F8/x86_64)
Have yet to try the mouse-wrapping patch.

- Gilboa

This problem still occurs on Swat 4 under wine 9.54 (under linux ubuntu 7.04). Can someone help me ?
Thank you

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

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!

(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.

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...

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

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?

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

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.

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?

(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]

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.

(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! ***

(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.

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."

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!

... i used it under version 0.9.56, if that's of any interest

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?

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?

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).

using events device would be linux specific, the bug would still remain for freebsd, solaris, etc etc.

(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.

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.

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.)

*** Bug 12177 has been marked as a duplicate of this bug. ***

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?

maybe link to manymouse from icculus.org

http://icculus.org/manymouse/

it provides mousing abstraction on linux mac etc. is zlib license though :\

Quake 3 affected by this bug too

> 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.

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.

(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.

> 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.

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?

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 ;)

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.

Created attachment 11736 [details]
winex11.drv: Process LeaveNotify to ungrab the pointer

Second patch

Created attachment 11737 [details]
winex11.drv: Virtualize mouse pointer if it's invisible and grabbed

Third patch.

(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

(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.

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)

(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.

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?

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

(In reply to comment #90)
> What version do these latest three patches work with?
Old. You can see dates for yourself in each patch.

*** Bug 12472 has been marked as a duplicate of this bug. ***

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.

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

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.

*** Bug 13096 has been marked as a duplicate of this bug. ***

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

(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

It applies fine in the latest git with -p0

patch works for me against 1.0-rc1, now I can play gta3 again! :D

(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?

(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 

(In reply to comment #102)

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

WINEFORCEMOUSEWARP=yes wine yourapp.exe

(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.

(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 !

(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

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

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 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.

*** Bug 13385 has been marked as a duplicate of this bug. ***

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

This bug is present in Unreal Tournament 3, and therefore likely to be present in all other Unreal Engine 3 games as well.

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

*** Bug 13929 has been marked as a duplicate of this bug. ***

*** Bug 8291 has been marked as a duplicate of this bug. ***

*** Bug 14017 has been marked as a duplicate of this bug. ***

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

The patch wont be included unless it is submitted to Wine Patches AND it is up to the standard that AJ will accept.

*** Bug 14071 has been marked as a duplicate of this bug. ***

Here's another confirmation that the 7774 patch works with "XIII"

*** Bug 14307 has been marked as a duplicate of this bug. ***

*** Bug 14655 has been marked as a duplicate of this bug. ***

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

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...

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.

*** Bug 14890 has been marked as a duplicate of this bug. ***

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.

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.

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

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)

(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.

Confirming that Vitaliy's workaround works for Raven Shield.

(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

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

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!

(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.

(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

> 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!

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.

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?

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.

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. 

"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?

(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?

(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.

(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

(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?

> 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)

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).

(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.

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.

(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.

(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 :)

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.

(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. 

> 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.

(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.

>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.

Created attachment 15638 [details]
Proposed mouse improvement for 'stuck menu problem

(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?

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.

(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 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.

"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... :)

That doesn't work for the pointer that stuck in the corner. Mouse keeps moving. But pointer not.

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..

(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.

(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.

(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. 

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?

(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".

(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.

(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?

(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?

(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 :)

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**

As far as I understand it, the screen would have to be infinitely large. Doesn't work

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.

*** Bug 15476 has been marked as a duplicate of this bug. ***

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.

This is also not a problem in dosbox with games requiring a mouse..

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"?

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.

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).

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

(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.

(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.

*** Bug 16067 has been marked as a duplicate of this bug. ***

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 ...

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.

*** Bug 16119 has been marked as a duplicate of this bug. ***

*** Bug 16106 has been marked as a duplicate of this bug. ***

(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.

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.

(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.

(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)

(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.

(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.

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.

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.

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

@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).

Created attachment 18509 [details]
terminal output for SWAT4 game

(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.

*** Bug 16819 has been marked as a duplicate of this bug. ***

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().

(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.

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!

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.

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.

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.

(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.

(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.

(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.

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).

(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.

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.

(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.

(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.

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.

(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.

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.

*** Bug 17157 has been marked as a duplicate of this bug. ***

(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.

(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.

This bug still persists in Wine 1.1.15, tested with Unreal II XMP on OpenSUSE. Is there a working fix yet?

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"

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

why it's so difficult to fix mouse behaviour !!!!!
I can't understand :(

Same problem in GTAIII. The mouse leaves the windows... And with versions 0.9.7, 1.1.9, 1.1.16.

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.

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)

*** Bug 17751 has been marked as a duplicate of this bug. ***

*** Bug 17801 has been marked as a duplicate of this bug. ***

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.

(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.

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

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.

Ignore that, I confused XTrap and XTest. It's compiled, but not enabled by default.

http://wiki.winehq.org/DInput has some XInput2 information.

Xorg has dropped XTrap as of Xserver 1.6.

http://www.x.org/wiki/Server16Branch#head-b1f125722e5fa755198eaff3e42c1cfffc861f90

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.

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.

(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.

Given the wide range of apps that are affected by this bug, it's severity should probably be upped from Normal to Major.

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?

Created attachment 21554 [details]
Patch for mouse for bug 6971

Comment on attachment 21554 [details]
Patch for mouse for bug 6971

to activate
WINEFORCEMOUSEWARP=yes wine proggy.exe

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

*** Bug 18774 has been marked as a duplicate of this bug. ***

Please how can I implement this patch? I'm not a programmer so if you can explain it to me... many thanks.

(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)

(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$ 

(?)

(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.

(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. ;)

(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.

Is xinput2 support already implemented somewhere (git?)? Like, if still there is no grab support, maybe it can work with fullscreen?

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.

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.

(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 #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

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

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

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.

Also affects borderlands.

*** Bug 20593 has been marked as a duplicate of this bug. ***

Also affects "Point blank". Rude hack with permanent mouse wrapping makes menu unusable

*** Bug 20582 has been marked as a duplicate of this bug. ***

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.

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) :)

*** Bug 20796 has been marked as a duplicate of this bug. ***

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?

> 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''

(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?

> 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.

(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.

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?

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 :(

Created attachment 25097 [details]
New version of giovanni.nicola patch (21554) to work with Wine 1.1.34

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! ;)

(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"

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!

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.

(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.

(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"....

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.

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.

(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.

(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?

(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.

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.

(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.

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".

(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.

(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.

(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)

(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.

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...

(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.

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.

(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.

(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.

> 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.

(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)

"current (broken) behavior" means as it is today.

The patch for 34 works with wine 35 as well

http://bugs.winehq.org/attachment.cgi?id=25097

patch works with 36 as well

(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.

Wasn't someone here working on a patch to implement XInput 2?
If so, i'd like to test it...

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....

(In reply to comment #307)
> patch works with 36 as well

Works in 37 fine

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

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.

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.

Created attachment 26091 [details]
Resolves mouse problems for ME / ME 2

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.

(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 on attachment 26091 [details]
Resolves mouse problems for ME / ME 2

What part of NO HACKS don't you Bontas Marcel understand?

(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

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

(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.

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.

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

(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.

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...

(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 ...

(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.

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.

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.

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

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.

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

(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

(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.)

(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)]

*** Bug 22729 has been marked as a duplicate of this bug. ***

XI2 support won't happen for 1.2.

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.

Oh, and he says he tested on Ubuntu 10.04.

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

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?

(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

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.

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.

(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?

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

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

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.

(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.

In Steam download Thief - Deadly Shadows the mouse cannot turn around in X axis is still an issue.

Wine 1.2rc6

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).

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.

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.

(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.

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!

(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?! ;)

(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.

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.

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.

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.

(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?

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.

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.

(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])

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.

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.

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.

*** Bug 23579 has been marked as a duplicate of this bug. ***

Debian has Xorg 1.8 in their "experimental" tree: http://packages.debian.org/search?keywords=xserver-xorg-core

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]

(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!

(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.

(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.

(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.

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)

*** Bug 22282 has been marked as a duplicate of this bug. ***

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,

(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!

(In reply to comment #378)
This patch doesn't work with Wine 1.2 source.

(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

(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

> 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.

(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.

(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.

(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

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.

(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

(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?

(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)

(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?

(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.

madscientist, that patch did not fix those problems. The behaviour is practically identical to unpatched wine.

*** Bug 13603 has been marked as a duplicate of this bug. ***

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.

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

(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.

(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.

(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.

(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

(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

(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°.

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.

"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.

(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?

The rumor I hear is that it would take a few weeks of a senior developer's time to whip it into shape.

(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.

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.

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)

(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.

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.

(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.

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).

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.

(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.

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

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?

> 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.

(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.

So what's the progress on this. Is is going into trunk soon now that Ubuntu 10.10 is out?

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)

Created attachment 31405 [details]
xinput2 patch fixed for wine git from 20101020 (after-1.3.5)

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

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.

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!

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

Latest patch doesn't apply anymore with the latest git as of today.

Created attachment 31693 [details]
Add Xinput2 support

updated patch to apply against current git

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))

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.

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?

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.

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.

(Well, "probably going to happen before next release" might be a bit strong,
but it seems likely to me.)

Created attachment 32768 [details]
Xinput2 patch, fixed for commit 179b862738aae3b84b87c8e421cef868fe60e87e (01/08/2011)

IDirectInputDevice2AImpl was renamed to IDirectInputDeviceImpl.

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)

*** Bug 25855 has been marked as a duplicate of this bug. ***

(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...

*** Bug 26274 has been marked as a duplicate of this bug. ***

Created attachment 33574 [details]
Rediffed to apply to today's git

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!

(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".

(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).

(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 ?

*** Bug 26408 has been marked as a duplicate of this bug. ***

(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.

(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!

(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 on attachment 15638 [details]
Proposed mouse improvement for 'stuck menu problem

Marking this patch as obsolete as Xinput2 is definately the way to go.

(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

(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.

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.

*** Bug 22282 has been marked as a duplicate of this bug. ***

(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

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...

Looks like it needs to be rediffed again.

(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.

(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 ;-).

(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??

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?

(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.

(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.

Wine 1.3.18 doesn't works with Mass Effect too.
I must to use 1.2.3 with an old patch.

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).

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.

Unfortunately no improvement with DC Universe Online (Unreal Engine).

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.

Uru: Ages Beyond Myst now works fine.

UT3: Black (Steam) still requires MouseWarpOverride=force setting to achieve full 360+ rotations...

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.

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 :(

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.

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.

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.

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

(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.

(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.

(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!

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'

(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?

(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?

(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)

(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?

(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

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.

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?

The mouse in UT3 works for me with todays git and the new checkbox in winecfg checked (didn't even tried without it)

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!

(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.

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).

please stop patching old wine, but test the fix in git (or wait until wine-1.3.20, most likely tomorrow) with your games

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.

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)

(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.

Unreal Tournament III: Works perfectly with Wine 1.3.20 (without MouseWarpOverride=force) !

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.)

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.

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

(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).

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.

Since 1.3.20 in Call of Duty 4 the mouse is crazy !
It's realy unplayable !

The 360 degree mouse rotation in Wine 1.3.20 on Mass Effect 2 works completly.

(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.

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

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

@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.

This bug still applies to Assassin's Creed.

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

(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.

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?

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.

(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.

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.

Closing bugs fixed in 1.3.21.

*** Bug 27942 has been marked as a duplicate of this bug. ***

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.

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