L trigger gets stuck held when playing Soul Calibur with Redream + Demul

[multigamesystem]

When pressing the L trigger button while using Redream and playing Soul Calibur the L trigger gets stuck held until you reset the game or close the emulator. Here is a video recreating the bug.

https://youtu.be/HHU5TVLXMjk?si=yc71App9An33cQ1G

[ErykDarnowski]

Hey I think I encountered something similar.

In my case I tried to map some inputs in an emulator but every time I tried to remap something, one of the triggers would force itself in as it acted like it was constantly depressed (a state different than idle).

I took a look at the inputs in the Control Panel (like you did) and got the same weird behavior (like in your YouTube video). Later I compared how the triggers acted to an Xbox 360 controller and noticed that they didn't start from the left (0%), but from the middle (50%) of the bar instead. That's when I decided to implement a quick fix and did this.

Ohh, but something worth mentionting is that I don't think I've managed to fix the behavior that happens when you try to Calibrate the controller in the Control Panel (but in my case that wasn't an issue as my fix sufficed).

[multigamesystem]

The problem seems to not be a an issue with Retroarch oddly or at least I have noticed it being an issue when testing for the behavior with Soul Calibur. Hopefully someone figures out a fix for this.

[ErykDarnowski]

Ohhh...
Well, sorry to say I have no idea how Retroarch behaves with it (I just run my emulators on Windows).
I may test it when I have some free time however.

[ErykDarnowski]

Ahh! My bad, I thought Retroarch was a Linux distro, but now I've learned that it's just a program.
But, if that's the case, then the issue should persist 🤔.

[Tails86]

Possibly an interaction with USB HID controller somewhere in the OS or Retroarch?

To give a bit more context, here is where the value gets loaded into the USB interface. Then here is where the value is saved to the descriptor. This is using tiny USB's definition for HID controller here which limits the value between 0x81 and 0x7f. The host is supposed to recognize the first value as a 2's compliment negative value, so -127 to 127 should be what it recognizes the range as.

It could possibly be because something starts to interpret this signed value incorrectly. It would be possible to define a new USB descriptor with a 0 to 255 range instead.

[Tails86]

Showing the raw value on the calibration screens in the Windows gamepad tool provide the expected values. I tried Soul Calibur in Redream and wasn't able to reproduce.

I tried setting logical min/max to 0 to 255, but that caused more compatibility issues. I instead tried updating the minimum value from -127 to -128 and pushed that - it better correlates to Dreamcast mapping anyway. Maybe that will help? The Windows calibration tool is still jumpy, so I get the feeling there is some bug in Windows code.

[multigamesystem]

Showing the raw value on the calibration screens in the Windows gamepad tool provide the expected values. I tried Soul Calibur in Redream and wasn't able to reproduce.

I tried setting logical min/max to 0 to 255, but that caused more compatibility issues. I instead tried updating the minimum value from -127 to -128 and pushed that - it better correlates to Dreamcast mapping anyway. Maybe that will help? The Windows calibration tool is still jumpy, so I get the feeling there is some bug in Windows code.

Could you link me to the updated .uf2 to test?

[Tails86]

I published a new release with separate 4p and 1p variants
https://github.com/OrangeFox86/DreamcastControllerUsbPico/releases/tag/v0.13