[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: [e-mail]
        ReportedBy: [e-mail]
    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...).

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

[e-mail] changed:

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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

Forest  changed:

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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

Luke Bratch  changed:

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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

[e-mail] changed:

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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

ax 34noff  changed:

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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

voidcastr  changed:

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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #1 from voidcastr  2012-09-14 04:39:46 CDT ---
(added Henri Verbeet - the author of the raw input implementation - to the CC
list)

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

Fernando Martins  changed:

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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

Jordan  changed:

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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #2 from voidcastr  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! :)

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

[e-mail] changed:

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

--- Comment #3 from [e-mail] 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 ;)

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #4 from voidcastr  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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #5 from Henri Verbeet  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #6 from Samuel Nelson  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

[e-mail] changed:

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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #7 from voidcastr  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

[e-mail]  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jonathan-vola_tester@hotmai
                   |                            |l.com

--- Comment #8 from [e-mail]  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #9 from Samuel Nelson  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).

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #10 from [e-mail]  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #11 from Samuel Nelson  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #12 from [e-mail]  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #13 from [e-mail] 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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

[e-mail] changed:

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

--- Comment #14 from [e-mail] 2012-09-18 13:15:35 CDT ---
What about the DXGrab option?

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #15 from Forest  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #16 from Samuel Nelson  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

ax 34noff  changed:

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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

sl1pkn07  changed:

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

--- Comment #17 from sl1pkn07  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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #18 from sl1pkn07  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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #19 from voidcastr  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?

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #20 from Henri Verbeet  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

Julian Rüger  changed:

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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #21 from voidcastr  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

Anthony Mattheakakis  changed:

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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #22 from voidcastr  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #23 from [e-mail] 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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #24 from Henri Verbeet  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()?

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #25 from voidcastr  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #26 from voidcastr  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #27 from Henri Verbeet  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #28 from voidcastr  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #29 from Henri Verbeet  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #30 from voidcastr  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 .

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #31 from Henri Verbeet  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #32 from voidcastr  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #33 from Henri Verbeet  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?

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #34 from Samuel Nelson  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #35 from voidcastr  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).

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #36 from voidcastr  2012-09-24 08:50:35 CDT ---
(ignore the link in the above post; must have been bugzilla's link
autodetection failing)

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #37 from voidcastr  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #38 from [e-mail] 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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #39 from voidcastr  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #40 from voidcastr  2012-09-26 14:59:25 CDT ---
..."now eliminated"*

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #41 from [e-mail] 2012-09-26 15:08:12 CDT ---
What exactly is now eliminated. Or do you mean that now all cases are working
fine?

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #42 from [e-mail] 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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

hash  changed:

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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #43 from voidcastr  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?

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #44 from voidcastr  2012-09-28 11:41:28 CDT ---
Now fixed in current git. Thanks!

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

Bruno Jesus  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
      Fixed by SHA1|                            |73d68c5a31b972a24dab39b036a
                   |                            |5d3197edb3565
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #45 from Bruno Jesus  2012-09-28 11:59:26 CDT ---
(In reply to comment #44)
> Now fixed in current git. Thanks!

Fixed.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #46 from [e-mail] 2012-09-28 12:13:22 CDT ---
What about the rare conditions? Shall now a new ticket be created?

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #47 from Alexandre Julliard  2012-09-28 13:43:41 CDT ---
Closing bugs fixed in 1.5.14.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #48 from sl1pkn07  2012-10-11 15:55:48 CDT ---
regression in GIT. this bug appears in 32bits, in 64bits works. the git version
test is 1f876a670e60464b4a39de2382c533782179172f

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #49 from voidcastr  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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #50 from sl1pkn07  2012-10-11 16:56:44 CDT ---
yes, is installed and reinstalled
sl1pkn07@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)

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #51 from sl1pkn07  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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

Anthony Mattheakakis  changed:

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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

[e-mail] changed:

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

--- Comment #52 from [e-mail] 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?

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #53 from [e-mail] 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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

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

--- Comment #54 from Forest  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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

https://bugs.winehq.org/show_bug.cgi?id=31702

Oded  changed:

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

--- Comment #55 from Oded  ---
(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

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

https://bugs.winehq.org/show_bug.cgi?id=31702

--- Comment #56 from Forest  ---
(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...

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

https://bugs.winehq.org/show_bug.cgi?id=31702

--- Comment #57 from Oded  ---
(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.

[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

https://bugs.winehq.org/show_bug.cgi?id=31702

--- Comment #58 from Oded  ---
(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.