macos and Windows disagree on interface numbering for Black Magic Probe #214
Comments
|
(The above comment appears to be spam, and I am unable to submit a report to Github because their captcha isn't working.) |
|
Ahhh those spammers are all over github right now. Anyways, thanks for the report. I have one thing I am interested in seeing, and that is the HWID for the Black Magic ports on Windows. To see these open up Device Manager, click on the ports, go to the "Details" tab, then go to the "Hardware Ids" tab. |
|
Here's the HWID for COM9, which shows up as Interface 0:
Similarly, here's COM8, which shows up as Interface 2:
On the Mac, they show up as Interface 1 and 3 respectively. |
|
Well we are just reporting what it says then, unfortunately. Not much we can do about it here. You could ask the Black Magic folks about it. It is defined here: I'm not sure where they are defined for Darwin. |
|
I think what's going on is that the Mac is reporting the CDC Data interface, whereas Linux and Windows are reporting the Communcations interface. So it's fundamentally different information. It might be useful to point out this difference, and ultimately the proper thing to do is for application writers to be aware of the difference and to have different checks when the operating system is from Apple. You might want to note this in the documentation, but if not please feel free to close this issue. |
|
For the record, the issue is in fact that the serial port is listed under the Notice how the actual interface is Apple is not doing the correct thing in this case, and I'm not sure how to get the correct thing out of the system. |
|
Thank you very much for spotting this and your extensive research @xobs! Having two device files for a single serial devices on macOS is how macOS reports it: as a callout and a TTY device. It is how it is. But the interface number does not match my expectation: I was assuming that
So may be we just have to put some more fairy dust at it for picking the "right" interface number. Could you please post the whole tree from |
|
Here's the entire output from the Black Magic device: It has six interfaces. One interface is for SWO capture, and is not a specific interface. It's designed to be read with libusb directly. One interface is for talking with DFU. Again, this is designed to be read with libusb. Two interfaces are the serial output to communicate with the onboard UART. Two interfaces are the GDB server, designed to interact directly with GDB. Recall that with USB ACM, a single serial port needs to have two interfaces:
Here's an example I found of the various interfaces: https://gist.github.com/lupyuen/073984471bc064216995d0a6b18c0b95 So yes, there are two interfaces for the one serial port. Unfortunately, Macos (and therefore serialport-rs) is picking the wrong one. It apparently should pick the lower-numbered one, but I can't find a doc that describes that. |
Thank you for pointing this out! I was not aware of this when writing my last reply.
So may be this is open to drivers and OS' and the choices were just made out of convenience. So it's likely up to us to look for both CDC ACM interfaces and report the lower one. Speaking about consistency: Have you looked at other libraries (like pySerial) how they report interface numbers for CDC ACM devices? |
|
pySerial doesn't report interface numbers: from serial.tools import list_ports
if __name__ == '__main__':
for port in list_ports.comports(include_links=False):
print(f"Port: {port.name} Interface: {port.interface}")Windows: Mac: I'm trying to find the location in the USB spec that defines which interface number to use when referring to the device. |
|
Ah okay, I found it. From https://www.usb.org/sites/default/files/iadclasscode_r10.pdf on the very last page:
So it's defined that the Interface number should be the lowest value when there are multiple descriptors. |
|
After thinking about it a bit more, it may just be that the answer is that the However, it's probably safe to say that, regardless of the platform, it'll be one of the two, so either should be acceptable when searching for a particular device. |
So they're going easy here. :)
Thank you for your extensive research here! As bFirstInterface does not show up int the data from the IOKit registry, we could no take it into account and the quote from the document does not explicitly how do deal with bInterfaceNumber it looks like we are free to report whatever we like.
This sounds right. We might change the reported interface number but this comes at a decent amount of work for retrieving the lower one from the IOKit registry tree. In my schedule there is no room for this overhaul in the near future. But feel free to create a PR if you feel idle. ;-) In every case a PR for just adding some lines of documentation to Thank you all for the fruitful discussion so far! |
Document that the interface number can vary depending on the platform. This addresses some surprise discovered in serialport#214, as it isn't entirely clear which interface should be used, but it is definitely clear that different platforms report differing interface indexes. Signed-off-by: Sean Cross <[email protected]>
|
Alright, I added a note. Again, I'm not even sure if macOs is in the wrong here. I do know it's different, but maybe it is the case where both are valid and developers need to recognize both in their code. In any case, this has been perfect for my usecase, so thanks again for producing a wonderful crate! |
Document that the interface number can vary depending on the platform. This addresses some surprise discovered in #214, as it isn't entirely clear which interface should be used, but it is definitely clear that different platforms report differing interface indexes. Signed-off-by: Sean Cross <[email protected]>
and others
The Black Magic Probe has two serial ports, and the interface should be 0 and 2. For example, this is how it shows up under Windows:
However under Mac, it lists each port twice, and the interface is offset by one:
There are two issues:
I'm uncertain what this would show on Linux, so I'm not sure which would be considered more "canonical". I can work around it in software by accepting either 0 or 1, and I can ignore "/dev/tty*", but it would be nice if it were the same across platforms.
The text was updated successfully, but these errors were encountered: