-
Notifications
You must be signed in to change notification settings - Fork 3
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
DISE Programmer application sometimes won't use the correct handle to access the HID Keyboard. #4
Comments
I just can't reproduce this issue on my PC. No matter what usb port I use, it always recognize the device. |
I'm using Windows 11 Using devmanview64 I can see the two installed devices (look for the device with VID 0483 PID 573e) :
I had the issue twice , just by plugging the device while testing it. I used different ports on different hubs and it happened. To force this issue It may work to unplug the device, uninstall the entry that is detected as a keyboard with devmanview and plug it again so windows reinstall the device driver. That may switch the order of the devices. |
Do you have an access to a windows 10 machine, to see if you have the same problem? |
No right now, |
I separated this issue in a new different thread for the shake of clarity.
Problem:
Sometimes after plugging and unplugging the keyboard in different ports the keyboard the Programmer app won't be able to communicate to the keyboard.
Causes:
It seems that when you plug the DISE there are two devices listed as connected in windows HIDLibrary.
The last one is always used. But not always the correct one.
How to replicate:
Connect the keyboard in different USB ports until the app stops showing any of the keypresses despite of showing the green connected icon.
Workaround:
Disconnect the DISE and then using a program like devmanview remove all the non connected HID entries. then connect the keyboard and it will work again. Beause windows will list the devices and install the drivers in the right order.
Details and a temporary fix:
I've changed the code from the InitDevice to debug whats been listed, and all the available information from each device using this code:
** MainWindow.xml.cs** Line 248 function InitDevice()
This modification in a non working condition will make the keyboard work and display this at the output:
The only difference that the HIDLibrary is showing as far as I know is the ending \kbd of one of them on the DevicePath.
What the modification is doing to make the program select the right one is:
Final notes
I have the feeling that this fix is kind of ugly. Excluding a device by it's ending on the device path probably doesn't cut it.
And i'm unsure about the longevity of the fix on future Windows releases.
I don't know if anyone knows a better solution, to differentiate between the good and bad HID device now that we have the problem identified.
If you want to have this solution implemented for the time being, I can clean up the logging output lines and commit a pull request.
The text was updated successfully, but these errors were encountered: