Project

General

Profile

Actions

Emulator Issues #12052

closed

DSU client - Dolphin doesn't separate each pad motion input

Added by joaorb64 over 4 years ago. Updated over 4 years ago.

Status:
Working as intended
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

Game Name?

All

What's the problem? Describe what went wrong.

Dolphin lists the correct number of "DSUClient/X/Generic Gamepad" inputs, but if there's more than one controller it captures all controllers' motion (from all DSU controllers) and applies it to all Dolphin emulated wiimotes.

So, if there are 2 controllers and controller 2 is rotated, Dolphin applies this rotation to both controller 2 and controller 1.

What steps will reproduce the problem?

Open Dolphin and a DSU server.
Connect 2 motion-enabled controllers through DSU.
On Dolphin, set 2 emulated wiimotes, one for each DSU slot/device.
While on the input config menu, it's already visible that both controllers' motion inputs are affecting the accelerometer/gyro input preview, even though only one DSU controller is assigned as the input source.

Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.

Yes, 5.0-11843. Self-built.

Is the issue present in the latest stable version?

Yes, 5.0

What are your PC specifications? (CPU, GPU, Operating System, more)

Linux OS - Ubuntu 19.10

Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)

I'm using a DSU server I'm developing myself. If I run my DSU server and cemuhook's pad test via wine, each controller's motion data is correctly used on each port, so it seems like the server itself is working fine, so it might be a bug related to input on Linux or the DSU client itself.

Actions #1

Updated by joaorb64 over 4 years ago

Reports testing with a Dolphin windows build via wine:

  • The same issue occurs. With 2 controllers, both motions and buttons are used on all DSU controllers
  • I noticed gyro inputs are about 1/4 of the amount Cemuhook's PadTest detects, which is another bug on itself
Actions #2

Updated by iwubcode over 4 years ago

joaorb64 wrote:

Reports testing with a Dolphin windows build via wine:

  • The same issue occurs. With 2 controllers, both motions and buttons are used on all DSU controllers
  • I noticed gyro inputs are about 1/4 of the amount Cemuhook's PadTest detects, which is another bug on itself

Untested but just eyeballing the code, I think I can confirm this issue and see the problem. I'll take a stab at confirming / possibly fixing this tomorrow or over the weekend. Whatever the outcome, I'll report back here once done.

As for the gyro inputs, I can't say. I do know I was seeing larger values in Dolphin/Citra for my custom DSU but then realized it was a bug in my implementation for Dolphin (see PR 8747 if interested). But this specific issue might be a better choice for Billiard. Regardless, I'd suggest you open another defect so we can track it separately.

Actions #3

Updated by joaorb64 over 4 years ago

iwubcode wrote:

joaorb64 wrote:

Reports testing with a Dolphin windows build via wine:

  • The same issue occurs. With 2 controllers, both motions and buttons are used on all DSU controllers
  • I noticed gyro inputs are about 1/4 of the amount Cemuhook's PadTest detects, which is another bug on itself

Untested but just eyeballing the code, I think I can confirm this issue and see the problem. I'll take a stab at confirming / possibly fixing this tomorrow or over the weekend. Whatever the outcome, I'll report back here once done.

As for the gyro inputs, I can't say. I do know I was seeing larger values in Dolphin/Citra for my custom DSU but then realized it was a bug in my implementation for Dolphin (see PR 8747 if interested). But this specific issue might be a better choice for Billiard. Regardless, I'd suggest you open another defect so we can track it separately.

After further testing and exploring I noticed this other bug was a bug in my DSU server, sorry about that. Still, the original reported issue applies, as you also confirmed.

Actions #4

Updated by iwubcode over 4 years ago

Please try https://github.com/dolphin-emu/dolphin/pull/8804 and see if that resolves your issue.

Actions #5

Updated by iwubcode over 4 years ago

iwubcode wrote:

Please try https://github.com/dolphin-emu/dolphin/pull/8804 and see if that resolves your issue.

My apologies, please ignore the above link (not sure how to delete posts). I did have a potential fix but there's a more appropriate solution that will need to be implemented.

Actions #6

Updated by rlnilsen over 4 years ago

I'm the author of the code in question. After looking at the code again, I think it should be correct, assuming the connected UDP Server handles requests for data from individual controllers like DS4Windows does. That is, responding with data from only the requested controller.

Source: https://github.com/Ryochan7/DS4Windows/blob/c9210c41bebcf8ec4562ff8126d0c7b798d667d3/DS4Windows/DS4Control/UdpServer.cs#L611-L613.

Assuming the DSU Server @joaorb64 has tested with is https://github.com/joaorb64/joycond-cemuhook, it handles requests for data from individual controllers differently, by responding with data from all connected controllers.

Source: https://github.com/joaorb64/joycond-cemuhook/blob/2a6a243e8af0c2ba64bbc0c8197ec961bed7c570/joycond-cemuhook.py#L304-L306.

This document https://v1993.github.io/cemuhook-protocol/ seems to support the DS4Windows way:
"Actual controllers data - When you get this type of message, no instant response is required. Instead, you should begin or continue sending data from requested controller to this server." (my emphasis).

The reason cemuhook's PadTest worked correctly with @joaorb64's DSU Server may be because
PadTest requests data from all connected controllers at once, in stead of individually.

Actions #7

Updated by mbc07 over 4 years ago

I haven't thoroughly tested this issue, but indeed I couldn't reproduce it while testing PR 8804. I used multiple servers simultaneously (one of them had two controllers connected to it) and every controller reported still responded with its own data...

Actions #8

Updated by joaorb64 over 4 years ago

rlnilsen wrote:

I'm the author of the code in question. After looking at the code again, I think it should be correct, assuming the connected UDP Server handles requests for data from individual controllers like DS4Windows does. That is, responding with data from only the requested controller.

Source: https://github.com/Ryochan7/DS4Windows/blob/c9210c41bebcf8ec4562ff8126d0c7b798d667d3/DS4Windows/DS4Control/UdpServer.cs#L611-L613.

Assuming the DSU Server @joaorb64 has tested with is https://github.com/joaorb64/joycond-cemuhook, it handles requests for data from individual controllers differently, by responding with data from all connected controllers.

Source: https://github.com/joaorb64/joycond-cemuhook/blob/2a6a243e8af0c2ba64bbc0c8197ec961bed7c570/joycond-cemuhook.py#L304-L306.

This document https://v1993.github.io/cemuhook-protocol/ seems to support the DS4Windows way:
"Actual controllers data - When you get this type of message, no instant response is required. Instead, you should begin or continue sending data from requested controller to this server." (my emphasis).

The reason cemuhook's PadTest worked correctly with @joaorb64's DSU Server may be because
PadTest requests data from all connected controllers at once, in stead of individually.

Thank you for the complete answer. I'll try changing the server's response and report back.

Actions #9

Updated by joaorb64 over 4 years ago

Ok, fixed it from joycond-cemuhook's end.
From what I could understand, even though the protocol supports up to 4 controllers per server, all emulators create a client for each emulated controller. Because of this, I had to get which controller each client was asking for via the id they requested in the request message.
This issue is fixed and was not a Dolphin bug. Thank you all for your help!

Actions #10

Updated by Billiard26 over 4 years ago

  • Status changed from New to Working as intended
Actions

Also available in: Atom PDF