June 2009 - Wine-bugs - list.winehq.org

[Bug 6971] Mouse "escapes" window or is confined to an area in the full screen program
by wine-bugs＠winehq.org 19 Jun '09

19 Jun '09

http://bugs.winehq.org/show_bug.cgi?id=6971 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jounijarvis(a)gmail.com Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson(a)Pobox.com Christoph Korn <c_korn(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |c_korn(a)gmx.de chaykin <rchayster(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|rchayster(a)gmail.com | Adrian Lüthi <adi.l(a)bluewin.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adi.l(a)bluewin.ch dlzerocool <dl.zerocool(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool(a)gmail.com Stephane Mikaty <stephane(a)mikaty.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stephane(a)mikaty.net Casey Jones <pvtpuddin(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pvtpuddin(a)gmail.com Dennis Schridde <lindevel(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lindevel(a)gmx.net Lars Blomqvist <knaprigt(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |knaprigt(a)gmail.com giovanni.nicola(a)ticino.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |giovanni.nicola(a)ticino.com Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle(a)users.sourceforge.ne | |t Alessandro Pedarra <alessandro.pedarra(a)inbox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alessandro.pedarra(a)inbox.co | |m sheen <toxmerguez(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |toxmerguez(a)yahoo.fr Danila Sentiabov <dsent.zen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dsent.zen(a)gmail.com --- Comment #234 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-03-20 10:45:03 --- *** Bug 17801 has been marked as a duplicate of this bug. *** --- Comment #235 from Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> 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 <Paul.Hampson(a)Pobox.com> 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 <legine(a)gmx.net> 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 <Paul.Hampson(a)Pobox.com> 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 <Paul.Hampson(a)Pobox.com> 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 <Paul.Hampson(a)Pobox.com> 2009-03-29 03:49:18 --- http://wiki.winehq.org/DInput has some XInput2 information. --- Comment #241 from Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> 2009-03-31 07:00:57 --- Xorg has dropped XTrap as of Xserver 1.6. http://www.x.org/wiki/Server16Branch#head-b1f125722e5fa755198eaff3e42c1cfff… --- Comment #242 from Joey Forgues Forget <Jey123456(a)gmail.com> 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 <dl.zerocool(a)gmail.com> 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 <dl.zerocool(a)gmail.com> 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 <stonej4(a)mcmaster.ca> 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 <knaprigt(a)gmail.com> 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 giovanni.nicola(a)ticino.com 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 giovanni.nicola(a)ticino.com 2009-06-04 12:38:28 --- (From update of attachment 21554) to activate WINEFORCEMOUSEWARP=yes wine proggy.exe --- Comment #249 from giovanni.nicola(a)ticino.com 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 <vitaliy(a)kievinfo.com> 2009-06-04 19:38:45 --- *** Bug 18774 has been marked as a duplicate of this bug. *** --- Comment #251 from Alessandro Pedarra <alessandro.pedarra(a)inbox.com> 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 <toxmerguez(a)yahoo.fr> 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 <alessandro.pedarra(a)inbox.com> 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(a)alessandro-desktop:~/user/wine-git$ make depend make: *** Nessuna regola per creare l'obiettivo «depend». Arresto. alessandro(a)alessandro-desktop:~/user/wine-git$ (?) --- Comment #254 from sheen <toxmerguez(a)yahoo.fr> 2009-06-19 14:31:22 --- (In reply to comment #253) > I got stopped here: alessandro(a)alessandro-desktop:~/user/wine-git$ make depend > make: *** Nessuna regola per creare l'obiettivo «depend». Arresto. > alessandro(a)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 <alessandro.pedarra(a)inbox.com> 2009-06-19 16:29:18 --- (In reply to comment #254) > (In reply to comment #253) > > I got stopped here: alessandro(a)alessandro-desktop:~/user/wine-git$ make depend > > make: *** Nessuna regola per creare l'obiettivo «depend». Arresto. > > alessandro(a)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. ;) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 6971] Mouse "escapes" window or is confined to an area in the full screen program
by wine-bugs＠winehq.org 19 Jun '09

19 Jun '09

http://bugs.winehq.org/show_bug.cgi?id=6971 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jounijarvis(a)gmail.com Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson(a)Pobox.com Christoph Korn <c_korn(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |c_korn(a)gmx.de chaykin <rchayster(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|rchayster(a)gmail.com | Adrian Lüthi <adi.l(a)bluewin.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adi.l(a)bluewin.ch dlzerocool <dl.zerocool(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool(a)gmail.com Stephane Mikaty <stephane(a)mikaty.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stephane(a)mikaty.net Casey Jones <pvtpuddin(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pvtpuddin(a)gmail.com Dennis Schridde <lindevel(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lindevel(a)gmx.net Lars Blomqvist <knaprigt(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |knaprigt(a)gmail.com giovanni.nicola(a)ticino.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |giovanni.nicola(a)ticino.com Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle(a)users.sourceforge.ne | |t Alessandro Pedarra <alessandro.pedarra(a)inbox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alessandro.pedarra(a)inbox.co | |m sheen <toxmerguez(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |toxmerguez(a)yahoo.fr Danila Sentiabov <dsent.zen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dsent.zen(a)gmail.com --- Comment #234 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-03-20 10:45:03 --- *** Bug 17801 has been marked as a duplicate of this bug. *** --- Comment #235 from Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> 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 <Paul.Hampson(a)Pobox.com> 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 <legine(a)gmx.net> 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 <Paul.Hampson(a)Pobox.com> 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 <Paul.Hampson(a)Pobox.com> 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 <Paul.Hampson(a)Pobox.com> 2009-03-29 03:49:18 --- http://wiki.winehq.org/DInput has some XInput2 information. --- Comment #241 from Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> 2009-03-31 07:00:57 --- Xorg has dropped XTrap as of Xserver 1.6. http://www.x.org/wiki/Server16Branch#head-b1f125722e5fa755198eaff3e42c1cfff… --- Comment #242 from Joey Forgues Forget <Jey123456(a)gmail.com> 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 <dl.zerocool(a)gmail.com> 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 <dl.zerocool(a)gmail.com> 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 <stonej4(a)mcmaster.ca> 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 <knaprigt(a)gmail.com> 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 giovanni.nicola(a)ticino.com 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 giovanni.nicola(a)ticino.com 2009-06-04 12:38:28 --- (From update of attachment 21554) to activate WINEFORCEMOUSEWARP=yes wine proggy.exe --- Comment #249 from giovanni.nicola(a)ticino.com 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 <vitaliy(a)kievinfo.com> 2009-06-04 19:38:45 --- *** Bug 18774 has been marked as a duplicate of this bug. *** --- Comment #251 from Alessandro Pedarra <alessandro.pedarra(a)inbox.com> 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 <toxmerguez(a)yahoo.fr> 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 <alessandro.pedarra(a)inbox.com> 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(a)alessandro-desktop:~/user/wine-git$ make depend make: *** Nessuna regola per creare l'obiettivo «depend». Arresto. alessandro(a)alessandro-desktop:~/user/wine-git$ (?) --- Comment #254 from sheen <toxmerguez(a)yahoo.fr> 2009-06-19 14:31:22 --- (In reply to comment #253) > I got stopped here: alessandro(a)alessandro-desktop:~/user/wine-git$ make depend > make: *** Nessuna regola per creare l'obiettivo «depend». Arresto. > alessandro(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 6994] Crimsonland's background textures fail to render
by wine-bugs＠winehq.org 19 Jun '09

19 Jun '09

http://bugs.winehq.org/show_bug.cgi?id=6994 Danila Sentiabov <dsent.zen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dsent.zen(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 6719] Office 2000/2003 - installer ignore selected functions
by wine-bugs＠winehq.org 19 Jun '09

19 Jun '09

http://bugs.winehq.org/show_bug.cgi?id=6719 Danila Sentiabov <dsent.zen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dsent.zen(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 6971] Mouse "escapes" window or is confined to an area in the full screen program
by wine-bugs＠winehq.org 19 Jun '09

19 Jun '09

http://bugs.winehq.org/show_bug.cgi?id=6971 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jounijarvis(a)gmail.com Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson(a)Pobox.com Christoph Korn <c_korn(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |c_korn(a)gmx.de chaykin <rchayster(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|rchayster(a)gmail.com | Adrian Lüthi <adi.l(a)bluewin.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adi.l(a)bluewin.ch dlzerocool <dl.zerocool(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool(a)gmail.com Stephane Mikaty <stephane(a)mikaty.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stephane(a)mikaty.net Casey Jones <pvtpuddin(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pvtpuddin(a)gmail.com Dennis Schridde <lindevel(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lindevel(a)gmx.net Lars Blomqvist <knaprigt(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |knaprigt(a)gmail.com giovanni.nicola(a)ticino.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |giovanni.nicola(a)ticino.com Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle(a)users.sourceforge.ne | |t Alessandro Pedarra <alessandro.pedarra(a)inbox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alessandro.pedarra(a)inbox.co | |m sheen <toxmerguez(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |toxmerguez(a)yahoo.fr --- Comment #234 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-03-20 10:45:03 --- *** Bug 17801 has been marked as a duplicate of this bug. *** --- Comment #235 from Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> 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 <Paul.Hampson(a)Pobox.com> 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 <legine(a)gmx.net> 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 <Paul.Hampson(a)Pobox.com> 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 <Paul.Hampson(a)Pobox.com> 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 <Paul.Hampson(a)Pobox.com> 2009-03-29 03:49:18 --- http://wiki.winehq.org/DInput has some XInput2 information. --- Comment #241 from Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> 2009-03-31 07:00:57 --- Xorg has dropped XTrap as of Xserver 1.6. http://www.x.org/wiki/Server16Branch#head-b1f125722e5fa755198eaff3e42c1cfff… --- Comment #242 from Joey Forgues Forget <Jey123456(a)gmail.com> 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 <dl.zerocool(a)gmail.com> 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 <dl.zerocool(a)gmail.com> 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 <stonej4(a)mcmaster.ca> 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 <knaprigt(a)gmail.com> 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 giovanni.nicola(a)ticino.com 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 giovanni.nicola(a)ticino.com 2009-06-04 12:38:28 --- (From update of attachment 21554) to activate WINEFORCEMOUSEWARP=yes wine proggy.exe --- Comment #249 from giovanni.nicola(a)ticino.com 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 <vitaliy(a)kievinfo.com> 2009-06-04 19:38:45 --- *** Bug 18774 has been marked as a duplicate of this bug. *** --- Comment #251 from Alessandro Pedarra <alessandro.pedarra(a)inbox.com> 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 <toxmerguez(a)yahoo.fr> 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 <alessandro.pedarra(a)inbox.com> 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(a)alessandro-desktop:~/user/wine-git$ make depend make: *** Nessuna regola per creare l'obiettivo «depend». Arresto. alessandro(a)alessandro-desktop:~/user/wine-git$ (?) --- Comment #254 from sheen <toxmerguez(a)yahoo.fr> 2009-06-19 14:31:22 --- (In reply to comment #253) > I got stopped here: alessandro(a)alessandro-desktop:~/user/wine-git$ make depend > make: *** Nessuna regola per creare l'obiettivo «depend». Arresto. > alessandro(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 6971] Mouse "escapes" window or is confined to an area in the full screen program
by wine-bugs＠winehq.org 19 Jun '09

19 Jun '09

http://bugs.winehq.org/show_bug.cgi?id=6971 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jounijarvis(a)gmail.com Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson(a)Pobox.com Christoph Korn <c_korn(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |c_korn(a)gmx.de chaykin <rchayster(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|rchayster(a)gmail.com | Adrian Lüthi <adi.l(a)bluewin.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adi.l(a)bluewin.ch dlzerocool <dl.zerocool(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool(a)gmail.com Stephane Mikaty <stephane(a)mikaty.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stephane(a)mikaty.net Casey Jones <pvtpuddin(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pvtpuddin(a)gmail.com Dennis Schridde <lindevel(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lindevel(a)gmx.net Lars Blomqvist <knaprigt(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |knaprigt(a)gmail.com giovanni.nicola(a)ticino.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |giovanni.nicola(a)ticino.com Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle(a)users.sourceforge.ne | |t Alessandro Pedarra <alessandro.pedarra(a)inbox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alessandro.pedarra(a)inbox.co | |m sheen <toxmerguez(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |toxmerguez(a)yahoo.fr --- Comment #234 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-03-20 10:45:03 --- *** Bug 17801 has been marked as a duplicate of this bug. *** --- Comment #235 from Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> 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 <Paul.Hampson(a)Pobox.com> 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 <legine(a)gmx.net> 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 <Paul.Hampson(a)Pobox.com> 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 <Paul.Hampson(a)Pobox.com> 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 <Paul.Hampson(a)Pobox.com> 2009-03-29 03:49:18 --- http://wiki.winehq.org/DInput has some XInput2 information. --- Comment #241 from Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> 2009-03-31 07:00:57 --- Xorg has dropped XTrap as of Xserver 1.6. http://www.x.org/wiki/Server16Branch#head-b1f125722e5fa755198eaff3e42c1cfff… --- Comment #242 from Joey Forgues Forget <Jey123456(a)gmail.com> 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 <dl.zerocool(a)gmail.com> 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 <dl.zerocool(a)gmail.com> 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 <stonej4(a)mcmaster.ca> 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 <knaprigt(a)gmail.com> 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 giovanni.nicola(a)ticino.com 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 giovanni.nicola(a)ticino.com 2009-06-04 12:38:28 --- (From update of attachment 21554) to activate WINEFORCEMOUSEWARP=yes wine proggy.exe --- Comment #249 from giovanni.nicola(a)ticino.com 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 <vitaliy(a)kievinfo.com> 2009-06-04 19:38:45 --- *** Bug 18774 has been marked as a duplicate of this bug. *** --- Comment #251 from Alessandro Pedarra <alessandro.pedarra(a)inbox.com> 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 <toxmerguez(a)yahoo.fr> 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 <alessandro.pedarra(a)inbox.com> 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(a)alessandro-desktop:~/user/wine-git$ make depend make: *** Nessuna regola per creare l'obiettivo «depend». Arresto. alessandro(a)alessandro-desktop:~/user/wine-git$ (?) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 6971] Mouse "escapes" window or is confined to an area in the full screen program
by wine-bugs＠winehq.org 19 Jun '09

19 Jun '09

http://bugs.winehq.org/show_bug.cgi?id=6971 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jounijarvis(a)gmail.com Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson(a)Pobox.com Christoph Korn <c_korn(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |c_korn(a)gmx.de chaykin <rchayster(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|rchayster(a)gmail.com | Adrian Lüthi <adi.l(a)bluewin.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adi.l(a)bluewin.ch dlzerocool <dl.zerocool(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool(a)gmail.com Stephane Mikaty <stephane(a)mikaty.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stephane(a)mikaty.net Casey Jones <pvtpuddin(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pvtpuddin(a)gmail.com Dennis Schridde <lindevel(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lindevel(a)gmx.net Lars Blomqvist <knaprigt(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |knaprigt(a)gmail.com giovanni.nicola(a)ticino.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |giovanni.nicola(a)ticino.com Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle(a)users.sourceforge.ne | |t Alessandro Pedarra <alessandro.pedarra(a)inbox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alessandro.pedarra(a)inbox.co | |m sheen <toxmerguez(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |toxmerguez(a)yahoo.fr --- Comment #234 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-03-20 10:45:03 --- *** Bug 17801 has been marked as a duplicate of this bug. *** --- Comment #235 from Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> 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 <Paul.Hampson(a)Pobox.com> 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 <legine(a)gmx.net> 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 <Paul.Hampson(a)Pobox.com> 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 <Paul.Hampson(a)Pobox.com> 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 <Paul.Hampson(a)Pobox.com> 2009-03-29 03:49:18 --- http://wiki.winehq.org/DInput has some XInput2 information. --- Comment #241 from Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> 2009-03-31 07:00:57 --- Xorg has dropped XTrap as of Xserver 1.6. http://www.x.org/wiki/Server16Branch#head-b1f125722e5fa755198eaff3e42c1cfff… --- Comment #242 from Joey Forgues Forget <Jey123456(a)gmail.com> 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 <dl.zerocool(a)gmail.com> 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 <dl.zerocool(a)gmail.com> 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 <stonej4(a)mcmaster.ca> 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 <knaprigt(a)gmail.com> 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 giovanni.nicola(a)ticino.com 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 giovanni.nicola(a)ticino.com 2009-06-04 12:38:28 --- (From update of attachment 21554) to activate WINEFORCEMOUSEWARP=yes wine proggy.exe --- Comment #249 from giovanni.nicola(a)ticino.com 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 <vitaliy(a)kievinfo.com> 2009-06-04 19:38:45 --- *** Bug 18774 has been marked as a duplicate of this bug. *** --- Comment #251 from Alessandro Pedarra <alessandro.pedarra(a)inbox.com> 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 <toxmerguez(a)yahoo.fr> 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) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 6971] Mouse "escapes" window or is confined to an area in the full screen program
by wine-bugs＠winehq.org 19 Jun '09

19 Jun '09

http://bugs.winehq.org/show_bug.cgi?id=6971 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jounijarvis(a)gmail.com Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson(a)Pobox.com Christoph Korn <c_korn(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |c_korn(a)gmx.de chaykin <rchayster(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|rchayster(a)gmail.com | Adrian Lüthi <adi.l(a)bluewin.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adi.l(a)bluewin.ch dlzerocool <dl.zerocool(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool(a)gmail.com Stephane Mikaty <stephane(a)mikaty.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stephane(a)mikaty.net Casey Jones <pvtpuddin(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pvtpuddin(a)gmail.com Dennis Schridde <lindevel(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lindevel(a)gmx.net Lars Blomqvist <knaprigt(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |knaprigt(a)gmail.com giovanni.nicola(a)ticino.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |giovanni.nicola(a)ticino.com Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle(a)users.sourceforge.ne | |t Alessandro Pedarra <alessandro.pedarra(a)inbox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alessandro.pedarra(a)inbox.co | |m --- Comment #234 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-03-20 10:45:03 --- *** Bug 17801 has been marked as a duplicate of this bug. *** --- Comment #235 from Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> 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 <Paul.Hampson(a)Pobox.com> 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 <legine(a)gmx.net> 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 <Paul.Hampson(a)Pobox.com> 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 <Paul.Hampson(a)Pobox.com> 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 <Paul.Hampson(a)Pobox.com> 2009-03-29 03:49:18 --- http://wiki.winehq.org/DInput has some XInput2 information. --- Comment #241 from Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> 2009-03-31 07:00:57 --- Xorg has dropped XTrap as of Xserver 1.6. http://www.x.org/wiki/Server16Branch#head-b1f125722e5fa755198eaff3e42c1cfff… --- Comment #242 from Joey Forgues Forget <Jey123456(a)gmail.com> 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 <dl.zerocool(a)gmail.com> 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 <dl.zerocool(a)gmail.com> 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 <stonej4(a)mcmaster.ca> 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 <knaprigt(a)gmail.com> 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 giovanni.nicola(a)ticino.com 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 giovanni.nicola(a)ticino.com 2009-06-04 12:38:28 --- (From update of attachment 21554) to activate WINEFORCEMOUSEWARP=yes wine proggy.exe --- Comment #249 from giovanni.nicola(a)ticino.com 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 <vitaliy(a)kievinfo.com> 2009-06-04 19:38:45 --- *** Bug 18774 has been marked as a duplicate of this bug. *** --- Comment #251 from Alessandro Pedarra <alessandro.pedarra(a)inbox.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 18916] New: Thief 2 crashes when bringing up in-game menu
by wine-bugs＠winehq.org 19 Jun '09

19 Jun '09

http://bugs.winehq.org/show_bug.cgi?id=18916 Summary: Thief 2 crashes when bringing up in-game menu Product: Wine Version: 1.1.23 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: michael(a)araneidae.co.uk Created an attachment (id=21762) --> (http://bugs.winehq.org/attachment.cgi?id=21762) Transcript of game run, complete with backtrace After the commit below, Thief 2 crashes with the attached backtrace when bringing up the in-game menu. This menu involves switching screen resolution to 640x480. This appears to have been generated by the following commit: commit f8c4832276fb740e527fed87aa27975f91546d26 Author: Henri Verbeet <hverbeet(a)codeweavers.com> Date: Fri Jun 5 10:10:48 2009 +0200 wined3d: Use GL_DEPTH24_STENCIL8_EXT for depth stencil formats. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 22

[Bug 18895] New: Thief 3 crashes on closing.
by wine-bugs＠winehq.org 19 Jun '09

19 Jun '09

http://bugs.winehq.org/show_bug.cgi?id=18895 Summary: Thief 3 crashes on closing. Product: Wine Version: 1.1.23 Platform: PC-x86-64 URL: http://www.eidos.de/downloads/search.html?gmid=174 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: kgbricola(a)web.de Created an attachment (id=21737) --> (http://bugs.winehq.org/attachment.cgi?id=21737) Testcase to trigger the crash in d3d8. Thief 3 crashes in DeletePixelShader if it closes/release all the resources. The game deletes some resources twice and there could the crash happen. The attached test case let wine crash in the same way. (The only difference is it uses VertexShader instead of PixelShader, but the code which is responsible for the crash is shared between both). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 8