input/pointer: Support wl_pointer.warp in MotionEvent - #2137
Conversation
Being more strongly typed here seems good in general. More specifically, this should help for implementing `input-timestamps-unstable-v1`, or synthesizing events with microsecond timestamps from an event using millisecond timestamps. This change itself has no impact on what timestamps are actually sent anywhere.
In practice, we likely can and must assume `CLOCK_MONOTONIC` is used for input timestamps. And already do. Provide a helper for this. In some places this is equivalent to the code that was previously used. In others a timestamp of `0` was used, which appears to be invalid.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2137 +/- ##
==========================================
- Coverage 17.41% 17.39% -0.02%
==========================================
Files 187 187
Lines 30976 31172 +196
==========================================
+ Hits 5393 5422 +29
- Misses 25583 25750 +167
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Hm. What about cases like the new logic in ClickGrab that updates the focus start data? I guess it doesn't need any explicit handling because if the compositor changes the location of the surface without a pointer event, it will send |
Description
Based on #2108.
cosmic-compneeds to be updated with this to test properly with pointer constraints, then it needs testing inXWayland/etc. This is meant to replace themotion/relative_motioncode in pop-os/cosmic-comp@dda2d14832.As far as I understand, it should be correct to use
.motionon older versions of the protocol, and.warpon newer versions. If the.relative_pointerevent with a delta of 0 is just a workaround for the lack of a "warp" in earlier versions of the protocol, it presumably isn't necessary to send with newer versions? In which case, handling here seems appropriate.Checklist