[PR #415] [CLOSED] fix: negate macOS scroll delta to match wl_pointer/libei sign #408

New issue

Closed

opened 2026-05-05 22:18:26 -06:00 by gitea-mirror · 0 comments

gitea-mirror commented

2026-05-05 22:18:26 -06:00

Owner

📋 Pull Request Information

Original PR: https://github.com/feschber/lan-mouse/pull/415
Author: @jondkinney
Created: 4/23/2026
Status: ❌ Closed

Base: main ← Head: fix/macos-scroll-sign

📝 Commits (1)

bb17cf0 fix: negate macOS scroll delta to match wl_pointer/libei sign

📊 Changes

1 file changed (+8 additions, -4 deletions)

View changed files

📝 input-capture/src/macos.rs (+8 -4)

📄 Description

Summary

macOS CGEvent scroll deltas use the opposite sign convention from wl_pointer.axis (and the libei capture backend used on Linux hosts). On macOS, a positive delta means "content moves up" (finger-up gesture under natural scrolling), while on Wayland a positive axis value means "scroll-down direction". The wire protocol value was therefore landing on the sink with the sign flipped relative to what other capture backends produce, so scrolling felt backwards whenever the source machine was macOS.

This normalizes the sign at capture time in input-capture/src/macos.rs so the wire protocol stays source-agnostic — both continuous (trackpad/Magic Mouse point-delta) and line-based (mouse-wheel) scroll values are negated to match wl_pointer/libei semantics.

Before / after

Before: scrolling from a macOS source with another lan-mouse client on Linux (wlroots emulation backend) scrolled the opposite direction from what the user gestured on the Mac.
After: gesture direction on macOS matches content direction on the Linux sink, identical to behavior with a libei/Linux source.

Test plan

Tested locally with a Mac (Dygma Defy + Magic Trackpad) as the source and an Arch + Hyprland host (wlroots sink) as the target. Scroll direction now matches gesture direction on both machines.
Would appreciate confirmation from another macOS user that direction feels correct with both natural-scroll on and off in System Settings.
Line-based (non-continuous) scroll path is negated symmetrically; no test environment with a PS/2-style wheel mouse on Mac to verify, but the change is trivially the same sign flip applied to the V120_STEPS_PER_LINE * v calculation.

Notes

The fix deliberately lives in the macOS capture path rather than on the emission side, so the wire format stays consistent with what the libei capture backend already produces. No sink-side change is needed and Linux→Linux scrolling is unaffected.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/feschber/lan-mouse/pull/415 **Author:** [@jondkinney](https://github.com/jondkinney) **Created:** 4/23/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/macos-scroll-sign` --- ### 📝 Commits (1) - [`bb17cf0`](https://github.com/feschber/lan-mouse/commit/bb17cf0399d4fb68f03461ff2e0727cc781ca676) fix: negate macOS scroll delta to match wl_pointer/libei sign ### 📊 Changes **1 file changed** (+8 additions, -4 deletions) <details> <summary>View changed files</summary> 📝 `input-capture/src/macos.rs` (+8 -4) </details> ### 📄 Description ## Summary macOS CGEvent scroll deltas use the opposite sign convention from `wl_pointer.axis` (and the libei capture backend used on Linux hosts). On macOS, a positive delta means "content moves up" (finger-up gesture under natural scrolling), while on Wayland a positive axis value means "scroll-down direction". The wire protocol value was therefore landing on the sink with the sign flipped relative to what other capture backends produce, so scrolling felt backwards whenever the source machine was macOS. This normalizes the sign at capture time in ``input-capture/src/macos.rs`` so the wire protocol stays source-agnostic — both continuous (trackpad/Magic Mouse point-delta) and line-based (mouse-wheel) scroll values are negated to match wl_pointer/libei semantics. ### Before / after - **Before**: scrolling from a macOS source with another lan-mouse client on Linux (wlroots emulation backend) scrolled the opposite direction from what the user gestured on the Mac. - **After**: gesture direction on macOS matches content direction on the Linux sink, identical to behavior with a libei/Linux source. ## Test plan - [x] Tested locally with a Mac (Dygma Defy + Magic Trackpad) as the source and an Arch + Hyprland host (wlroots sink) as the target. Scroll direction now matches gesture direction on both machines. - [ ] Would appreciate confirmation from another macOS user that direction feels correct with both natural-scroll on and off in System Settings. - [ ] Line-based (non-continuous) scroll path is negated symmetrically; no test environment with a PS/2-style wheel mouse on Mac to verify, but the change is trivially the same sign flip applied to the ``V120_STEPS_PER_LINE * v`` calculation. ## Notes The fix deliberately lives in the macOS capture path rather than on the emission side, so the wire format stays consistent with what the libei capture backend already produces. No sink-side change is needed and Linux→Linux scrolling is unaffected. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>