Touchscreen clicks happen at the previously-touched location

[RavenWorks]

In a large percentage of mouse-based games that I play on Steam Deck, trying to click buttons by tapping the touch screen causes the button under my cursor's PREVIOUS location to get clicked.

As in:
- My cursor is over button A.
- I tap button B with my finger.
My cursor moves to button B, but button A responds.
- I tap button C with my finger.
My cursor moves to button C, but button B responds.
- I tap button C again.
Now button C responds (because the cursor was already there.)

It's like the Steam Deck is sending the click BEFORE it sends the new cursor coordinates.

I'm prepared to believe that the Steam Deck is doing everything correctly and that this is a flaw in the mouse handling in the individual games; but given that I've literally lost count of the number of games that this happens in, this seems like something that really needs a 'compatibility mode' in order for the touch screen to be broadly usable.

All it really needs is a checkbox somewhere to force click events to always be sent one frame after the touch begins, so the game has time to notice the new mouse coordinates first. If the touch screen were configurable like every other input is, I'd do it myself -- are there any possible workarounds? (Native touchscreen support doesn't help, at least in the games that I've tried.)

[Chromega]

As a developer, I'm encountering this as well. The click events seem to process correctly on UI, but NOT when clicking 3D actors.

I'm using Unreal 5.4. Not sure if this a bug on the deck, unreal, or my side, but I found this post and wanted to chime in with the details I have.

[deaddoof]

Originally posted by Chromega:

As a developer, I'm encountering this as well. The click events seem to process correctly on UI, but NOT when clicking 3D actors.

I'm using Unreal 5.4. Not sure if this a bug on the deck, unreal, or my side, but I found this post and wanted to chime in with the details I have.

Seems like Valve messed up input for Steam OS 3.6. Linux community is in an transition period from X11 to wayland. Desktop mode uses a x11 compositor while game mode uses a wayland one.

Since the client changes controller events to XTEST input, the game mode compositor may have issues recording user actions. As a result, libinput will not see those XTEST events and the compositor will not move the cursor. I believe you have the situation as similar as above.

https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/431#note_511868

Bazzite OS resolves the X11 transition issue with this project. I heard extest does not work with unicode chars well enough. Valve will need to revert to the old behavior until a permanent solution is found. Input is political hell.

https://github.com/Supreeeme/extest

[Chromega]

Thanks for the information. I hope this gets resolved eventually, but in the mean time I did a workaround in my Unreal project.

For other Unreal devs who might find this...I have a custom PlayerController class, and I added an override for InputKey. If I'm on steam deck and I receive a left click event, I buffer that event (so I don't immediately call Super::InputKey in that case) and then process that event later, after new mouse positions come in. It's a hack but it means my OnActorClicked events get processed with the correct mouse position.

[Qonoma]

Player here, just want to give this a bump. Been playing the Etrian Odyssey remaster, the touch screen was working like a dream, hardly even noticed I wasn't playing on a DS. Until updating steam os recently, now the touch screen is completely unusable. Something as simple as dragging a symbol onto a map is now an entire multistep process since I need to keep resetting the mouse position before I start dragging. It's frustrating enough that I'm shelving the game until it gets fixed. Do let me know if anyone finds a fix for existing games.

[The cake is a lie]

I noticed that issue too. Click can happen before move, but it is not in all circumstances. For example:
In Rungore Demo, character sélection screen works properly, but in game not anymore. Setting as Native touch does not improve.
In Into The Breach it is not working well neither, but this game supports native touch screen which works perfectly.
Dicey dungeons, mouse emulation is working fine, no touch native support at all.
Slay the spire, working only in menu. In game click is before move. Native touch does not improve.

[Terithian]

Originally posted by Qonoma:

Player here, just want to give this a bump. Been playing the Etrian Odyssey remaster, the touch screen was working like a dream, hardly even noticed I wasn't playing on a DS. Until updating steam os recently, now the touch screen is completely unusable. Something as simple as dragging a symbol onto a map is now an entire multistep process since I need to keep resetting the mouse position before I start dragging. It's frustrating enough that I'm shelving the game until it gets fixed. Do let me know if anyone finds a fix for existing games.

I am experiencing the exact same issue, first noticed in Etrian Odyssey 3 HD. The touch screen is completely unusable, significantly impacting the game's playability on Steam Deck, as the entire reason to play it on Steam Deck is so that the mapping can be controlled with the touch screen. I tried switching to the Beta update channel to see if the problem was fixed there, but then the game wouldn't even boot. The only thing keeping me from refunding the game is that I managed to modify the controller settings to make the right trackpad work as a mouse, which works decently well (though not as well as if the touch screen was actually working).

[Rybun]

Using latest version of ProtonGE works correctly.

[RavenWorks]

Which do you mean, GE-Proton8-3? Neither that or Proton Experimental are fixing it for me...

[TANKKI MÄK]

Any workarounds? Can you modify the touch screen input anywhere? If you could add delay between the coordinates and the click event it should remedy the issue?