Distinguish between mouse and trackpad `MouseWheel` events

[liamaharon]

It would be helpful to tell whether MouseWheel events originated from a trackpad or mouse: johanhelsing/bevy_pancam#81 (comment)

This SO post seems to indicate it can be detected based on the NSEvent subtype, so there might be a potential path, at least on MacOS.

Maybe someone here knows if this is a possibility, and if so what a path forward might look like?

[kchibisov]

Isn't the goal to detect a touchpad gesture instead? Generally, on some platforms you probably can distinguish, but on the rest you can not, but you have interface to subscribe to touchpad gestures, which winit supports.

[liamaharon]

Isn't the goal to detect a touchpad gesture instead? Generally, on some platforms you probably can distinguish, but on the rest you can not, but you have interface to subscribe to touchpad gestures, which winit supports.

Hi, thanks for your amazing work especially on alacritty which I drive daily!

The touchpad gesture I think I need appears to only be available on iOS:

winit/winit-core/src/event.rs

Lines 279 to 290 in 120f21a

	/// N-finger pan gesture
	///
	/// ## Platform-specific
	///
	/// - Only available on **iOS**.
	/// - On iOS, not recognized by default. It must be enabled when needed.
	PanGesture {
	device_id: Option<DeviceId>,
	/// Change in pixels of pan gesture from last update.
	delta: PhysicalPosition<f32>,
	phase: TouchPhase,
	},

Let me know if I might be missing something? PinchGesture in contrast works great, which is labelled as available on both iOS and MacOS.

It's a shame that there's no cross-platform solution :')

[kchibisov]

I'm not sure there's a way to actually reliably detect a trackpad (I think modern mice have better precision and can also sometime report pixel deltas, but I have no idea how those exposed on macOS) and also issue a pan event.

Also, I think you can detect that based off the TouchPhase, only touch/trackpad will have a Moved state, instead of Start/End. There could still be missing bits for it, but I think that's the way to actually distinguish mouse and trackpad here. Some folks point to momentumPhase on the event as the only option to figure it out, which we use to generate TouchPhase.

So, you can try to write the logic based of TouchPhase on MouseWheel.

[liamaharon]

Thanks for your explanation and help @kchibisov. I guess it would be too unreliable/unstable to add a new field to WindowEvent::MouseWheel indicating trackpad using these methods of detection? If that's the case, I think we can close the issue.

[kchibisov]

I mean, that you have kind of have all you need to implement all you want based on the TouchPhase field already, for mouse you won't have Moved phase.

There could be something missing in the global handling of all of that, but generally, those states is how it's implemented in toolkits as well, they don't generally check for IsTrackPad or something from what I remember. Maybe on e.g. Web it's different and e.g. Windows, but generally speaking it's based off the scrolling phase, since mouse doesn't enter Moved.

[liamaharon]

Thanks, I'll try detecting based on TouchPhase. Will re-open if I have any issues or more questions!

[liamaharon]

Hey again @kchibisov, I just tested this with a physical mouse on MacOS and the TouchPhase is always Moved when I scroll. Touchpad events are the same but begin with Started and finish with Ended.

scroll_events_compressed.mp4

Let me know if you have any ideas.

[kchibisov]

Touchpad events are the same but begin with Started and finish with Ended.

So it seems like you've answered the question? You need to detect Started -> Ended cycle and all between is touchpad motion.

I just forgot which exactly is touchpad, but yeah, it seems like Started -> Ended is the pattern. There could be some state still missing though.

[liamaharon]

In browser WASM env on touchpad there is no Started and Ended, only Moved same as mouse wheel scroll.

[kchibisov]

I think that's more of a patching wasm backend issue, probably not exposed or something? There're certainly places here and there were backends behave slightly differently where they shouldn't.