Prior to my question , I’d like to describe the scenario .
Two identical USB devices are connected and works at High speed(2.0)
With an application , Enduser backups data from them respectively. After then , End User starts to switches them by sending the vendor defined command. After switching , two devices are enumerated as other “device” (different PID with before) and what’s more , they are switched to low speed (1.1). Then , we restore the just extracted data to the original one.
Now the problem comes up : We can’t identify which device is the original device .
As I know, the port information retrieved with DeviceIocontrol is elaborated and subject to change if speed is changed. So , I don’t think that can be applied to this scenario.
Currently , I wanna cope with it in this way : Try to bind the device with the connected physical port.
I suppose every physical USB port has a physical address(or whatever information uniquely identifies it ). So I can internally maintain a mapping table (the device <=> USB port ) . And then when the devices restarts or switched , I just use this port information to identify the connected device .
With this idea , several questions is presented :
- This idea is feasible ? Do you have better suggestion ???
2 . Is there any Port data/information documented for this purpose ?? Currently , I wanna do it in Kernel mode . So any Kernel API is provided ?
- With this idea , how to handle the scenario where external HUB is connected .
Please feel free to share your idea . Thanks a lot.
There are two easy ways to identify a USB device:
(1) You can use the USB Serial Number String Descriptor (index in Device
Descriptor/iSerialNumber) to identify your devices and tell them apart:
http://www.beyondlogic.org/usbnutshell/usb5.htm
(2) We have a reason not to use this, so we use a “vendor specific” USB
string descriptor. The device driver relays this via IOCTL to our
application.
(Any string index value not published in any configuration or interface
descriptors makes it “vendor specific”.)
[PSetupDiEnumDeviceInterfaces gives a list of devices, then we query
them individually for their ID strings and then open the one we want.]
This works for USB 1/2 and for any USB port a device may be plugged in.
(3) Background note:
Microsoft, too, uses this technique:
http://www.microsoft.com/whdc/connect/usb/usbfaq_intermed.mspx
On the very first plug-in of a new device you will get the request for
an 0xEE string descriptor. Better handle it properly (STALL) if you
don’t support it. 
Thanks for the prompt reply .
Here is my comment:
For reply 1) , I don’t think serial number is applied in this scenario . After switching from A mode to B mode , the device reports different serial number and PIDs( You can simply consider Device in A mode is absolutely different from in B mode since they have different PID and accordingly OS loads different driver). Also , serial number is not reliable since device team always set them NULL .
Currently , I hope to solve it from PC side and don’t expect to have more involved
-
We are PC-side developer ,including App and driver. Device team might not pay more effort on this “virtual” request which actually doesn’t enhance phone except to make us convenient. We need to enumerate all possible solutions from PC side firstly. So , please understand my situation …
-
Thanks for the reference.
> 1. This idea is feasible ? Do you have better suggestion ???
No.
When you switch from Hi to Full or Low, another USB controller can come into play and pick up your device. This will change anything related to port number.
USB is designed in a way to make the “address” and “port number” meaningless for the software.
Keep some unique ID in the device itself.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>driver). Also , serial number is not reliable since device team always set them NULL .
How great.
Put the device to another USB port and have the full driver reinstall sequence.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> Currently , I wanna cope with it in this way : Try to bind the device with the connected physical port.
I suppose every physical USB port has a physical address(or whatever information uniquely identifies
Look at USBVIEW in the WDK samples, maybe this is the solution.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Thanks to each of you , especially to Chris .
Lastly, a quick question for Doron as to the device instance ID generation algorithm .
As for what I know , this ID is generated partly depending on port information. If MS can reveal it and release a formal algorithm , my issue seems to be easily solved.
After all , identifying which usb device to connect to which physical port is really a reasonable requirement from developers.
It is not a reasonable request, we are not going to doc the algorithm. If you want a predictable instance, use serial numbers.
d
sent from my phpne
-----Original Message-----
From: xiedong_sl@126.com <xiedong_sl>
Sent: April 22, 2010 7:23 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] I hope to bind the device with the connected physical USB Port
Thanks to each of you , especially to Chris .
Lastly, a quick question for Doron as to the device instance ID generation algorithm .
As for what I know , this ID is generated partly depending on port information. If MS can reveal it and release a formal algorithm , my issue seems to be easily solved.
After all , identifying which usb device to connect to which physical port is really a reasonable requirement from developers.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</xiedong_sl>
> After all , identifying which usb device to connect to which physical port is really a reasonable
requirement from developers.
So, if the user will plug the same device to another port, his/her setup will be broken?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
No. How to use this information is fully depending on end-developer…
<xiedong_sl> wrote in message news:xxxxx@ntdev…
> …
> After all , identifying which usb device to connect to which physical port
> is really a reasonable requirement from developers.
Yes it is reasonable - but can be done only if the device has some distinct
piece of data on it, which can be read in runtime.
A “serial number”, for example. USB ports are enumerated like in usbview (in
WDK examples).
“Serial number” is special because it also makes part of the instance path,
so device specific info can be persisted rigth in the instance registry.
Otherwise, need to store it elsewhere.
–pa</xiedong_sl>
Maxim S. Shatskih wrote:
So, if the user will plug the same device to another port, his/her
setup will be broken?
No, no, no. Did you read the original post? Imagine twenty USB devices all connected to a machine, all through hubs, add-on controller cards, etc. They have different operational modes based on different PIDs and even USB modes (1.1 vs 2.0). The typical operation works like this:
-
Back up data from the device (USB 2.0)
-
Reboot the device into programming mode (which is USB 1.1)
-
Restore the data to the device after its been wiped/reprogrammed (USB 2.0)
Problem is, going from #1 to #2, you can’t tell where the device is (or, which “one” it is) after it restarts, because it has reappeared in a totally different place in the device hierarchy (because it has switched host controller parents).
What’s the real solution? Yes, some unique ID, of course. Unfortunately, OP says the device owner refuses. Consider it the same as the “my boss says…” posts that come from time to time.
>> So, if the user will plug the same device to another port, his/her
> setup will be broken?
No, no, no. Did you read the original post?
Yes, but the thread went to general USB design choices.
For me, the USB is designed to simulate the electrical parallel connection as much as it can. That’s why using the port numbers (and associating something with them) is a bad idea - the users are accustomed that all USB ports on the machine are the same, and it is not important where to plug the device.
I think this is why Doron insists to avoid parsing the undocumented USB instance IDs.
And yes, unique IDs are good
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
…
> For me, the USB is designed to simulate the electrical parallel connection
> as much as it can. That’s why using the port numbers (and associating
> something with them) is a bad idea - the users are accustomed that all USB
> ports on the machine are the same, and it is not important where to plug
> the device.
This is fine with USB mice or keyboards, but imagine two netcards connected
to different networks,
then the user definitely wants to know which is which.
The USB standard, if my memory serves, lets hubs have LEDs on each port and
there’s some command to control these LEDs.
Regards,
–pa