Passed Through USB devices do not match hardware behavior

[HadetTheUndying]

Bug Description

While I was testing Steel Battalion: Line of Contact I noticed some peculiar issues.

1. Inputs appear to be getting pressed when know buttons, or keys are pressed.
2. Inputs appear to reset(flicker) or trigger the wrong inputs in the controller calibration menu
3. it also may be effecting my racing wheel as i noticed it felt like games were occasionally steering against me(Returning to center)

Video of the problem:

Uploading 2022-08-18_17-01-52.mp4… EDIT: Apparently the video did not upload here is a link to the same video I uploaded in Discord https://cdn.discordapp.com/attachments/1009927154529742879/1009946148087279626/2022-08-18_17-01-52.mp4 .

Expected Behavior

This is a video of the correct behavior on hardware. I do not believe this is a Steel Battalion specific issue because of what i mentioned with my racing wheel, however it is the only game I have that I can quickly test with.

https://user-images.githubusercontent.com/28496334/185505797-8c5bd4ca-7dfc-4c00-9534-cb5cdf6950af.mp4

xemu Version

Version: 0.7.56-15-g940bee452c Branch: master Commit: 940bee452cc34127ecf3f364c3c5f52e4e6a80a4 Date: Thu Aug 18 08:13:32 PM UTC 2022

System Information

CPU: AMD Ryzen 7 2700X Eight-Core Processor
OS Platform: Linux OS Version: Void Linux Manufacturer: AMD GPU Model: AMD Radeon RX Vega (vega10, LLVM 12.0.1, DRM 3.46, 5.18.16_1) Driver: 4.6 (Core Profile) Mesa 22.1.7 Shader: 4.60

Additional Context

I have tested this scenario in both the original and Line of Contact's calibration screens. It also causes inputs to be hit multiple times instead of just once. Could this be because I'm using a USB 3 port for my USB adapter? I only have Front panel USB, and I'm not sure if I have back panel USB 2 at all. The controller works fine and behaves correctly when using the Windows Drivers in a VM from the same port however. Could xemu not be syncing correctly?

[GXTX]

Isn't pass through disabled?

[HadetTheUndying]

Isn't pass through disabled?

You can still build with passthrough enabled. This is the only way to test Steel Battalion for example. This issue won't go anywhere unreported. I can't really speculate as to what's causing this though. The only thing that I could even think of is maybe it's a polling rate problem and possibly maybe whatever is happening with the communicator PR might be related as well.

[GXTX]

Then you didn't test with master or that git-rev.

[HadetTheUndying]

I think I had a weird issue rebasing. I'll reset against master when I'm home.

[HadetTheUndying]

Just an update, I did rebuild to master. I've also switched the USB port I'm using to be on the back panel of my system, the issue above still persists

Version:      0.7.56-15-g940bee452c
Branch:       master
Commit:       940bee452cc34127ecf3f364c3c5f52e4e6a80a4
Date:         Sun Aug 21 02:22:05 AM UTC 2022

[faha223]

I found the cause of the issue and fixed it in my usb_passthrough branch. There's a comment noting why it behaves this way in hw/usb/hcd-ohci.c on line 959 that says:

/* ??? The hardware should allow one active packet per endpoint. We only allow one active packet per controller. This should be sufficient as long as devices respond in a timely manner. */

I was able to fix this by removing the fields relating to the active packet from the OHCIState struct and putting them in a USBActivePacket struct along with a pointer to the USB Endpoint to tie each packet to their respective endpoints. Then adding a tailq of USBActivePacket structs to the OHCIState. I also had to update the code that interacts with the active packet to instead interact with the new tailq of USBActivePacket structs.

I fixed it in this commit: https://github.com/faha223/xemu/commit/da56949af17c80aafa13d090f994f5a7df504e23 see the following files: hw/usb/hcd-ohci.h hw/usb/hcd-ohci.c hw/usb/hcd-ohci-pci.c