fix(hid): discard raw-XY jump artifacts from the gesture button/panel

[obvionaoe]

Gesture button/panel raw-XY reports occasionally carry an absolute-position jump instead of a delta, at any point in a hold, not only the first sample after contact — the existing discard covered the first sample only, and specifically for HAPTIC_PANEL_CID. On real MX Master 4 hardware the jump has been observed reported under the mechanical gesture button's CID instead, several samples into an otherwise-clean hold, with magnitudes into the tens of thousands versus a few hundred for an entire deliberate swipe — summed into the accumulator, a jump like that commits a bogus direction (or the wrong axis entirely) before real motion is ever read.

Replace the CID-scoped, first-sample-only discard with a plain magnitude sanity check applied to every raw-XY sample of a hold, regardless of source CID: raw-XY reports carry no CID attribution on the wire, so the jump is a wire-level artifact of this control family, not something to special-case per control. Verified on real MX Master 4 hardware (Bluetooth) with an instrumented build logging every raw-XY sample: recorded contact-jump magnitudes from ~300 up to ~9700 units, consistently discarded by this fix with zero false positives against deliberate swipes in a 60+ gesture mixed test session (left/right/up/ down/click).

Likely related to #349, #426 and #752.

[greptile-apps]

Greptile Summary

This PR replaces the haptic-panel-specific first-sample discard with a device-family-wide magnitude filter that rejects implausibly large raw-XY samples throughout a gesture hold.

• Adds a 250-unit per-axis jump threshold.
• Applies artifact filtering to every raw-XY sample regardless of source control.
• Removes the prior gesture-source edge bookkeeping and first-sample flag.

Confidence Score: 5/5

The PR appears safe to merge based on the reviewed gesture-capture paths and documented hardware measurements.

The new filter preserves ordinary gesture deltas while rejecting the measured jump artifacts throughout a hold, and no reachable supported input was found that violates the selected threshold.

Important Files Changed

Filename	Overview
crates/openlogi-hid/src/session/gesture.rs	Reworks raw-XY artifact rejection to use an unconditional magnitude threshold; no concrete defect was established in the changed behavior.

_{Reviews (1): Last reviewed commit: "fix(hid): discard raw-XY jump artifacts ..." | Re-trigger Greptile}

[AprilNEA]

Thanks for taking the time to investigate this on real MX Master 4 hardware and capture the raw samples. The observation that these jumps can occur in the middle of a hold is especially useful, and I agree that filtering them before they reach SwipeAccumulator is the right layer. The existing first-sample-only handling clearly does not cover the case you observed.

I have one concern that I think we should address before merging: 250 is a fixed raw-count cutoff applied to every sample from every gesture source and device. The relationship between raw counts and physical movement depends on the configured DPI, so a threshold validated with one device setting may not generalize to higher DPI settings or other supported devices.

For example, at 8000 DPI and roughly 125 Hz, 251 counts represents only about 0.8 mm of movement in one report, or around 10 cm/s. That seems reachable during a legitimate fast swipe. The filter could therefore undercount valid movement and, in the worst case, let the release resolve as a click.

Could we make the bound DPI-aware, or otherwise avoid applying a device-independent raw-count cutoff globally? I would also prefer to preserve the existing first-sample safeguard unless the replacement can be shown to cover it reliably.

A few focused regression cases would help us validate the final approach:

• a jump occurring several samples into a hold;
• normal motion continuing after the jump;
• legitimate fast movement at the device’s highest DPI;
• boundary and release behavior;
• both Haptic Panel and mechanical gesture-button holds, where practical.

It would also be helpful to note the DPI used for the current 60+ gesture test and, if possible, include a few sample sequences captured at both low and high DPI.

Thanks again for the hardware investigation — this looks like a real device quirk, and the traces you collected give us a very useful starting point.