Prioritise mouse over touch position in osu! gameplay

[Susko3]

• Alternative to Enable mouse/pen aim + touch click play style #31704

Prioritises mouse (or pen hover) input over touch input for cursor position in osu! gameplay.

This will allow hovering pen + click with touch gameplay, with and without ppy/osu-framework#6523. Clicking with the pen still doesn't play nice with touch.

I had a problem with trying to implement isRealMouseMoveEvent() as it was difficult to filter out fake events generated for IRequireHighFrequencyMousePosition. I settled on checking whether the new event reports a position different that the state of the nested input manager (i.e. a change in position).
One would expect filtering fake events would be as easy as checking e.Delta == 0 (as high frequency events shouldn't report any), but the o!f caching of events is broken, resulting in incorrect deltas.

Testing

Tested on windows with a touchscreen monitor and vTablet (simulating windows ink). Works fine. But for this virtual tablet specifically, mouse_move_debounce_time needs to be increased as it has a low report rate.

Mixing tablet and touch input causes visual issues because the game is rapidly switching Static.TouchInputActive. A jarring example is HoldForMenuButton (could be fixed by adding easing).

[Susko3]

Ignoring touch when there is a mouse event within the last 50 ms is fine (I would increase it to 100 ms). But what's even better is to check if a pen is hovering and ignore all touch input if so. SDL provides us with SDL_EVENT_PEN_PROXIMITY_IN and SDL_EVENT_PEN_PROXIMITY_OUT, but o!f is not currently handling those events.

Could have a global bool GameHost.IsPenDetected, similar to GameHost.OnScreenKeyboardOverlapsGameWindow.

[frenzibyte]

I honestly think the entire flow here needs to be rethought with pen input in mind. I can't wrap my head around this diff either.

I'm hoping this input system becomes as simple as OsuTouchInputMapper being an actual mapper that accepts both touch and pen input as "input" and produces mouse position/button input as "output".

This is not the case in #31704 as it just handles mouse events and sets some flags indicating that suddenly mouse position should not be generated anymore.

This is not the case in this PR either as apparently this is adding a method in OsuInputManager that sets mouse position to touch based on when was the last time a mouse event was received.

It would be a more tolerable solution to add support for pen enter/leave events and handle them in OsuTouchInputMapper as an explicit "pen in screen" flag, and force positionTrackingTouch to null when this is the case.

[frenzibyte]

As per above.

[Susko3]

It would be a more tolerable solution to add support for pen enter/leave events and handle them in OsuTouchInputMapper as an explicit "pen in screen" flag, and force positionTrackingTouch to null when this is the case.

Right, so add proper pen support, the whole flow. Including pen-to-mouse, long tap to right click, be really careful with PassThroughInputManager, plus all-new event types related to pen hover. I would have the new pen events only for mobile, and keep OTD and windows ink (via SDL pen events) as mouse events.

I think I will first write the modified OsuTouchInputMapper code, to get a feel what event-handling methods need to exist on Drawable. Making a draft PR that doesn't compile but shows the logic.

I don't see this being done quickly, so I guess ppy/osu-framework#6523 should go in.

[frenzibyte]

I would have the new pen events only for mobile, and keep OTD and windows ink (via SDL pen events) as mouse events.

Ideally those should also be sent as pen events with a flag distinguishing between them and mobile pen events (i.e. indirect vs on-screen pen input). That would allow proper touchscreen support on Windows.