Closed szempy closed 6 months ago
I see there was a bug about this in v2.8.5 that was already resolved awhile ago. Can you please try again with a recent library release and see if the issue still persists?
I did try this out whit every version until the latest 2.10.1 but it has this bug in it still.
Do you know if this is an FTDI device? Also, what is it listed as under "Device Manager", and if you go further into the properties for the device in Device Manager, what is listed on the "Details" tab under the two properties "Device description" and "Bus reported device description"? Thanks!
Yes it is an FTDI device In the Device Manager it is listed as USB serial Port it has the latest FTDI driver 2.12.36.4 It appears as USB Serial Converter and USB Serial Port. But then i don't understand where did it get the information that this is a Smart Card Rack with the version 2.8.4 and lower.
I honestly have no idea. There were virtually no changes on this front between 2.8.4 and 2.8.5, and all of the description information comes from the underlying OS, so I'm kind of at a loss as to where that string would have come from. If you downgrade from the current library release back to 2.8.4, does the description change back to "Smart Card Rack"? Also, is there any reference to "Smart Card Rack" in any of the device properties for this device in Device Manager?
Using Library Version v2.8.5 getDescriptivePortName: USB Serial Port (COM3) getSystemPortName: COM3 toString: USB Serial Port getPortDescription: USB Serial Port isOpen: false Using Library Version v2.8.4 getDescriptivePortName: USB Serial Port (COM3) getSystemPortName: COM3 toString: Smart Card Rack getPortDescription: Smart Card Rack isOpen: false
No i couldn't find any reference in the device manager in other properties that this is a smart card rack.
Can it be that this was looked up from the Vendor ID and Device ID?
FTDIBUS\COMPORT&VID_0403&PID_6015
Very odd - the only other place it could be coming from is the device itself using the FTDI driver. Prior to v2.8.5, if the device was determined to be FTDI-based, the library would actually open the port and poll for its information during enumeration. This opening/closing operation during enumeration turned out to cause substantial issues for a number of users (particularly because it tried to open ALL devices that it located to retrieve their information). I definitely don't want to add back in functionality that requires the devices to be opened during enumeration, but I will see if I can figure out a way to retrieve the relevant information without actually connecting. I'll post back once I've done some exploration.
That is understandable. At least i know why it did change. If there is some update let me know. Thank you.
After a decent amount of probing, I don't see any way to retrieve/update this FTDI-specified device description without actually opening all devices during enumeration (which I don't want to do). That being said, these strings should automatically be probed and cached by Windows when it first registers the device in the OS (and would be reported in the "bus-reported description" detail item).
The library already tries to update its strings using this property if it exists, and I have tested a number of FTDI devices on my own Windows PC. There was only 1 device that I was able to replicate this bug on, and it looks like Windows just failed to enumerate this string when it initially connected...unfortunately, it never retries to parse this information (even through reboots). The only way I was able to get it to update the description correctly was:
1) Go into Device Manager 2) Right-click the port in question 3) Click "uninstall device" followed by "uninstall" (don't select "attempt to remove the driver for this device") 4) Click Action->Scan for Hardware Changes, and let it reinstall the device
After I did the above, my problematic device showed up with the correct description. Maybe you can get some mileage out of this?
I did try but nothing has changed. Is it possible to add this function so they can be called from outside to check and read the real device description directly from the FTDI?
Today's release of v2.11.0 added a static method called allowPortOpenForEnumeration()
which you can call before trying to enumerate ports. This will allow an FTDI device to be opened for full enumeration instead of using the OS-cached values.
I have discovered that the getPortDescription has changed on windows server 2016 x64 the java version doesn't matter. So with the version 2.8.4 when i call the function getPortDescription i get : "Smart Card Rack" when i change the library to 2.8.5 i will get the "USB Serial Port" response. Can someone check out what happened. Thank you.