[Bug 31702] New: Mouselook (raw input) is bound to a box every other click in Guild Wars 2
http://bugs.winehq.org/show_bug.cgi?id=31702 Bug #: 31702 Summary: Mouselook (raw input) is bound to a box every other click in Guild Wars 2 Product: Wine Version: unspecified Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: valczir.darkvein(a)gmail.com Classification: Unclassified The below description was copied from a comment by voidcastr on another, somewhat related bug - I feel like it does a pretty good job of explaining the problem. --- When trying to turn the view in Guild Wars 2, every SECOND time -- this is exactly reproducible -- the camera rotation (by right-clicking and dragging the mouse) stops like when the (invisible) cursor hit the edge of the screen. The other time, I can rotate the view without such a limit. These two cases literally take turns. In both of them, the cursor properly re-appears at the position I started dragging, as soon as I release the mouse button. The first rotation attempt is unlimited. --- I confirmed this with the latest Wine git as of this posting, including the latest changes to raw input (http://source.winehq.org/git/wine.git/commitdiff/54efd8a430e52d6fd8977d169bf...). -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 arthur.huillet(a)free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arthur.huillet(a)free.fr -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 Forest <winehq(a)tibit.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq(a)tibit.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.
http://bugs.winehq.org/show_bug.cgi?id=31702 Luke Bratch <l_bratch(a)yahoo.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |l_bratch(a)yahoo.co.uk -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 sworddragon2(a)aol.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sworddragon2(a)aol.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.
http://bugs.winehq.org/show_bug.cgi?id=31702 ax 34noff <otaku(a)rambler.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |otaku(a)rambler.ru -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 voidcastr <cephryx(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cephryx(a)gmx.net, | |hverbeet(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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #1 from voidcastr <cephryx(a)gmx.net> 2012-09-14 04:39:46 CDT --- (added Henri Verbeet - the author of the raw input implementation - to the CC list) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 Fernando Martins <fernando(a)cmartins.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fernando(a)cmartins.nl -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 Jordan <jordanw2(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jordanw2(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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #2 from voidcastr <cephryx(a)gmx.net> 2012-09-16 09:17:34 CDT --- To reprhase the original bug description a bit: In the problematic case, the invisible cursor simply seems to move... until it hits the edge of the screen. It goes invisible when holding down a mouse button and it properly reappears at the original position in BOTH alternating cases (the buggy and the correct one) when releasing the button. Guild Wars 2 does not use raw mouse input all the time, but only when a mouse button is held down and the mouse is moved. The game basically enters and quits raw mouse input mode. Thus, there must be some logic within wine's input system that is triggered when initializing raw input... either this logic or the one processing an actual "raw mouse move event" malfunctions preceisely every second time, not causing an expected suppression of the cursor's movement. Because this suppression always works in the first attempt, I suspect a missing reset of some variable, some kind of wrong state being set, a missing increment of a pointer, a lack of removing an event from a queue... or something like that. I already had a look into the code but to me it's not easy to identify the part responsible for this, since I do not know much about wine's input message processing and it's quite hard to figure it out from scratch / on my own. -> So... help pls! :) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 chemacg(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chemacg(a)gmail.com --- Comment #3 from chemacg(a)gmail.com 2012-09-16 10:31:56 CDT --- This is really game breaking, it can kill you in the weirdest forms when you find yourself unable to keep turning. Hope you can find any light on this matter, cheers ;) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #4 from voidcastr <cephryx(a)gmx.net> 2012-09-16 11:46:03 CDT --- Actually, the above was mainly directed towards Henri Verbeet, who implemented the raw input support in wine 1.5.13 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #5 from Henri Verbeet <hverbeet(a)gmail.com> 2012-09-16 12:25:19 CDT --- Is this specific to the current implementation, or did this also happen with the "raw3" patch? From the description it sounds like we're not enabling XI 2 in some cases when we're supposed to, but that wouldn't be specific to rawinput. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #6 from Samuel Nelson <valczir.darkvein(a)gmail.com> 2012-09-16 12:35:29 CDT --- (In reply to comment #5)
Is this specific to the current implementation, or did this also happen with the "raw3" patch? From the description it sounds like we're not enabling XI 2 in some cases when we're supposed to, but that wouldn't be specific to rawinput.
It also happened with the raw3 patch. I had noticed it in passing, but didn't have any more information than, "The mouse sometimes acts like it's bound to a box when using mouselook." When I saw voidcastr's comment, I double checked, then tested wine git - it seems to act the same in both cases. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 arthur.huillet(a)free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- CC|arthur.huillet(a)free.fr | -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #7 from voidcastr <cephryx(a)gmx.net> 2012-09-16 14:15:37 CDT --- Yep, just checked it after compiling 1.5.11-raw3: The "raw3" behavior matches the one implemented in 1.5.13. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 jonthan-vola(a)hotmail.com <jonathan-vola_tester(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan-vola_tester(a)hotmai | |l.com --- Comment #8 from jonthan-vola(a)hotmail.com <jonathan-vola_tester(a)hotmail.com> 2012-09-17 18:31:46 CDT --- I don't think this is a rawinput related bug. In fullscreen mode we see this "every other time" issue, in a vdesktop we see it every time, and in windowed we don't see it at all. Additionally, pressing keys (A full keypress not a keydown or keyup, in between camera movements) will "Reset" the counter allowing you to deliberately maintain a "Streak" of sorts. I believe the game is somehow losing focus every other time. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #9 from Samuel Nelson <valczir.darkvein(a)gmail.com> 2012-09-18 08:28:22 CDT --- (In reply to comment #8)
I don't think this is a rawinput related bug.
In fullscreen mode we see this "every other time" issue, in a vdesktop we see it every time, and in windowed we don't see it at all.
Additionally, pressing keys (A full keypress not a keydown or keyup, in between camera movements) will "Reset" the counter allowing you to deliberately maintain a "Streak" of sorts.
I believe the game is somehow losing focus every other time.
You're right, I'm seeing similar behavior. Although, pressing keyboard keys doesn't reset anything for me; pressing a mouse key seems to, as you said, sort of reset the counter - as if I had released and pressed the right mouse button. Windowed works every time, as you said - but it's strange that windowed fullscreen (or just maximizing the windowed mode) goes back to the same behavior as standard fullscreen. The entire behavior is very strange. I'm not so sure that the game is losing focus - whenever anything loses focus in my window manager, it also loses the ability to receive events, and GW2 definitely still receives key presses. That said, it needs more testing. I'll try to remember to work on it after work tonight (I'm busy, lately). -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #10 from jonthan-vola(a)hotmail.com <jonathan-vola_tester(a)hotmail.com> 2012-09-18 09:24:14 CDT ---
Windowed works every time, as you said - but it's strange that windowed fullscreen (or just maximizing the windowed mode) goes back to the same behavior as standard fullscreen.
As I understood it, all fullscreen wine programs were windowed fullscreen. I assume it must be something to do with the window state, or we wouldn't be seeing different results in the virtual desktop. I'm using xfwm4 btw. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #11 from Samuel Nelson <valczir.darkvein(a)gmail.com> 2012-09-18 09:47:43 CDT --- (In reply to comment #10)
Windowed works every time, as you said - but it's strange that windowed fullscreen (or just maximizing the windowed mode) goes back to the same behavior as standard fullscreen.
As I understood it, all fullscreen wine programs were windowed fullscreen.
I do notice differences between actual fullscreen and windowed fullscreen, though. Windowed fullscreen allows me to alt+tab to different programs; with actual fullscreen, I have to switch to a different virtual desktop if I want to use other programs (alt+tab doesn't do any switching). At least, that's how it seemed to work when I tried the different modes a couple of days ago.
I assume it must be something to do with the window state, or we wouldn't be seeing different results in the virtual desktop.
It does make sense that the bug has something to do with the window state, and it's possible that it could be losing direct focus in some sense of the word - I'm just not quite so sure just yet, personally, because e17 tends to be pretty strict about windows that don't have focus behaving very differently. Heck, I even have it set to make unfocused windows translucent, and I've never seen GW2 go translucent all of a sudden. On the other hand, though, I think e17 shuts down compositing when anything is running fullscreen. So all I'm really saying is that it doesn't work *exactly* like the game has lost focus. Maybe it loses partial focus, returns partial control of the mouse cursor to the window manager, or something like that. That would make sense. I'm planning to try a few more environments (including an empty X session) after work - I'll post back with any results. I'm not expecting much, but I am pretty sure that at least some people just don't experience this bug, based on the lack of comments we're getting about it on the AppDB - maybe the window manager has something to do with it. I might have to install *cringe* KDE or *shudder* GNOME to see if the popular DEs somehow work. On the other hand, it might just be that most people don't use mouselook constantly.
I'm using xfwm4 btw.
I'm using enlightenment DR17. Side note: are you using focus follows mouse, focus under mouse, or click to focus? I'm using focus follows mouse (i.e. the most recent window that I moused over is focused - e17 calls this "most recent window under mouse" or "sloppy" focus). Again, I'm thinking in terms of how seldom people are commenting on the issue on the AppDB, but could the issue be related to that setting? Still seems unlikely to me; it's just a thought. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #12 from jonthan-vola(a)hotmail.com <jonathan-vola_tester(a)hotmail.com> 2012-09-18 10:57:41 CDT ---
Side note: are you using focus follows mouse, focus under mouse, or click to focus? I'm using focus follows mouse (i.e. the most recent window that I moused over is focused - e17 calls this "most recent window under mouse" or "sloppy" focus).
Click to focus. I just had a thought: Technically we aren't losing focus but the game isn't resetting the cursor position (Or rawinput isn't, either way same result) This would partially explain why the vdesktop one always locks: The virtual "Window" is never being "Triggered" Also, regeditting mwo makes no difference.
I do notice differences between actual fullscreen and windowed fullscreen, though. Windowed fullscreen allows me to alt+tab to different programs; with actual fullscreen, I have to switch to a different virtual desktop if I want to use other programs (alt+tab doesn't do any switching). At least, that's how it seemed to work when I tried the different modes a couple of days ago.
Nope, not that way here, but perhaps that's just a window manager thing. It could also be if the game is specifically pulling all inputs (Like SDL) but leaving <super> alone cause I use that for alt-tab. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #13 from chemacg(a)gmail.com 2012-09-18 13:06:53 CDT --- I have KDE and i see this exact same behaviour, except when i enable virtual desktop and disable "capture mouse" then the mouse can't turn over the screen border NEVER -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 nob.dir.info(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nob.dir.info(a)gmail.com --- Comment #14 from nob.dir.info(a)gmail.com 2012-09-18 13:15:35 CDT --- What about the DXGrab option? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #15 from Forest <winehq(a)tibit.com> 2012-09-18 13:45:43 CDT --- (In reply to comment #11)
pretty sure that at least some people just don't experience this bug, based on the lack of comments we're getting about it on the AppDB
I wouldn't jump to that conclusion. The first wine source code release to include raw input support just landed a few days ago. Many users probably aren't even aware that it's available yet, let alone diligent enough to notice the phrase "raw input" in the announcement, knowledgeable enough to realize that it might solve their problem, comfortable being an early adopter of a new version, and idle enough to have time for testing games any day of the week. I love that you guys are all over this problem, but I'll bet I'm one of a very few who are aware of the progress you're making. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #16 from Samuel Nelson <valczir.darkvein(a)gmail.com> 2012-09-18 13:58:15 CDT --- (In reply to comment #15)
(In reply to comment #11)
pretty sure that at least some people just don't experience this bug, based on the lack of comments we're getting about it on the AppDB
I wouldn't jump to that conclusion. The first wine source code release to include raw input support just landed a few days ago. Many users probably aren't even aware that it's available yet, let alone diligent enough to notice the phrase "raw input" in the announcement, knowledgeable enough to realize that it might solve their problem, comfortable being an early adopter of a new version, and idle enough to have time for testing games any day of the week. I love that you guys are all over this problem, but I'll bet I'm one of a very few who are aware of the progress you're making.
I'm mainly jumping there because the bug affected the raw3 patch, which is what most of them are using - most people are either manually patching with raw3 or using PlayOn(Linux|Mac) (which downloads wine with the raw3 patch) - which, in my experience, has the same behavior. So either no one's mentioning it, there's something different about our setup, or most users just don't rely on mouselook that often. Honestly, I wouldn't be surprised if mouselook isn't used by most people. If I weren't in the minority, more games would have mouselook as a toggle instead of a held button. I've seen requests for ANet to make mouselook a setting you can turn on in the settings, so that the mouselook process is reversed - right click takes you out of mouselook instead of putting you in it. The amount of people opposed to the idea was ... frightening. I don't know how people can play MMOs without constantly using mouselook. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 ax 34noff <otaku(a)rambler.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|otaku(a)rambler.ru | -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 sl1pkn07 <sl1pkn07(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sl1pkn07(a)gmail.com --- Comment #17 from sl1pkn07 <sl1pkn07(a)gmail.com> 2012-09-19 15:24:46 CDT --- i'm use always hold-click and move mouse to move focus/direction, and have this issue (i dead more times in WvW (pvp) when have this issue) use playonlinux with 1.5.12-guildwars2 wine and older (all with raw3 patch) don't test with 1.5.13 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #18 from sl1pkn07 <sl1pkn07(a)gmail.com> 2012-09-19 17:39:14 CDT --- same in 1.5.13. but the ingame bazar don't work, back to 1.5.12-guildwars2 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #19 from voidcastr <cephryx(a)gmx.net> 2012-09-21 09:26:47 CDT --- So - what now? :) Henri, you mentioned "not enabling XI 2 in some cases"... given what was described in the above comments, could you narrow down the potential causes of the issue? As far as I understand, the raw input implementation is not necessarily bugged but it is likely to somehow correlate with an existing bug... how could that one be solved and what kind of data (log, testing, ...) can we provide in order to help? And what is this "XI 2" at all? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #20 from Henri Verbeet <hverbeet(a)gmail.com> 2012-09-21 10:57:04 CDT --- (In reply to comment #19)
Henri, you mentioned "not enabling XI 2 in some cases"... given what was described in the above comments, could you narrow down the potential causes of the issue? As far as I understand, the raw input implementation is not necessarily bugged but it is likely to somehow correlate with an existing bug... how could that one be solved and what kind of data (log, testing, ...) can we provide in order to help?
And what is this "XI 2" at all?
X Input 2, it's what we use for getting relative mouse input. Without that you'd stop getting mouse input once the cursor reaches the edges of the screen or the cursor clipping rect. See also enable_xinput2(), disable_xinput2(), and related code in dlls/winex11.drv/mouse.c. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 Julian Rüger <jr98(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98(a)gmx.net -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #21 from voidcastr <cephryx(a)gmx.net> 2012-09-23 01:14:23 CDT --- Thanks for the hints. I will investigate the issue over the next few days, adding lots of traces and comparing cases, and report back here as soon as I found something. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 Anthony Mattheakakis <antony256(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |antony256(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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #22 from voidcastr <cephryx(a)gmx.net> 2012-09-23 11:16:01 CDT --- Based on the current git, I was able to narrow the problem down to dlls/winex11.drv/mouse.c:504. The observed behavior of "every second time the mouse is bound" etc. was a misinterpretation and subject to the player's individual rate of click-dragging in order to turn the camera. This is also the reason why only few players reported this bug. More details on this in the "long version" below. --------------------------- TL/DR version: - from dlls/winex11.drv/mouse.c, remove line 504 --OR-- change the "1000" it contains to "10" - the original line is: "if (GetTickCount() - thread_data->clip_reset < 1000) return FALSE;" - recompile wine - check if this fix works for you --------------------------- Long version (primarily interesting for Henri): In dlls/winex11.drv/mouse.c, BOOL clip_fullscreen_window( HWND, BOOL ) sometimes fails to call static BOOL grab_clipping_window( const RECT ) which activates XI 2, which is required for raw input, which is used for GW2's mouse look. This is because the condition in line 504 if (GetTickCount() - thread_data->clip_reset < 1000) return FALSE; is "sometimes" fulfilled, causing the method to return early. In all cases, both GetTickCount() and thread_data->clip_reset contain sensible values (i.e. they are never zero). Their difference is just sometimes too small which results in occasionally returning FALSE. The mentioned condition seems to be nothing more than a way of "throttling" possible calls to grab_clipping_window: The calculated difference basically represents the time passed since the last clipping reset operation (let's call it like that). GetTickCount() thereby must be something similar to "the time the application is running". Now it gets interesting: A clipping reset operation seems to be triggered when pressing or releasing a mouse button. Thus, "1000" is the number of milliseconds that must have passed after releasing a mouse button that was pressed in order to trigger raw input, before grab_clipping_window can be called again by pressing the mouse button once more. In GW2, this corresponds to "turning the camera", "releasing the mouse button" and then "immediately turning the camera again" -- and for many players it is not uncommon to do this in a succession faster than 1000 ms. As expected, simply removing the line (504) seems to solve the problem for Guild Wars 2. An alternative persists in significantly lowering the original value of "1000". I tried various values there, and for me "10" (ms) was a convenient number I can never go below between two clicks (while 15 was still too high when trying really hard). After removing or adjusting the line as described, I can now turn the camera in Guild Wars 2 without any constaint. Though the removal or change of the above check does not seem to cause new problems, I can't tell yet if it breaks something for another application. Sadly, I don't possess another one using raw input. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #23 from sworddragon2(a)aol.com 2012-09-23 12:28:53 CDT ---
Now it gets interesting: A clipping reset operation seems to be triggered when pressing or releasing a mouse button. Thus, "1000" is the number of milliseconds that must have passed after releasing a mouse button that was pressed in order to trigger raw input, before grab_clipping_window can be called again by pressing the mouse button once more.
This is the problem here. I don't think that any mouse input should be throttled in a way which can negative affect the user. Reducing the time (even just to 10 milliseconds) would be more like a hackish way of solving this problem. I would prefer a clean solution which doesn't even theoretically cause this problem. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #24 from Henri Verbeet <hverbeet(a)gmail.com> 2012-09-23 12:38:12 CDT --- (In reply to comment #22)
Now it gets interesting: A clipping reset operation seems to be triggered when pressing or releasing a mouse button. Thus, "1000" is the number of milliseconds that must have passed after releasing a mouse button that was pressed in order to trigger raw input, before grab_clipping_window can be called again by pressing the mouse button once more.
What causes the WM_X11DRV_CLIP_CURSOR? Is it the application changing the cursor clipping rect with ClipCursor()? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #25 from voidcastr <cephryx(a)gmx.net> 2012-09-23 17:56:36 CDT --- (In reply to comment #23)
This is the problem here. I don't think that any mouse input should be throttled in a way which can negative affect the user. Reducing the time (even just to 10 milliseconds) would be more like a hackish way of solving this problem. I would prefer a clean solution which doesn't even theoretically cause this problem.
Absolutely. But in the case being at hand (GW2), it looks like completely removing the throttling solves the initial problem. Nevertheless, I suppose it's in there for a specific reason, and doing so might break other applications... though I really can't figure out what reason that might be. If and only if the throttling turns out to be obsolete or something, removing it would evidently be a clean solution; but that remains to be proven. (In reply to comment #24)
(In reply to comment #22) What causes the WM_X11DRV_CLIP_CURSOR? Is it the application changing the cursor clipping rect with ClipCursor()?
I don't know yet -- gonna investigate this tomorrow. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #26 from voidcastr <cephryx(a)gmx.net> 2012-09-24 02:48:12 CDT --- As far as I can tell, "ClipCursor( NULL );" is only called when quitting the game. Concerning WM_X11DRV_CLIP_CURSOR being sent from mouse.c with SendMessageW or SendNotifyMessageW, I made the following observations: When moving the mouse WITHOUT pressing a button, ungrab_clipping_window() is triggered on every mouse move event, causing WM_X11DRV_CLIP_CURSOR to get spammed via SendMessageW. Right when pressing a mouse button (and not yet moving the mouse), grab_clipping_window(RECT) is called, sending WM_X11DRV_CLIP_CURSOR with SendMessageW. When moving the mouse with a button held down, WM_X11DRV_CLIP_CURSOR is never sent. When releasing a mouse button, ungrab_clipping_window() sends WM_X11DRV_CLIP_CURSOR with SendMessageW. Subsequently, as expected from the comments, clip_cursor_notify(HWND, HWND) is called sending WM_X11DRV_CLIP_CURSOR with SendNotifyMessageW. I don't know how to interpret this behavior. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #27 from Henri Verbeet <hverbeet(a)gmail.com> 2012-09-24 04:12:22 CDT --- (In reply to comment #26)
As far as I can tell, "ClipCursor( NULL );" is only called when quitting the game.
Concerning WM_X11DRV_CLIP_CURSOR being sent from mouse.c with SendMessageW or SendNotifyMessageW, I made the following observations:
When moving the mouse WITHOUT pressing a button, ungrab_clipping_window() is triggered on every mouse move event, causing WM_X11DRV_CLIP_CURSOR to get spammed via SendMessageW.
Right when pressing a mouse button (and not yet moving the mouse), grab_clipping_window(RECT) is called, sending WM_X11DRV_CLIP_CURSOR with SendMessageW.
When moving the mouse with a button held down, WM_X11DRV_CLIP_CURSOR is never sent.
When releasing a mouse button, ungrab_clipping_window() sends WM_X11DRV_CLIP_CURSOR with SendMessageW. Subsequently, as expected from the comments, clip_cursor_notify(HWND, HWND) is called sending WM_X11DRV_CLIP_CURSOR with SendNotifyMessageW.
I don't know how to interpret this behavior.
I think we're mostly interested in what behaviour in the application causes all the resets. ungrab_clipping_window() is only called from a couple of places: X11DRV_ClipCursor(), and X11DRV_WindowPosChanged() and X11DRV_FocusOut() through reset_clipping_window(). The latter two seem unlikely, though it would be good to verify. The first one suggests the application calling ClipCursor(). If the application is indeed calling ClipCursor() on mouse moves, we'd like to know what rectangle it's using, and if that rectangle changes. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #28 from voidcastr <cephryx(a)gmx.net> 2012-09-24 05:02:15 CDT --- The call of ungrab_clipping_window() getting spammed on moving the mouse is the one at the bottom of X11DRV_ClipCursor(LPCRECT). The upper call in the same method is executed once every time a previously pressed mouse button gets released. With "rectangle changes" you refer to the LPCRECT given to X11DRV_ClipCursor, right? That one remains constant. I added this trace to the end of the method, right before the call of ungrab_clipping_window(): TRACE( "clip (left/right/top/bottom): %u %u %u %u\n", clip->left, clip->right, clip->top, clip->bottom ); Result: clip (left/right/top/bottom): 0 1920 0 1080 all the time. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #29 from Henri Verbeet <hverbeet(a)gmail.com> 2012-09-24 05:19:29 CDT --- (In reply to comment #28)
clip (left/right/top/bottom): 0 1920 0 1080
all the time. And 1920x1080 is also the size of your screen, right? Why doesn't it return in "if (EqualRect( clip, &clip_rect ) || clip_fullscreen_window( foreground, TRUE )) return TRUE;"? The ClipCursor(NULL) call on releasing a mouse button may be a problem as well, but lets figure this one out first.
-- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #30 from voidcastr <cephryx(a)gmx.net> 2012-09-24 05:36:57 CDT --- Yep, my resolution is 1920x1080. The line with if (EqualRect( clip, &clip_rect ) || clip_fullscreen_window( foreground, TRUE )) is not even reached because the above data && data->clip_hwnd yields false. This is because !data->clip_hwnd . -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #31 from Henri Verbeet <hverbeet(a)gmail.com> 2012-09-24 05:52:03 CDT --- (In reply to comment #30)
This is because !data->clip_hwnd . Is that always the case? It would get set to NULL by ungrab_clipping_window(), but after a successful call to clip_fullscreen_window() (grab_clipping_window()) it's supposed to be non-NULL.
-- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #32 from voidcastr <cephryx(a)gmx.net> 2012-09-24 07:21:02 CDT --- This is really getting nasty... Investigating X11DRV_ClipCursor led to the following results: When pressing a mouse button (activating raw input), the method seems to get triggered twice: 1. it calls ungrab_clipping_window() and returns because GetWindowThreadProcessId( GetDesktopWindow(), NULL ) == GetCurrentThreadId() 2. it returns because EqualRect( clip, &clip_rect ) || clip_fullscreen_window( foreground, TRUE ) ...so data->clip_hwnd is non-NULL then. When moving the mouse with the button pressed, X11DRV_ClipCursor is not called. When releasing the mouse button (disabling raw input), to following happens in the given order: 1. X11DRV_ClipCursor returns because EqualRect( clip, &clip_rect ) || clip_fullscreen_window( foreground, TRUE ) ...so data->clip_hwnd is still non-NULL. 2. it calls ungrab_clipping_window() and then returns because !clip 3. it returns because GetWindowThreadProcessId( GetDesktopWindow(), NULL ) == GetCurrentThreadId() 4. the method runs to its end and triggers ungrab_clipping_window() because !data->clip_hwnd When then moving the mouse without a button pressed, the following two cases constantly take turns (this matches the steps #3 and #4 from above): 1. the method returns because GetWindowThreadProcessId( GetDesktopWindow(), NULL ) == GetCurrentThreadId() 2. the method runs to its end and triggers ungrab_clipping_window() because !data->clip_hwnd Thus, your assumption
It would get set to NULL by ungrab_clipping_window() seems to be correct.
Furthermore, I added traces to the end of all returns in grab_clipping_window, like if(!data->clip_hwnd) TRACE("bad clip_hwnd\n"); but they never occur. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #33 from Henri Verbeet <hverbeet(a)gmail.com> 2012-09-24 07:59:16 CDT --- Created attachment 41812 --> http://bugs.winehq.org/attachment.cgi?id=41812 patch Right, so the ClipCursor(NULL) when the mouse button is released disables clipping, and then it stays disabled because ClipCursor() is called so often. Does the attached patch make it any better? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #34 from Samuel Nelson <valczir.darkvein(a)gmail.com> 2012-09-24 08:37:17 CDT --- (In reply to comment #33)
Created attachment 41812 [details] patch
Right, so the ClipCursor(NULL) when the mouse button is released disables clipping, and then it stays disabled because ClipCursor() is called so often. Does the attached patch make it any better?
That attachment appears (from about one minute of testing) to work. I'm getting ready for work, though, so I can't test very thoroughly. If no one else has done any testing by the time I get back home, I'll play for a while and try to break it. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #35 from voidcastr <cephryx(a)gmx.net> 2012-09-24 08:49:19 CDT --- (In reply to comment #33)
Created attachment 41812 [details] patch
Right, so the ClipCursor(NULL) when the mouse button is released disables clipping, and then it stays disabled because ClipCursor() is called so often. Does the attached patch make it any better?
Seems like we got it: Apparently the patch solves the actual issue for all common cases. Tough I only played a couple of minutes so far, but I don't suppose it will somehow stop working. Nevertheless, the bug can still be triggered in an unusual scenario (I only came across this by chance): 1. start up the application 2. switch to another workspace, away from the application 3. switch back to the workspace the application runs in 4. trying to turn the camera within 1000 ms from the point in time (2.) was triggered causes the bug 5. it recovers for any subsequent attempts so the cam an once more be turned normally This is not remotely critical, but it might hint to some other misc bug. The hardcoded "1000" is still around and either this threshold or the underlying issue might eventually become a problem for some practical scenario/application (though I cannot figure out one right now). -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #36 from voidcastr <cephryx(a)gmx.net> 2012-09-24 08:50:35 CDT --- (ignore the link in the above post; must have been bugzilla's link autodetection failing) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #37 from voidcastr <cephryx(a)gmx.net> 2012-09-26 06:48:58 CDT --- I have now played several hours with this patch -- no problems at all. I would consider the issue fixed and recomment sendint it to wine-patches... the misc bug described above is most likely somewhat related, but fixing it is not worth the trouble, IMO. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #38 from sworddragon2(a)aol.com 2012-09-26 07:40:13 CDT --- The mouse is not reacting up to 1 second after restoring the game, this should not be a big problem. Maybe we should open a new ticket for this including all information we have gained here. Maybe the simplest solution is really just to remove the threshold then. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #39 from voidcastr <cephryx(a)gmx.net> 2012-09-26 12:47:29 CDT --- Well, apparently there are several causes triggering the observed behavior... but one of them is not eliminated. Thus, we have a functional patch. It is not perfect, but it is also not just a hack. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #40 from voidcastr <cephryx(a)gmx.net> 2012-09-26 14:59:25 CDT --- ..."now eliminated"* -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #41 from sworddragon2(a)aol.com 2012-09-26 15:08:12 CDT --- What exactly is now eliminated. Or do you mean that now all cases are working fine? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #42 from sworddragon2(a)aol.com 2012-09-26 15:09:38 CDT --- Edit: Ah, this is some sort of edit you have done to your last post. It is a little annoying that we can't directly edit our posts. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 hash <HASH.DuOrden(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |HASH.DuOrden(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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #43 from voidcastr <cephryx(a)gmx.net> 2012-09-26 16:04:35 CDT --- Yep, sorry I was just correcting the typo which turned my comment #39 into the contrary to what I actually meant :-/ Anyway, Henri, do you think it's possible to get this patch merged? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #44 from voidcastr <cephryx(a)gmx.net> 2012-09-28 11:41:28 CDT --- Now fixed in current git. 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |73d68c5a31b972a24dab39b036a | |5d3197edb3565 Status|UNCONFIRMED |RESOLVED Resolution| |FIXED --- Comment #45 from Bruno Jesus <00cpxxx(a)gmail.com> 2012-09-28 11:59:26 CDT --- (In reply to comment #44)
Now fixed in current git. Thanks!
Fixed. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #46 from sworddragon2(a)aol.com 2012-09-28 12:13:22 CDT --- What about the rare conditions? Shall now a new ticket be created? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #47 from Alexandre Julliard <julliard(a)winehq.org> 2012-09-28 13:43:41 CDT --- Closing bugs fixed in 1.5.14. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #48 from sl1pkn07 <sl1pkn07(a)gmail.com> 2012-10-11 15:55:48 CDT --- regression in GIT. this bug appears in 32bits, in 64bits works. the git version test is 1f876a670e60464b4a39de2382c533782179172f -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #49 from voidcastr <voidcastr(a)gmail.com> 2012-10-11 16:53:18 CDT --- Still works for me with wine 32bit, same git version you're using. Do you have libxi6:i386 installed? Ubuntu x64 nvidia 304.51 wine32 xfwm4.10 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #50 from sl1pkn07 <sl1pkn07(a)gmail.com> 2012-10-11 16:56:44 CDT --- yes, is installed and reinstalled sl1pkn07(a)sL1pKn07 aplicaciones $ yaourt libxi 1 extra/libxi 1.6.1-1 [installed] X11 Input extension library .... 3 multilib/lib32-libxi 1.6.1-1 [installed] X11 Input extension library (32-bit) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #51 from sl1pkn07 <sl1pkn07(a)gmail.com> 2012-10-11 19:53:37 CDT --- i emove all wine stuff related (include POL config and prefix) and build wine GIT like http://wiki.winehq.org/Wine64 include awe+screenshot patches. create 2 prefix one per arch (32 and 64) all working, include this bug very sorry for the inconvenience :S (seriously, all my issues make me crazy :S) greetings -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 Anthony Mattheakakis <antony256(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|antony256(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.
http://bugs.winehq.org/show_bug.cgi?id=31702 rmlipman(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rmlipman(a)gmail.com --- Comment #52 from rmlipman(a)gmail.com 2012-10-14 20:43:04 CDT --- @sl1pkn07 I'm not getting any mouselook working as of 1.5.15. The commit you mentioned is in 1.5.15 so is this that regression causing the mouselook not working at all? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #53 from rmlipman(a)gmail.com 2012-10-14 21:13:51 CDT --- (In reply to comment #52)
@sl1pkn07 I'm not getting any mouselook working as of 1.5.15. The commit you mentioned is in 1.5.15 so is this that regression causing the mouselook not working at all?
My bad, I was accidentally running an older version. Mouselook works for me in 1.5.15. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #54 from Forest <winehq(a)tibit.com> 2013-02-01 12:33:42 CST --- I have two Guild Wars 2 installations, one in a 32-bit wine prefix and one in a 64-bit prefix. When I run the 32-bit one, mouselook pretty much works as expected. When I run the 64-bit one, mouselook gets stuck about where my pointer would hit the screen borders. Can anyone suggest a fix? This is an amd64 Xubuntu system with libxi6 and libxi6:i386 installed. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=31702 Oded <oded(a)geek.co.il> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |oded(a)geek.co.il --- Comment #55 from Oded <oded(a)geek.co.il> --- (In reply to Forest from comment #54)
When I run the 64-bit one, mouselook gets stuck about where my pointer would hit the screen borders.
Same here, though I use a single Guild Wars 2 installation, and run it either with the system's 64bit Wine 1.7.45 installation or with a PlayOnLinux 32bit Wine 1.7.46 installation - with the system's mouselook raw input fails and is bound to the screen area, while with the 32bit setup works fine. Using Fedora 22 64bit -- 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.
https://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #56 from Forest <winehq(a)tibit.com> --- (In reply to Oded from comment #55) Oded, have you tried the patch from bug 33479? It's now in wine-staging as well. https://github.com/wine-compholio/wine-staging/tree/master/patches/server-Cl... -- 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.
https://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #57 from Oded <oded(a)geek.co.il> --- (In reply to Forest from comment #56)
Oded, have you tried the patch from bug 33479? It's now in wine-staging as well.
My 64bit installation is 1.7.45-staging (sorry for misleading previously), in which I have the mouselook broken. I'll update once I get 1.7.46-staging. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=31702 --- Comment #58 from Oded <oded(a)geek.co.il> --- (In reply to Oded from comment #57)
(In reply to Forest from comment #56)
Oded, have you tried the patch from bug 33479? It's now in wine-staging as well.
My 64bit installation is 1.7.45-staging (sorry for misleading previously), in which I have the mouselook broken.
I've tried this with the wine-staging build from https://copr.fedoraproject.org/coprs/griever/wine-staging/ , and the problem does not appear when using that, on an x86_64 system. I'm not sure when 1.7.46 staging will land in official Fedora 22 repos, I'll update if I have more information. -- 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.
participants (1)
-
wine-bugs＠winehq.org