Touchpad Touch can cause jitter when adding a standalone Menu Cursor or Camera action

[AL2009man]

I've been closely following progress on Steam Controller 2 for sometime, and i finally got the chance to try out how it's look like in a live game.

Unfortunately: it has a problem where...simply touching the touchpad without moving will cause the cursor (and/or camera) to jump all over the place, i discovered it's more evident for Steam Controller's pressure sensitive touchpad as it doesn't properly respond to a touch until you gently push the "button".

Similar case will occur with Steam Controller OG but far less due to the driver already having a jitter filter system. Even if you went ahead and build a anti-jitter code to your gamepad code: you can't fully remove the jitter, not everyone wants to go ahead and create one themselves (which in my case, i searched around the internet for Laptop touchpad jitter references but unable to do so)

to test, i have a personal WIP build of Red Faction 1's community patch as my testbed to try out Steam Controller 2 feature to demostrate the issue, this was recorded on 5/16/2026, using existing functions before replacing/changing it.

2026-05-16.16-13-55.mp4

[slouken]

There's a reason Valve recommends using Steam Input in conjunction with the Steam Controller. :)

[Kuratius]

I think this uniquely bad for Steam Controller 2, I've noticed it misses entire events or stops reporting them when moving the finger across the touchpad. The difference to the original is very apparent to me (and I don't think this is because the original has filtering code in SDL). Maybe it's trying to pre-filter stuff in the controller's firmware and that filter is wrong. I know SDL has a touch input filter for the original controller but that doesn't explain the difference, I've checked.
If the steam client is running the same behavior appears for data it gets via SDL, but the mouse cursor movement from the controller appears as it should.

SteamController2.mp4

OriginalSteamController.mp4

In particular the right touchpad of the controller appears to be affected by this issue, it's less noticeable on the left one.
You should be able to see how the red rectangle "jumps" across keys without ever lighting up the keys in between when I move my right thumb from the bottom left to top right. On the original steam controller the keys light up correctly.
So this looks like there are dropped or missed events. Sometimes the rectangle also disappears entirely for a few frames.

[Kuratius]

SDL/src/joystick/hidapi/SDL_hidapi_steam_triton.c

Line 247 in 8b49bff

pTritonReport->sPressureLeft > 0,

maybe this is the wrong way to report a touchpad as "finger down" seeing as the report has a field for finger down so inferring it from the pressure shouldnt be necessary.

[Kuratius]

Yeah that fixes it, I'll try to send a PR.

You might want to apply this fix to the steam deck driver too, seeing as the touchpads are probably similar and it also seems to use the wrong way to detect fingers.

[Kuratius]

@AL2009man Could you build the latest master and try again with these fixes? The Steam Controller 2 touchpads seem significantly more precise than those of the original steam controller so I was hoping it would be stable enough now.
I only get movement by 1 or 2 pixels so I was assuming that's mostly due to my heartbeat.

[AL2009man]

@AL2009man Could you build the latest master and try again with these fixes? The Steam Controller 2 touchpads seem significantly more precise than those of the original steam controller so I was hoping it would be stable enough now. I only get movement by 1 or 2 pixels so I was assuming that's mostly due to my heartbeat.

Last I tested: it still cause jitter if I simply touch it without moving, however: it's much smoother than it was before

I won't be home to do another recording tho, gonna wait for a bit

[ceski-1]

Is there remaining jitter because of an actual issue or because the data is raw and unfiltered? If it's the latter, then should SDL apply smoothing to the input or is that up to the application using SDL? For comparison, it would be considered unacceptable for SDL to smooth mouse or gyro input.

[Kuratius]

The original controller reports very noisy data (probably some issue with the circuit that performs the analog to digital conversion), which is why the Linux kernel driver filters the data before sending it to userspace.
The filter ignores updates that are smaller than the noise floor of the sensor, and the moving average is tiered so larger diffs are filtered less by doing a weighted average of the old and the new value. Diffs larger than the noise floor are unfiltered.
Generally it just results in the reported position being a little behind (but not in a way that accumulates), which is more tolerable than being unable to click small buttons.
Slouken mentioned that the touchpads on the PS4 and DualSense controllers are less noisy, but I don't know if that's because the hardware is better or because the firmware of the controller already performs filtering.

[ceski-1]

Subjectively, the DualSense's touchpad feels heavily filtered with an input delay, the DualShock 4 has less filtering (slight jitter) and less input delay, followed by the Steam Controller (2026) which has a little more jitter than the DualShock 4 and has the least input delay of the three. I don't have an original Steam Controller (2015) to test.

If the plan is to filter the Steam Controller's (2026) input, then please choose the filter carefully and maybe even allow it to be configured on or off across all controller touchpads. I think adding input latency is unacceptable, and the application should have control over the filtering technique.

[Kuratius]

There might also be variation between devices. The left pad on my original controller has slightly less jitter than the right one, which to me points to a binning problem with the components they used. Binning transistors for amplifiers used to be a super big thing if you were buying from low quality fabs or lived 50 years ago.

The filter doesn't wait until it has x values to perform averaging on, it's more like a moving deadzone.
If you are moving your finger quickly it just passes through the most recent value, in which case there's no significant increase in input lag.
If the concern is for the cycles spent on doing the averaging calculation, you could probably do some inline assembler or branchless SIMD code to shorten it, but I'm not sure that's worth the effort. You could do it if you think it's fun. Even if it doesn't end up faster you'd learn enough that you might be able to make something else faster next time.

It's also probably possible to add an SDL hint to make it report raw coordinates or set the jitter value to use for filtering.

My understanding is that mouse input is usually filtered by the OS too, at least I can find references to a hysteresis filter.
https://wayland.freedesktop.org/libinput/doc/latest/touchpad-jitter.html

[AL2009man]

@AL2009man Could you build the latest master and try again with these fixes? The Steam Controller 2 touchpads seem significantly more precise than those of the original steam controller so I was hoping it would be stable enough now. I only get movement by 1 or 2 pixels so I was assuming that's mostly due to my heartbeat.

ok, got back home and I went ahead and recorded two videos, same process...but this time I included the actual camera portion. As a reminder: this is all done raw, without any sort of application-driven filters nor smoothing.

compressO-2026-05-23.16-09-46.mp4

compressO-2026-05-23.16-10-17.mp4