Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Only update device context's host address by using its respective GetFeature request #357

Closed
Kanuan opened this issue Apr 28, 2024 · 3 comments · Fixed by #360
Closed

Only update device context's host address by using its respective GetFeature request #357

Kanuan opened this issue Apr 28, 2024 · 3 comments · Fixed by #360
Labels
enhancement New feature or request USB USB-related (wired)
Milestone

Comments

@Kanuan
Copy link
Collaborator

Kanuan commented Apr 28, 2024

When on USB, there are 2 situations in which DsHidMini updates the device's host address field that is stored in the Device Context:

  1. It sends a GetFeature request and saves the host address informed by the controller when it responds
    • Occurs in the DsUsb_PrepareHardware method
  2. When a pairing request is sent to the controller and is considered successful, then it automatically updates the device's context host address field to the same one sent in the request
    • Occurs in the method currently known as DsUsb_Ds3PairToFirstRadio

I'd like to know your thoughts on removing the automatic updating done in (2), and replacing it with what happens in (1).

My line of thinking is that it would be better to always confirm what host address the controller is informing instead of assuming it was updated by the pairing request.

This would give us more info in situations in which the driver considers the pairing request succeeded but the controller continues informing it is paired to another MAC address

@nefarius
Copy link
Owner

Agreed, the SET request being successful may not infer that the address was written properly, so better to do:

  • Set new address to device
  • Query the address from device
  • If it matches with what we sent, update it in the context

Also another remark; IIRC there currently is two places for either device or host address where it is stored as a byte array/struct and a string, this makes it susceptible to bugs where only one is updated, we should look into streamlining that as well.

@nefarius nefarius added enhancement New feature or request USB USB-related (wired) labels Apr 29, 2024
@Kanuan
Copy link
Collaborator Author

Kanuan commented Apr 30, 2024

If the request to get the host address fails do we set the host address to all zeroes to signify "failure" or "unkown" or do we do nothing and introduce a separate property for the request status?

@nefarius
Copy link
Owner

Honestly I am displeased with the amount of workarounds currently required to send commands to the driver, maybe I should just add a vendor defined collection to each mode so we can send custom feature requests, like pairing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request USB USB-related (wired)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants