DualSense feedback stuck if there are many inputs

[Jobima1st]

in GTA V E if I drift using R2 + L2 and use the left stick to control the tires and then suddenly I release all buttons, the haptics will continues for more than 1 second at least, and that in both usb and bt, direct usb (without PadForge) of DualSense is fine

the log using usb
padforge-trace.log

[hifihedgehog]

@Jobima1st Two defects, both corrected on the development branch for the next build.

PadForge keeps a mapped DualSense's lightbar and LEDs in step with a frame of its own thirty times a second. While a game drives the pad, that frame repeats the game's rumble values. It repeated them with PadForge's own rumble mode bits rather than the game's. GTA V Enhanced uses the original emulation bit alone, so the pad was switched between two emulations thirty times a second. The frame now carries the game's own bits.

The second defect is the one that leaves the motors running. PadForge only recorded rumble from frames that set a rumble bit. A game can stop rumble by sending a frame with the rumble bits cleared, which is how SDL and games built on it do it. After such a frame PadForge kept the last nonzero motor values and kept sending them, first for its 1.5-second mirror window and then from the virtual pad's motor state until the game rumbled again. Direct USB is unaffected because the game's own frame stops the pad. PadForge now treats that frame as the stop it is.

Your trace records the first game frame only, so the exact frame the game sends when you let go is not in it. The next build records every rumble start and stop the game sends (lines beginning with DS5MIRROR in the diagnostics log). The response of the pad's firmware to a frame with the rumble bits cleared is taken from SDL's stop, not measured here.

[Jobima1st]

thanks! now its just harder to trigger it (not fully fixed I think)

padforge-trace.log

this time I used BT, I will try with usb later soon

[Jobima1st]

same thing with usb
padforge-trace usb.log

btw, there are other way to trigger it, which is taping "X" and running towards a speeding car to make it hit you

[hifihedgehog]

@Jobima1st The build you ran recorded what the game sends: a rumble frame and a trigger frame back to back every 10 ms, the trigger frame carrying zero motor bytes without the motor flag, and the same pair with the motors at zero when an effect ends. PadForge's forwarding lane kept one pending frame per slot and let a newer frame replace an older one, so when the game's final zero-motor rumble frame arrived a fraction of a millisecond before its trigger frame, the zero could be discarded and the pad never received the stop. Whether that happened depended on timing, which is why it became rarer rather than gone. The lane logic is the same on USB and Bluetooth.

On the bench with your frame pattern, forcing that timing left the pad rumbling 4.1 seconds after the game stopped on that build, until PadForge's own next lighting frame reached the pad without the rumble flag.

The next build merges a frame that arrives while one is waiting by the report's valid flags, so the pad gets every field the game asserted and the zero-motor stop always goes out. It also writes the physical pad directly instead of through SDL's rumble thread. With the same forced timing the pad now stops within 0.4 seconds in every cycle, which is the pad's own ramp-down.

Corrected on the development branch for the next build.

[Jobima1st]

seems perfect now! thanks!