[Bug 6971] Mouse "escapes" window or is confined to an area in the full screen program

http://bugs.winehq.org/show_bug.cgi?id=6971

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

Paul "TBBle" Hampson  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

Christoph Korn  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

chaykin  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|[e-mail]         |

Adrian Lüthi  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

dlzerocool  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

Stephane Mikaty  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

Casey Jones  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

Dennis Schridde  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

Lars Blomqvist  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]
                   |                            |t

Alessandro Pedarra  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]
                   |                            |m

sheen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

Danila Sentiabov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

Brian  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

Jan Kalab  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

Michael Bonfils  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

Jake  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

Jack Diaz  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

Giovanni Ongaro  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

Konrad Materka  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

Martin Klapetek  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #234 from Vitaliy Margolen   2009-03-20 10:45:03 ---
*** Bug 17801 has been marked as a duplicate of this bug. ***

--- Comment #235 from Paul "TBBle" Hampson   2009-03-22 10:05:43 ---
XInput2 is starting to firm up
(http://lists.x.org/archives/xorg-devel/2009-March/000514.html via Phoronix) so
it might be a good time to investigate a preliminary XInput2-based solution to
this bug, and ensure that the XInput2 API is sufficient (while it's still
malleable enough to fix) to cover the requirements.

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

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

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

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

http://msdn.microsoft.com/en-us/library/bb147211(VS.85).aspx (briefly)
documents a sample program in the DirectX SDK which exercises the various modes
of using the mouse under DirectInput.

--- Comment #236 from Paul "TBBle" Hampson   2009-03-22 11:26:38 ---
(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
from comment 82 appears to be doing) is that (as far as I understand from the
manpage, I haven't tried this) it also affects what windows actually receive
X11 events, which isn't actually true of ClipCursor, although it will produce
the correct results for the general use-case of a Win32 program calling
ClipCusor with its own window rectangle or client-area rectangle.

Anyway, if ClipCursor does have any issues, it probably should be addressed in
a seperate bug, or this bug just gets too conflated.

--- Comment #237 from Peter Kovacs   2009-03-26 16:20:23 ---
> From what I understand the main Problem is that we only have absolute position

on the mouse, but for the Game interface we need vector oriented presentation.
Right? So I started to look for a way to get Vectored Events from X.
I stumbled across XTrap. They talk of Vectorevents ...
Cant we make use of that?
Sorry if I get the issue wrong. I am quite unskilled in C/C++ and have no Idea
of X. I just researched a bit and read stuff that could help. (I did not even
ask anyone :P ) So for me this is a shot into the Blue.

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

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

Hope it helps!
Peter

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

So I might be looking in the wrong place for the actual extension implemented.
But certainly the xserver-xorg-core package on Debian/unstable doesn't list
XTrap in xdpyinfo by default.

--- Comment #239 from Paul "TBBle" Hampson   2009-03-27 08:23:19 ---
Ignore that, I confused XTrap and XTest. It's compiled, but not enabled by
default.

--- Comment #240 from Paul "TBBle" Hampson   2009-03-29 03:49:18 ---
http://wiki.winehq.org/DInput has some XInput2 information.

--- Comment #241 from Paul "TBBle" Hampson   2009-03-31 07:00:57 ---
Xorg has dropped XTrap as of Xserver 1.6.

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

--- Comment #242 from Joey Forgues Forget   2009-04-06 12:38:57 ---
Created an attachment (id=20315)
 --> (http://bugs.winehq.org/attachment.cgi?id=20315)
add a toggle with the middle mouse button for the mouse wrapping.

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

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

Obviously, this is only meant as a temporary solution, but its enough for me.

--- Comment #243 from dlzerocool   2009-04-26 06:02:12 ---
Created an attachment (id=20721)
 --> (http://bugs.winehq.org/attachment.cgi?id=20721)
mouse patch modified only recenter mouse when right,left or middle click is
down.

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

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

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

This is a sort of hack, so it's not a really usable patch...
But it can help for some games at moment, so I post my changes added to this
patch here.

--- Comment #244 from dlzerocool   2009-04-26 06:30:55 ---
(In reply to comment #243)
> Created an attachment (id=20721)

--> (http://bugs.winehq.org/attachment.cgi?id=20721) [details]
> mouse patch modified only recenter mouse when right,left or middle click is
> down.
>
> This patch is a version modified on one that is actually present here.
>
> The only change is that when right/left/middle click is not pressed, center the
> mouse on the screen is not applied.
>
> Like warhammer online other games only have problems with mouse when right or
> left clic is used.
> Some games use this function with middle click so I added middle click too.
>
> This is a sort of hack, so it's not a really usable patch...
> But it can help for some games at moment, so I post my changes added to this
> patch here.

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

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

enjoy.

--- Comment #245 from James Stone   2009-05-04 11:26:25 ---
Given the wide range of apps that are affected by this bug, it's severity
should probably be upped from Normal to Major.

--- Comment #246 from Lars Blomqvist   2009-05-11 14:00:52 ---
Created an attachment (id=21031)
 --> (http://bugs.winehq.org/attachment.cgi?id=21031)
Output during lag/freeze when using patch id=18681

(In reply to comment #206)
> Created an attachment (id=18681)

--> (http://bugs.winehq.org/attachment.cgi?id=18681) [details]
> Hack to read raw mouse movement from /dev/input/mice
>
> ...

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

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

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

Any thoughts?

--- Comment #247 from [e-mail]  2009-06-04 12:05:53 ---
Created an attachment (id=21554)
 --> (http://bugs.winehq.org/attachment.cgi?id=21554)
Patch for mouse for bug 6971

--- Comment #248 from [e-mail]  2009-06-04 12:38:28 ---
(From update of attachment 21554)
to activate
WINEFORCEMOUSEWARP=yes wine proggy.exe

--- Comment #249 from [e-mail]  2009-06-04 12:44:10 ---
The Patch that i have proposed works for all Ut3 engine games, Crysis and
Crysis Warhead and all those ut2004 engine games, this i my firts try at wines
mouse but i hope this patch can be useful to all the community

--- Comment #250 from Vitaliy Margolen   2009-06-04 19:38:45 ---
*** Bug 18774 has been marked as a duplicate of this bug. ***

--- Comment #251 from Alessandro Pedarra   2009-06-19 12:17:41 ---
Please how can I implement this patch? I'm not a programmer so if you can
explain it to me... many thanks.

--- Comment #252 from sheen   2009-06-19 12:45:56 ---
(In reply to comment #251)
> Please how can I implement this patch? I'm not a programmer so if you can
> explain it to me... many thanks.

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

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

(Don't forget to install all the needed library, you should find them on the
wiki)

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

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

(?)

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

Sorry I've forgotten the ./configure line (before make depend), but you'll need
all the library
The best way for you is here : http://wiki.winehq.org/WineOn64bit
All is explained, for all environment.

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

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

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

Thanks anyway for your support sheen. ;)

--- Comment #256 from Brian   2009-06-20 06:54:10 ---
(In reply to comment #248)
> (From update of attachment 21554 [details])
> to activate
> WINEFORCEMOUSEWARP=yes wine proggy.exe

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

I tried this patch but it didn't seem to change anything.

--- Comment #257 from Valeriy Malov   2009-07-09 12:17:28 ---
Is xinput2 support already implemented somewhere (git?)? Like, if still there
is no grab support, maybe it can work with fullscreen?

--- Comment #258 from Jake   2009-07-29 20:38:21 ---
as anyone tried making a mouse warping program for xorg?

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

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

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

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

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

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

For a starting point, probably at least the mouse would need to be moved on a
tenth or a hundredth of a second basis, because in FPSes the mouse may need to
be moved fast.

--- Comment #259 from Jack Diaz   2009-08-10 21:32:08 ---
Raziel recommended using HKEY_CURRENT_USER --> Software --> Wine,
Key=DirectInput, String=MouseWarpOverride, Value=force. I'm testing it right
now on Wine 1.1.27 its working with no patch. I have not tested this on other
games yet but it does fix the mouse problem while playing Bioshock.

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

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

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

--- Comment #261 from Giovanni Ongaro   2009-08-23 16:15:12 ---
(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