Alexandros Frantzis (@afrantzis) commented about dlls/winewayland.drv/wayland_pointer.c:
if (!(hwnd = wayland_pointer_get_focused_hwnd())) return; if (!(data = wayland_win_data_get(hwnd))) return;
- if (!private) return;
- wayland_surface_coords_to_window(data->wayland_surface,
- wayland_motion_delta_to_window(data->wayland_surface, wl_fixed_to_double(dx), wl_fixed_to_double(dy),
(int *)&screen.x, (int *)&screen.y);
&screen.x, &screen.y);wayland_win_data_release(data);
d_accum->x += screen.x;
d_accum->y += screen.y;
The accum x and y are accessed in two contexts: in `wayland_pointer_update_constraint` for the zeroing, and also updated here in relative motion handler. These may be running concurrently in different threads, and since access to doubles may not be atomic we ideally need to protect the variables. Especially with the suggestion below to place them in wayland_pointer instead, it's straightforward to guard these in the relative motion handler with the wayland_pointer mutex.
Note that even with the lock, there are some Wayland event races left that are harder to resolve (e.g., Thread1: relative motion handler starts running, Thread2: zero accum and destroy relative motion, Thread1: handler updates accum), but at least we won't end up with some half-updated `double` value, and the worst case is then only a very small glitch.