When the same thread repeatedly calls ClipCursor, a message window is
created for every call, then stored in x11drv_thread_data->clip_hwnd.
The WM_X11DRV_CLIP_CURSOR notification is then sent to the desktop
window, then to the previous clipping thread in order for it to destroy
its clip_hwnd. But as the clipping thread is the same, and because
x11drv_thread_data->clip_hwnd has been overwritten, it does not satisfy
the "hwnd == data->clip_hwnd" condition and the window leaked.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
XWarpPointer will always succeed, regardless of grabs, so if the pointer
is already grabbed, by some other application, we should not ask to warp
it.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
As we ignore these NotifyGrab / NotifyUngrab w.r.t focus decisions,
some applications are unaware of mouse grabs being lost and sometimes
cursor clipping is lost. We have to keep the last clip rectangle and
restore it when grab is released.
This has been squashed with the foreground window check from
Zhiyi Zhang <zzhang@codeweavers.com> to fix an issue that happens when
switching from a fullscreen window - because there's some additional
focus events involved - but in general, if the window that is getting
focus cannot be activated:
When FocusIn/NotifyWhileGrabbed is received, SetForegroundWindow is not
called if the window cannot be activated. When the FocusIn/NotifyUngrab
event arrives for the same window, we have to check the foreground
window before restoring cursor clipping rectangle.
For reference, the event sequence when pressing Alt-Tab - for WMs that
grab the keyboard - is the following:
1. FocusOut/NotifyGrab, when WM grabs the keyboard.
2. FocusOut/NotifyWhileGrabbed, while WM switches windows, this calls
SetForegroundWindow(GetDesktopWindow()).
The event sequence for normal windows ends here, but for fullscreen
windows, there may be these additional events:
3. FocusIn/NotifyWhileGrabbed, which may not change Wine foreground
window if it cannot be activated.
4. FocusIn/NotifyUnGrab, when WM releases the keyboard while switching
windows, this is ignored but it should not retry to grab the cursor,
because window is not foreground.
5. FocusOut/NotifyNormal, when WM finishes switching the windows.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When the window manager has taken a keyboard grab, it may be going to
move the window itself, so the application should not move the cursor
at the same time.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of selecting for XI2 events for every slave device individually,
do it for XIAllDevices, and store the current device's relative X/Y
valuators so they can be quickly looked up in the XI_RawMotion events
received.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Use XI2's client pointer, it will be the master pointer affected by X
core calls, and even if it doesn't currently have relative X/Y
capabilities, it will gain those as soon as a slave device with such
capabilities is used.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
After processing several X events, X11DRV_MsgWaitForMultipleObjects always
tells us that a new message is available. This is not true for some cases.
For instance, when we call DestroyWindow, the X queues DestroyEvent. Then,
X11DRV_MsgWaitForMultipleObjects handles the event only; none is posted or
sent as hwnd for destroyed window is unavailable. However, the function
states "new message is available" by returning count - 1 value.
This is an issue for CoWaitForMultipleHandles because it expects a new
message in the queue and consumes the message.
Signed-off-by: Akihiro Sagawa <sagawa.aki@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We don't want to clip in the desktop process, but we still need it to call
ungrab_clipping_window() if the process that was previously clipping didn't.
This can happen for example when fullscreen clipping is enabled, but the
corresponding window isn't explicitly destroyed before process exit.
Rémi Bernon