This is an automated email from the git hooks/post-receive script.
git pushed a commit to branch wl/browser-all
in repository enlightenment.
View the commit online.
commit a2b44ee94712568879f23444ce4b6ebbdb84a224
Author: Cedric BAIL <[email protected]>
AuthorDate: Tue Aug 18 19:17:30 2026 -0600
e_comp_wl - report unaccelerated relative motion, not zero
zwp_relative_pointer_v1.relative_motion carries the movement twice: with
pointer acceleration applied, and again without it, so a client that
wants raw device movement - a game, a 3D viewer, anything that turns a
camera - can have it. E sent the accelerated pair and hard-coded the
other to 0.
That is not "unknown", it is a claim that the device did not move. A
client using the unaccelerated values, which is the whole reason they are
separate, gets nothing.
Nothing on this path applies acceleration - the deltas arrive from the
backend already in screen pixels - so the two pairs are equal here.
Found by taking a workaround out of the test harness rather than by
reading the code. wl_test had been passing the correct unaccelerated
deltas itself since E-20, which is how wlcs
RelativePointer.relative_pointer_gets_movement passed: the harness was
quietly supplying a number E never sends. That is the exact failure mode
the rule about harness changes exists to prevent, and it survived because
the workaround was written into the harness in the same session the test
started passing.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01FtoiXoSKUmZb6Aix6U3GZS
---
src/bin/e_comp_canvas.c | 12 +++++++++++-
src/modules/wl_test/e_mod_main.c | 3 +++
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/src/bin/e_comp_canvas.c b/src/bin/e_comp_canvas.c
index 2bdb19fdb..3522bb28d 100644
--- a/src/bin/e_comp_canvas.c
+++ b/src/bin/e_comp_canvas.c
@@ -341,8 +341,18 @@ _e_comp_cb_mouse_move(void *d EINA_UNUSED, int t EINA_UNUSED, Ecore_Event_Mouse_
{
if ((!e_comp->screen) || (!e_comp->screen->relative_motion))
{
+ /* Unaccelerated is the same delta, not zero.
+ *
+ * zwp_relative_pointer_v1 asks for the motion with pointer
+ * acceleration applied and again without it, so a client that
+ * wants raw device movement - a game, a 3D viewer - can have it.
+ * Nothing on this path applies acceleration: the deltas arrive
+ * from the backend already in screen pixels. Reporting 0 was
+ * therefore not "we do not know", it was a claim that the device
+ * did not move, and a client believing it never turns the
+ * camera. */
e_comp_wl_extension_relative_motion_event(ecore_time_unix_get() * 1000ULL,
- ev->x - x, ev->y - y, 0, 0);
+ ev->x - x, ev->y - y, ev->x - x, ev->y - y);
}
x = ev->x, y = ev->y;
if (e_comp_wl_extension_pointer_constraints_update(e_client_focused_get(), ev->x, ev->y))
diff --git a/src/modules/wl_test/e_mod_main.c b/src/modules/wl_test/e_mod_main.c
index 01387d2d7..b3d60eb68 100644
--- a/src/modules/wl_test/e_mod_main.c
+++ b/src/modules/wl_test/e_mod_main.c
@@ -335,6 +335,9 @@ _wl_test_cb_zone_add(struct wl_client *client EINA_UNUSED, struct wl_resource *r
static int _posted_x, _posted_y;
static Eina_Bool _posted_pending = EINA_FALSE;
+/* Defined further down with the rest of the pointer helpers. */
+static void _pointer_xy_get(int *x, int *y);
+
static void
_pointer_xy_now(int *x, int *y)
{
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
