Did Descriptive port names change in 2.9.2?

[inahas]

Where does one find a list of changes between builds/versions?

We noticed a change in how the port descriptive names are being reported (see below). I am not sure if this was related to a change in jSerialComm or some other OS configuration.

Previously - descriptive name is different than description:

2022-08-15 20:48:33,181 [INFO ]    * ttyS0 : Physical Port S0 = Physical Port S0
2022-08-15 20:48:33,181 [INFO ]    * ttyS1 : Physical Port S1 = Physical Port S1
2022-08-15 20:48:33,181 [INFO ]    * ttyUSB0 : CP2104 USB to UART Bridge Controller = USB-to-Serial Port (cp210x)
2022-08-15 20:48:33,181 [INFO ]    * ttyUSB2 : FT232R USB UART = USB-to-Serial Port (ftdi_sio)
2022-08-15 20:48:33,181 [INFO ]    * ttyUSB1 : Digilent USB Device = USB-to-Serial Port (ftdi_sio)

Now - descriptive name same as description:

2022-08-15 20:58:07,932 [INFO ]   * ttyUSB1 : CP2104 USB to UART Bridge Controller = CP2104 USB to UART Bridge Controller
2022-08-15 20:58:07,933 [INFO ]   * ttyS0 : Physical Port S0 = Physical Port S0
2022-08-15 20:58:07,933 [INFO ]   * ttyUSB2 : FT232R USB UART = FT232R USB UART
2022-08-15 20:58:07,933 [INFO ]   * ttyUSB0 : Digilent USB Device = Digilent USB Device
2022-08-15 20:58:07,933 [INFO ]   * ttyS1 : Physical Port S1 = Physical Port S1

Our code depended on recognizing the port name by (cp210x) which no longer appears. Was this an intentional change in jSerialComm?

[hedgecrw]

The list of changes between each build can be found on the Releases page.

The change you're seeing is expected. We had a growing number of user issues around the enumeration of ports (from missing ports with unusual file descriptors to general slow enumeration on devices with lots of serial devices connected). As such, the entire enumeration subsystem was rewritten to take care of those issues in a generic fashion and prevent them from being reintroduced in the future when new serial devices become available.

The string you were relying on (cp210x) was coming from a last ditch effort of previous versions of the library to identify a port that it couldn't quite figure out by using the driver that was loaded to interface with the port. This turned out to be unreliable, very slow, and was no longer necessary after the rewrite, so now the port description and friendly name might match one another if the port itself doesn't report something different for those values.

For your specific use-case, the best way of detecting your particular serial device would be to use the descriptive name (which is well-defined on all OSs and won't change), or even better, if you don't anticipate plugging your device into a different port, use the getPortLocation() method to always return the unique physical location of the port. Hope that helps, and sorry for the confusion!