diff options
author | nanahi <130121847+na-na-hi@users.noreply.github.com> | 2024-02-10 14:43:50 -0500 |
---|---|---|
committer | sfan5 <sfan5@live.de> | 2024-02-21 22:39:28 +0100 |
commit | 531704e35d9a5a4b143072d25657509138b5607c (patch) | |
tree | 2fd094884073b5b63b429f94d182a0da7ac6bf01 /video/out/x11_common.h | |
parent | d954646d29bfb7110253ea40d6ff853971425de0 (diff) | |
download | mpv-531704e35d9a5a4b143072d25657509138b5607c.tar.bz2 mpv-531704e35d9a5a4b143072d25657509138b5607c.tar.xz |
x11_common: handle window dragging in ButtonPress event
Begin the _NET_WM_MOVERESIZE window dragging in ButtonPress event
to match the behavior of win32 and wayland, simplify logic by dropping
the win_drag_button1_down hack required by the old method, and fix a race
condition described in commit 19f101db680f966a6e56035a16784541be390982,
which happens when moving the mouse and releasing the button at the same time.
The race condition can be easily triggered when using a touch screen
(tested with libinput driver), where a tap is translated to MotionNotify,
ButtonPress, MotionNotify, and ButtonRelease in sequence, with the last 2
events having the same timestamp. This has caused some window managers to
not stop dragging after the ButtonRelease, resulting in window being stuck
in dragging state after a single tap.
Diffstat (limited to 'video/out/x11_common.h')
-rw-r--r-- | video/out/x11_common.h | 3 |
1 files changed, 0 insertions, 3 deletions
diff --git a/video/out/x11_common.h b/video/out/x11_common.h index 8587c452c6..d88c8899c8 100644 --- a/video/out/x11_common.h +++ b/video/out/x11_common.h @@ -137,9 +137,6 @@ struct vo_x11_state { Atom dnd_requested_action; Window dnd_src_window; - /* dragging the window */ - bool win_drag_button1_down; - Atom icc_profile_property; }; |