Closed Geroyuni closed 3 years ago
nefarius
commented
3 years ago This is unfortunately by design. When you re-pair a wireless device, the ID the Windows PNP system assigns to it gets regenerated. HH depends on this ID to identify individual devices of the same manufacturer to work its magic. I'm afraid as of now there's no fix for that, maybe the upcoming changes for more scripting interaction can help building somewhat solid workarounds by users.
Geroyuni
commented
3 years ago Oh well, sad. I'll leave it up to you to close this issue depending on what you feel makes sense
Kanuan
commented
3 years ago HH depends on this ID to identify individual devices of the same manufacturer to work its magic
But if the ID is more-or-less unique, why does HidHide still recognizes the device as locked when repaired?
nefarius
commented
3 years ago HH depends on this ID to identify individual devices of the same manufacturer to work its magic
But if the ID is more-or-less unique, why does HidHide still recognizes the device as locked when repaired?
Because the old, now stale ID is still in the drivers cache and gets returned by the API and therefore rendered in the UI.
Kanuan
commented
3 years ago If the intended behaviour was for a completely new entry to be generated when a device is repaired then I confirm the issue exist. Steps to reproduce:
joy.cpl
nefarius
commented
3 years ago If the intended behaviour was for a completely new entry to be generated when a device is repaired then I confirm the issue exist. Steps to reproduce:
- Pair a DualShock 4
- Hide it with HidHide
- Confirm the controller is hidden
- Remove the DualShock 4 from Windows' Bluetooth Devices list
- Pair the controller again
- Confirm the DualShock 4 entry is still marked as "hidden" on HidHide
- Confirm the real device is still visible on
joy.cpl
I think I need to clarify further on the Device Instance ID: it it totally possible, that you get the same one after you remove and pair again, so since the same value (it's just a string comparison) is still present in the drivers cached configuration, it will continue hiding that device.
This is Windows PNP behaviour and "is what it is", so we can not offer a technical solution, the alternative would be to fall back to using HardwareIDs for more reliable blocking, but that ofc. has the major disadvantage that you won't be able to block individual DS4 controllers or any device of the same make and model on the same system. So pick your poison 🙂
Closing since unresolvable.
Kanuan
commented
3 years ago I used the CLI tool and confirmed that the device instance of a re-paired controller do is different from the device instance that remains on HidHide's blacklist.
My DS4 as it appears when the "list connected devices" command is used (--dev-gaming)
HID{00001124-0000-1000-8000-00805f9b34fb}_VID&0002054c_PID&09cc\9&1a03a06a&18&0000
How it appears when the "list HidHide's blacklist" command is used (--dev-list)
HID{00001124-0000-1000-8000-00805f9b34fb}_VID&0002054c_PID&09cc\9&1a03a06a&17&0000
To reproduce, use a bluetooth controller that has been previously paired on Windows and checked as hidden on HidHide, and manually remove it in "Windows Settings > Devices > Bluetooth & other devices". Then, pair it again by clicking "Add device" in the same Windows settings area.
HidHide will still show that controller as checked in its configuration wizard, although it'll not actually hide the controller. Turning the controller off and on again still won't make HidHide hide the controller, neither will a system restart. Also notably, the controller name no longer shows as the generic "HID-compliant game controller", but instead whatever it has when it's not hidden.
This was tested with a Dualshock 4 and DualSense controller. I have to manually uncheck and check the controller again in the configuration wizard to fix this. I come across this a lot because I need to pair my controllers again after using it in a different device, otherwise Windows won't use it.