Rumble lags behind or does not stop (BLE firmware)

[kakra]

Here's a rumble packet in btmon using the c_hidraw test

< ACL Data TX: Handle 16 flags 0x00 dlen 15                  #1 [hci0] 9.440042
      ATT: Write Request (0x12) len 10
        Handle: 0x0022
          Data: 0f1414281e050503
> HCI Event: Number of Completed Packets (0x13) plen 5       #2 [hci0] 9.562554
        Num handles: 1
        Handle: 16
        Count: 1
> ACL Data RX: Handle 16 flags 0x02 dlen 5                   #3 [hci0] 9.577123
      ATT: Write Response (0x13) len 0

And I've attached the rumble test btmon log from Rise of The Tomb Raider (outside of Steam using Wine Staging) where I saw the extended rumble effect btmon-rumble-test-2.txt

Originally posted by @EwokExile in https://github.com/atar-axis/xpadneo/issues/315#issuecomment-1060007749

[kakra]

@julian-barske Thanks for confirming the rumble issue, it looks like 0x0B22 is behaving differently then... I'm still not sure what is causing it.

Could try if changing the rumble throttle delay helps?

• https://github.com/atar-axis/xpadneo/blob/4fd620cd6cb80fb0c1490dc1c864108679d91ab1/hid-xpadneo/src/xpadneo.h#L69

Try setting it to 100ms instead of 10ms. This will certainly modify how rumble feels as it will be reprogrammed only once per 100ms. If it helps, try going to 50ms, then 25ms... You get the idea.

[julian-barske]

50 feels good to me. At 40, the issue was noticable, 45 felt a bit weird and 50 was OK (maybe a little bit of lag but I might just be focusing on it too much).

[kakra]

Thanks, that's a useful hint. I'll investigate that once I got the firmware update. Until then you can test that for a while and report back.

The throttler works this way:

When a rumble command is sent, the next rumble command will be buffered (overriding what ever was in the buffer before, it's not a queue) until 10ms have passed (or 50ms in your case). That means, the first rumble after at least 10ms will play at once but updates to the rumble will be in 10ms intervals - which can explain the lag you are feeling with 50ms. 50ms is only 20 Hz. The controller firmware works with around 100 Hz internally, so we used 10ms. It's also what the Windows driver seems to use.

Linux force feedback emulation via rumble works with 20 Hz, so if a game uses that API, it will match the 50 ms you set exactly. 45 ms may be weird because it is an awkward offset from 50 ms.

IOW, anything that doesn't evenly divide by 10 or 50 will probably feel weird.

[EwokExile]

50 feels like a pretty good spot here as well. Not getting the continuous rumble.

Is there a different interaction happening for the initial connection? That still does the pattern twice (not that it matters if games are good, just curious)

[EwokExile]

Upon further testing it appears that the rumble pattern repeating itself on initial connection is a separate issue. I can get it to happen reliably on the first connection I make with the controller (1708 on 5.13 firmware). What happens is the controller will do the rumble pattern twice, and will stay connected, but testing with evtest there is nothing from the select button.

If I disconnect and re-connect the controller the pattern only happens once and the select button works as expected

[hadicharara]

If I disconnect and re-connect the controller the pattern only happens once and the select button works as expected

For me, whenever I first connect the controller and the select button doesn't work, the share button acts as the select button instead.

[kakra]

For me, whenever I first connect the controller and the select button doesn't work, the share button acts as the select button instead.

This probably means, your model requires the Share button quirk. The fix should be in master, and will also be queued for the v0.9 branch.

[hadicharara]

I just checked, and unfortunately, I have compiled the latest xpadneo from master, so I don't think the fix did it. Any logs I might send to help?

[kakra]

@hadicharara Please open a new bug report for this and provide evtest results...

[kakra]

50 feels good to me. At 40, the issue was noticable, 45 felt a bit weird and 50 was OK (maybe a little bit of lag but I might just be focusing on it too much).

I've updated all my controllers to the 5.x firmware versions, and rumble works just fine. I think you observation may be related to Bluetooth device latency settings in bluez. Could you check https://github.com/atar-axis/xpadneo/blob/master/docs/TROUBLESHOOTING.md#high-latency-or-lost-button-events-with-bluetooth-le and report back?

[julian-barske]

I've updated all my controllers to the 5.x firmware versions, and rumble works just fine. I think you observation may be related to Bluetooth device latency settings in bluez. Could you check https://github.com/atar-axis/xpadneo/blob/master/docs/TROUBLESHOOTING.md#high-latency-or-lost-button-events-with-bluetooth-le and report back?

I set these Bluetooth LE settings, rebooted and changed the XPADNEO_RUMBLE_THROTTLE_DELAY back to 10. Didn't help, same problem, still have to set it to 50.

[k9bbzJavftZaqAqSW3dY]

I can confirm, bluetooth LE settings had no effect, but the jiffies 50msec setting fixed it. It's easy to reproduce this with DiRT rally 2.0, because the rumble events are stacking up ridiculously quickly (drive 10 seconds, get 30 seconds rumble). I fixed it conveniently by modifying the AUR PKGBUILD file, adding: sed -i 's/msecs_to_jiffies(10)/msecs_to_jiffies(50)/g' hid-xpadneo/src/xpadneo.h

[kakra]

We should identify which models are affected because I cannot reproduce it here. It looks like multiple effects from ff-memless may be running concurrent but technically that should not be possible because we serialize all effects in the driver.

[kakra]

I set these Bluetooth LE settings, rebooted

I wonder if the controller needs to be removed and re-paired if those settings were changed. The settings may be persisted in the device cache... Maybe give it a try.

[kakra]

I think I can reproduce it with one model, I'll need to check the others.

[k9bbzJavftZaqAqSW3dY]

i'm on model 1708.

[kakra]

Looks like all models updated to firmware 5.13 show the problem.

[EwokExile]

I've encountered the problem with both 1708 and 1914 models