Hi Jared,
A few avenues you can try here:
- We have a CVar LinuxApplication.EnableSimulatedMouseFromTouch that you can disable to prevent those mouse events, at which point you should *only* see the touch events in your log. I’ve tried toggling this in the past and still had issues, but it’s quick enough to test out and see if that improves things. We see similar issues with Windows touchscreens, they send both a native touch event and a simulated click (to make non-touch apps work properly) and that can cause all sorts of weird behaviors
- There are two big sources of mouse capture that you’re probably seeing- the viewport and any button widgets. The viewport will capture the cursor by default, but you can change that setting in Project Settings under “Default Viewport Mouse Capture Mode”. Other things, like setting the input mode, may adjust that setting at runtime. For button widgets, they only capture the mouse if set to “Down and Up” for their click/touch method, which we do to ensure you don’t need to remain hovered on the button between the press and the release. You can avoid that by using the other mode (Down or Precise Click/Tap).
- If capture is the culprit here then you should see the events come into LinuxApplication (with the logging mentioned before) and make it’s way through to FSlateApplication::ProcessTouchEndedEvent, at which point it’s handed off to the Mouse Up handler. If that’s not happening, perhaps something is wrong with FLinuxApplication::UpdateMouseCaptureWindow and we’re sending the event to the wrong window altogether. We should add some additional logging in there to get a better picture of what’s going on
A bit of a theory, I wonder if the synthesized mouse up event is causing capture to be released via SDL_CaptureMouse(false), and that interferes with the Finger Up event since we’ve already released capture. Hard to be sure without some hardware to test on, but that seems plausible (in which case the cvar in point 1 might help)