[APP BUG]: Controller touchpad not responding properly

[morten71]

Checklist

• I have searched for a similar issue in this repository and did not find one.
• I am using an official build obtained from releases or updated one of those builds using its in-app updater.

Describe the Bug

After commit c4bfaa6 with the new input mapping system, my controller touchpad stopped responding in Bloodborne, ie. clicking on it now did nothing, either on the left side or the right side.

This happens both when I build the main branch myself, and when I use the latest AppImage (I'm using linux).

After messing around with the code a bit, and inserting some debug output, it looks like the problem is somewhere around this:

In the WaitEvent function in src/sdl_window.cpp line 304 for every SDL event of the types SDL_EVENT_GAMEPAD_BUTTON_DOWN, SDL_EVENT_GAMEPAD_BUTTON_UP, or SDL_EVENT_GAMEPAD_AXIS_MOTION, 23 (or sometimes 24) new State objects get added to the controller's state object ring buffer. I believe that is only supposed to be one state object for each of those events?

The 23 state objects come from the iteration over output_array in src/input/input_handler.cpp line 669. It results in 17 (or sometimes 18) calls to GameController::CheckButton, and 6 calls to GameController::Axis, both of which add a state object.

Since my PS4 controller triggers constant SDL_EVENT_GAMEPAD_AXIS_MOTION events, with small variations inside the dead zones, that ends up being a huge number of state objects, with the ring buffer being entirely taken up by just 3 of those SDL events.

If I add these lines to the beginning of the WaitEvent function at line 315 in src/sdl_window.cpp just before the switch block:

if (event.type == SDL_EVENT_GAMEPAD_AXIS_MOTION) {
	if (std::abs(event.gaxis.value) < 5000)
		return;
}

This gets rid of all the deadzone SDL_EVENT_GAMEPAD_AXIS_MOTION events before they ever reach the input code, and it makes Bloodborne react to my controller touchpad clicks again. It fixes nothing of course. There are still 23 state objects being added to the ring buffer, for every one SDL gamepad event. But it seems like it prevents the touchpad clicks from being drowned out.

Even with this "non-fix", there is still something weird with the detection of touchpad clicks. Now clicking the right side of the touchpad works reliably, bringing up the quick slot bar in Bloodborne, but clicking the left side is just as likely to bring up the quick slot bar, as the gesture menu, depending on where you touched the touchpad last, before clicking.

I am surprised nobody else has reported this, and that makes me think I may have gotten something very wrong, and that I am the only one seeing this problem. I just really can't figure out how that could be, so I hope this doesn't waste anybody's time.

I can attach a shad_log.txt file of course, but I don't think it makes much sense, since none of the relevant info seems to get logged.

Reproduction Steps

Start Bloodborne, and try to bring up the quick slot bar, or the gesture menu, by clicking the right or left side of the controller touchpad.

Expected Behavior

The quick slot bar or the gesture menu should appear.

Specify OS Version

Gentoo Linux

[morten71]

Here is the shad_log.txt file anyway, from when I run the Pre-release-shadPS4-2025-02-03-8ad6505 AppImage version, in case it could be useful:

shad_log.txt.zip

[kalaposfos13]

This is a very well put together issue, thank you! I added a noise filter to axis inputs, and made it so outputs are only updated if they changed compared to their previous state over here: https://github.com/kalaposfos13/shadPS4/tree/remap-fix-input-overload
I remember adding conditional output updating to the code (you can see that there are some remnants of it in the merged PR), but also reverting it, though I don't remember why I had to revert it, so I'll not PR this change until I make sure this doesn't introduce any issues, but it's late for me now, so I'll only finish it tomorrow.
The problems with the touchpad are not caused by my PR, though, that's in the emulator for quite some time now (see #1342 for that)

[morten71]

Thanks! I'll test your new version tomorrow. It's also bed time here :-)

[sam20112011]

This is a very well put together issue, thank you! I added a noise filter to axis inputs, and made it so outputs are only updated if they changed compared to their previous state over here: https://github.com/kalaposfos13/shadPS4/tree/remap-fix-input-overload I remember adding conditional output updating to the code (you can see that there are some remnants of it in the merged PR), but also reverting it, though I don't remember why I had to revert it, so I'll not PR this change until I make sure this doesn't introduce any issues, but it's late for me now, so I'll only finish it tomorrow. The problems with the touchpad are not caused by my PR, though, that's in the emulator for quite some time now (see #1342 for that)

Confirmed. I noticed that yesterday, too.

Regarding the problem #1342, I will duplicate it here just in case:

This is not an emulator issue. It's a bug in the game itself from the PS4. I don't know if it was there originally or appeared with updates up to the GOTY edition, but it is. The game somehow reads the touchpad sensor touch and “freezes” the further input presses.

How reproduce the bug: Put left thumb on the left side touchpad (but do not press it) and press right thumb on the right side touchpad. From this moment the whole touchpad will be read as a single button (right side). Unfreeze the input as follows - put the right finger on the right side and press the left finger on the left side. The right side input will be triggered, but subsequent presses on the left side will trigger the left side input.

[sam20112011]

#2346 this is fix issue, if no regressions in other games.

[morten71]

Yes I can confirm, the pull request fixes the bug for me too 👍