summaryrefslogtreecommitdiffstats
path: root/video/out/x11_common.h
diff options
context:
space:
mode:
authornanahi <130121847+na-na-hi@users.noreply.github.com>2024-02-10 14:43:50 -0500
committersfan5 <sfan5@live.de>2024-02-21 22:39:28 +0100
commit531704e35d9a5a4b143072d25657509138b5607c (patch)
tree2fd094884073b5b63b429f94d182a0da7ac6bf01 /video/out/x11_common.h
parentd954646d29bfb7110253ea40d6ff853971425de0 (diff)
downloadmpv-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.h3
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;
};