Closed Kanuan closed 6 months ago
Agreed, the SET request being successful may not infer that the address was written properly, so better to do:
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.
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?
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.
When on USB, there are 2 situations in which DsHidMini updates the device's host address field that is stored in the Device Context:
DsUsb_PrepareHardware
methodDsUsb_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