DsHidMini v3 not loading device specific settings when controller is connected via BT
Kanuan opened this issue · comments
This is the configuration file I'm using: DsHidMini.txt (changed from .json to .txt to upload the file here on github)
This is the tracing results when connecting the controller via USB:
This is the result when connecting via BT (note that the "device specific" line is missing):
I'm pretty sure I wasn't running on this problem before updating the BthPS3 version (currently I'm using version 2.8.320.0). Will test if it's actually a BthPS3 issue somehow
I'm pretty sure I wasn't running on this problem before updating the BthPS3 version (currently I'm using version 2.8.320.0). Will test if it's actually a BthPS3 issue somehow
Yeah, no, the same issue happens under BthPS3 v2.6.127.0. I think I just didn't notice this issue before because I was using global settings the majority of time
Not sure I ever tested it wireless since it was introduced, so can totally be the case it's overlooked, will check it out.
In configuration.c, the ConfigLoadForDevice method gets the string that represents the device MAC address from the Context->DeviceAddressString field. The issue is that this field is not set when the device is connected via BT.
I've added a tracing message for it to show this field value if it fails to load the settings and it returns blank when via BT:
From what I've looked around, The device's DeviceAddressString field is only set in the DsUdb_PrepareHardware method of the DsUsb.c file, but this method is only called if the device is connected via USB, therefore the DeviceAddressString field is never set via BT:
I tried to set DeviceAddressString in the DsDevice_ReadProperties method of the device.c file immediately after it sets the DeviceAddress field. This works in the sense that the field is correctly set, but for some reason putting this piece of code here causes the driver to get stuck immediately after it:
From the traceview log, the driver hangs if DeviceAddressString is set before invoking the DsDevice_RegisterBthDisconnectListener method.
Setting the DeviceAddressString field AFTER both listerner-related methods are invoked fix the hanging and the code works as expected, allowing the driver to properly load device-specific configurations.
I'm really curious to why the driver hangs if the DeviceAddressString field is set before the listener-related methods are invoked, nothing in them seems to make use of it, but regardless, this got the "works on my machine" seal of approval. Will prepare a PR for the fix.
If the tracing just stops and the driver responding, it means it crashed. Look in the event viewer for Critical or Error events from the user-mode driver reflector service, I bet you find one or more crash logs.
Should look similar to #333
Yeah that's what I thought, we're probably reading or writing invalid/uninitialized memory somewhere during this exact sequence or in parallel and it goes poof. WinDbg session or code review could uncover why exactly.
Once you make a PR and I see the diff, maybe something obvious jumps out.