Commits on Source (11)
-
On systems with ACPI but disabled APM (e.g. --disable-linux-apm) the code does not compile due to preprocessor directives. If APM is disabled, the final return statement is considered to be part of ACPI's last if-statement, leading to a function which has no final return statement at all. I have refactored the code so ACPI and APM are independent of each other. Signed-off-by:Tobias Stoeckmann <tobias@stoeckmann.org>
9890e912 -
89f42b88
-
9937183e
-
Signed-off-by:Christopher Chavez <chrischavez@gmx.us>
462beb53 -
Martin Weber authored9bf33bab
-
Alan Coopersmith authoredMostly http->https conversions, but also replaces gitweb.fd.o with gitlab.fd.o, and xquartz.macosforge.org with xquartz.org. Signed-off-by:Alan Coopersmith <alan.coopersmith@oracle.com>
a5151f58 -
Olivier Fourdan authored
If a client issues a grab on the pointer while the cursor is on another X11 window, and then hides the cursor, we may end up locking the pointer onto that other window. Then a button click might end up moving the focus away from the window which issued the grab, leaving the whole setup in a mixed up state. Typically, if the pointer is on another X11 window, we should not try to lock the pointer, so that it can be moved back to the window which actually issues the grab (and hence the pointer confinement). Typically, this is the same as an X11 client issuing a pointer grab while the cursor is on another Wayland native window. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Closes: xorg/xserver#962 Reviewed-by:
Carlos Garnacho <carlosg@gnome.org> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net>
5929b789 -
Olivier Fourdan authored
When an X11 client has an active grab on the pointer, all events are reported relative to the window with the grab. For Xwayland, if an X11 client has a grab with a pointer confinement active, while pointer focus is on another window, motion events should not be reported to the client with the grab, because that sets the X11 client appart, the events would be reported when the pointer is on any X11 window but not on Wayland native surfaces. Therefore, if the pointer is confined on a window and that window differs from the actual pointer focus window, just pretend we lost pointer focus to another window. Signed-off-by:
1345f804 -
Olivier Fourdan authored
When an X11 client issues a ConfinePointer wit ha hidden cursor, Xwayland may translate that as a pointer lock. However, if the pointer is located on another window at the time, the request may be ignored, even if the pointer later enters the window. To avoid that issue, check again if locking the pointer with a hidden cursor is needed when pointer enters a surface. Signed-off-by:
baa8d12e -
Olivier Fourdan authored
xwl_seat_maybe_lock_on_hidden_cursor() checks that the value of cursor_confinement_window is not NULL, yet there is no code path that could lead to this. Remove the test for cursor_confinement_window being set, it's useless. Signed-off-by:
f486e2fd -
In this pretty Wine/Proton specific kludge, we try to handle confining grabs on InputOnly windows by trying to find the InputOutput window that the pointer would get visually confined to. The grabbing window and the visible window come from different clients, so we used to simply resort to the pointer focus. This is troublesome though, as the call may happen very soon at a time that the toplevel wasn't yet mapped by the Wayland compositor, so the pointer focus may well be out of date soon. In these situations, it does seem that even though the confining grab happens too early to have the wayland surface mapped, the xserver view of the WindowPtr does already reflect the size. Use this to find out the better window to assign the confining grab to, one whose geometry fully contains the InputOnly window's. Signed-off-by:
0777cf46
