Hi.
I have modified the usbsamp driver provided along with wdk to suite my device needs. Now I want to provide a easy name for the devices which are connected. From the application the user will simply call CreateFile along with the device name .
eg. CreateFile( USBDevice-1,…)
Please tell me where i sould code for this. Presently all the devices are showing under \Device\KMDF0.
WdfDeviceCreateSymbolicLink*,* but the preferred method is to use
WdfDeviceCreateDeviceInterface and have your application find the device
through its interface guid and the setupdi api.
On Thu, Sep 4, 2008 at 9:36 AM, wrote:
> Hi.
> I have modified the usbsamp driver provided along with wdk to suite my
> device needs. Now I want to provide a easy name for the devices which are
> connected. From the application the user will simply call CreateFile along
> with the device name .
> eg. CreateFile( USBDevice-1,…)
>
> Please tell me where i sould code for this. Presently all the devices are
> showing under \Device\KMDF0.
>
> —
> 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
>
–
Mark Roddy
exactly…currently the INF file has a Guid entry. The application is using SetupDiXXX apis to get the device information. But later i am planning to remove the GUID entry and then the device will be detected under generic usb device list in device manager. The application will only use CreateFile along with device name to get a handle to the device. If more than one device is connected then the device name should be like USBDevice-1, USBDevice-2,USBDevice-3. So where should i handle this in driver code?
You can modify the EvtDeviceAdd code to include a symbolic link for the
device, and this can be in addition to or instead of the device interface.
See, for example, FmEvtDeviceAdd in the file src\kmdf\fakemodem\driver.c.
On Thu, Sep 4, 2008 at 10:57 AM, wrote:
> exactly…currently the INF file has a Guid entry. The application is using
> SetupDiXXX apis to get the device information. But later i am planning to
> remove the GUID entry and then the device will be detected under generic usb
> device list in device manager. The application will only use CreateFile
> along with device name to get a handle to the device. If more than one
> device is connected then the device name should be like USBDevice-1,
> USBDevice-2,USBDevice-3. So where should i handle this in driver code?
>
> —
> 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
>
–
Mark Roddy
Which GUID entry in the INF? The class GUID at the top of the INF is *not* the device interface GUID. Why are you moving to hard coded names? There are a few problems with them
Device interface guids solve all of these problems. You can get dynamically notified of arrival, departure and you definitively know how many devices there are w/out trying to iterate over a device name space.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, September 04, 2008 7:57 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] how to give a device name to connected usb devices ?
exactly…currently the INF file has a Guid entry. The application is using SetupDiXXX apis to get the device information. But later i am planning to remove the GUID entry and then the device will be detected under generic usb device list in device manager. The application will only use CreateFile along with device name to get a handle to the device. If more than one device is connected then the device name should be like USBDevice-1, USBDevice-2,USBDevice-3. So where should i handle this in driver code?
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
But there is also a major problem with the guids and the setup api: If
you have more than one device of the same type you never know which is
the first one and which the second, because the sorting algorithm which
microsoft implements is unknown. Furthermore it seems to vary from time
to time which is the first and which the second device.
From the user point of view this is very bad, it causes major confusion.
(my experince is about firewire, usb may be similar)
/Uwe
Doron Holan schrieb:
Which GUID entry in the INF? The class GUID at the top of the INF is *not* the device interface GUID. Why are you moving to hard coded names? There are a few problems with them
- you do not know when a new device arrives
- when do you stop iterating over the sequence in the names and know you found the last device?
- what happens if you have holes in the hard coded names? E.g. USBDevice-2 goes away? Are you always going to iterate from 1?
Device interface guids solve all of these problems. You can get dynamically notified of arrival, departure and you definitively know how many devices there are w/out trying to iterate over a device name space.
d
Why does it matter which is first? I bet the user does not remember one minute after they plugged in the device which one was first plugged in. nevermind the boot scenario when they are both present, what does first mean?. Fixed names does not solve the problem either, numbers can wrap around back to zero.
Instead of using the name to indicate order, have the device tell you when it started through an IOCTL (system time or in tick count). You find a device, you ask it the start time, you self sort. No need to create an attribute on a naming system to imply more information other than the name of the device you want to talk to
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Uwe Kirst
Sent: Thursday, September 04, 2008 10:06 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] how to give a device name to connected usb devices ?
But there is also a major problem with the guids and the setup api: If
you have more than one device of the same type you never know which is
the first one and which the second, because the sorting algorithm which
microsoft implements is unknown. Furthermore it seems to vary from time
to time which is the first and which the second device.
From the user point of view this is very bad, it causes major confusion.
(my experince is about firewire, usb may be similar)
/Uwe
Doron Holan schrieb:
Which GUID entry in the INF? The class GUID at the top of the INF is *not* the device interface GUID. Why are you moving to hard coded names? There are a few problems with them
- you do not know when a new device arrives
- when do you stop iterating over the sequence in the names and know you found the last device?
- what happens if you have holes in the hard coded names? E.g. USBDevice-2 goes away? Are you always going to iterate from 1?
Device interface guids solve all of these problems. You can get dynamically notified of arrival, departure and you definitively know how many devices there are w/out trying to iterate over a device name space.
d
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
I have seen a problem with identical device names: When two MIDI devices have identical names they show up as MIDI 1 and MIDI 2 in “Sound and Audio Control Panel” i.e. Windows adds the number 1 and so on to make them unique. The problem arises when your MIDI devices have identical names and you want to use Cubase. Cubase SX 4 can enumerate ports using Windows MIDI and Directmusic interface. So when two midi devices have same name directmusic interface does not show them properly in Cubase which results in a duplicate MIDI port.
To overcome the above problem you have to have a unique name for each midi device. At least I couldn’t think of any other way to fix this.
Doron Holan schrieb:
Why does it matter which is first?
The user has its own special settup. For example he connects his monitor
speaker to the first device, his headphones to the second. So he is very
confused if the next time he powers up his computer, the sound does not
come out of the device it is used to come.
For non microsoft APIs or applications the solution to this problem is
in my opinion that you reorder the devices with your own algorithm,
example: the devices with the lowest serial numer (if the devices has
one) is always presented to the user as the first.
For microsoft APIs, like the wave API I have no solution.
/Uwe
Instead of using the name to indicate order, have the device tell you when it started through an IOCTL (system time or in tick count). You find a device, you ask it the start time, you self sort. No need to create an attribute on a naming system to imply more information other than the name of the device you want to talk to
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Uwe Kirst
Sent: Thursday, September 04, 2008 10:06 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] how to give a device name to connected usb devices ?But there is also a major problem with the guids and the setup api: If
you have more than one device of the same type you never know which is
the first one and which the second, because the sorting algorithm which
microsoft implements is unknown. Furthermore it seems to vary from time
to time which is the first and which the second device.
From the user point of view this is very bad, it causes major confusion.
(my experince is about firewire, usb may be similar)
/UweDoron Holan schrieb:
> Which GUID entry in the INF? The class GUID at the top of the INF is *not* the device interface GUID. Why are you moving to hard coded names? There are a few problems with them
> 1) you do not know when a new device arrives
> 2) when do you stop iterating over the sequence in the names and know you found the last device?
> 3) what happens if you have holes in the hard coded names? E.g. USBDevice-2 goes away? Are you always going to iterate from 1?
>
> Device interface guids solve all of these problems. You can get dynamically notified of arrival, departure and you definitively know how many devices there are w/out trying to iterate over a device name space.
>
> d
>
>
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
I don’t see how order has anything to do with it. you want it to be property based, not derived from another abstraction like the name or identity on the bus. If I always used the lower serial number and I had 2 instances of the same device, what does that mean?
What you want is to determine what the device does and make an intelligent policy decision off of that. For an audio device in windows, the INF can indicate if the device should be given preference to be the default audio device or not. Certainly not based on what its symlink name is
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Uwe Kirst
Sent: Friday, September 05, 2008 1:47 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] how to give a device name to connected usb devices ?
Doron Holan schrieb:
Why does it matter which is first?
The user has its own special settup. For example he connects his monitor
speaker to the first device, his headphones to the second. So he is very
confused if the next time he powers up his computer, the sound does not
come out of the device it is used to come.
For non microsoft APIs or applications the solution to this problem is
in my opinion that you reorder the devices with your own algorithm,
example: the devices with the lowest serial numer (if the devices has
one) is always presented to the user as the first.
For microsoft APIs, like the wave API I have no solution.
/Uwe
Instead of using the name to indicate order, have the device tell you when it started through an IOCTL (system time or in tick count). You find a device, you ask it the start time, you self sort. No need to create an attribute on a naming system to imply more information other than the name of the device you want to talk to
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Uwe Kirst
Sent: Thursday, September 04, 2008 10:06 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] how to give a device name to connected usb devices ?But there is also a major problem with the guids and the setup api: If
you have more than one device of the same type you never know which is
the first one and which the second, because the sorting algorithm which
microsoft implements is unknown. Furthermore it seems to vary from time
to time which is the first and which the second device.
From the user point of view this is very bad, it causes major confusion.
(my experince is about firewire, usb may be similar)
/UweDoron Holan schrieb:
> Which GUID entry in the INF? The class GUID at the top of the INF is *not* the device interface GUID. Why are you moving to hard coded names? There are a few problems with them
> 1) you do not know when a new device arrives
> 2) when do you stop iterating over the sequence in the names and know you found the last device?
> 3) what happens if you have holes in the hard coded names? E.g. USBDevice-2 goes away? Are you always going to iterate from 1?
>
> Device interface guids solve all of these problems. You can get dynamically notified of arrival, departure and you definitively know how many devices there are w/out trying to iterate over a device name space.
>
> d
>
>
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
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
I have used a cypress driver for a diagnostic device. The driver dynamically assigns name as ezusb-0, ezusb-1…etc to devices connected to the host. If you now remove the device which is connected first ie ezusb-0 then the entry of driver object ezusb-0 gets deleted. Again if you replugin the device it assigns it as ezusb-0 coz the driver algorithm decides the least number that it can be assigned to. One more advantage of this is you can never overrun your number of device limits. So from application if we know MAX_DEVICES then you can iterate using CreateFile and check how many devices are connected by simply changing the index as ezusb-0, ezusb-1…etc in loop. The driver name also solves many purpose. For example if you are maintaining a diagnostic session with your device from your application then each time you dont need to query for serial number of the device each time to send any request to the device. Your code know which device it should send all request to and gets a handle of that device. All subsequent request will be send using the same handle. So if the driver is intelligent enough to assign a name to devices which get connected to the host then it solves the extra effort of finding each time the device with a serial number also a considerable application code can be reduced as only CreateFile API will be used to check if the device is connected. What do you’ll think ?
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Saturday, September 06, 2008 6:21 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] how to give a device name to connected
usb devices ?I have used a cypress driver for a diagnostic device. The
driver dynamically assigns name as ezusb-0, ezusb-1…etc
to devices connected to the host. If you now remove the
device which is connected first ie ezusb-0 then the entry of
driver object ezusb-0 gets deleted. Again if you replugin the
device it assigns it as ezusb-0 coz the driver algorithm
decides the least number that it can be assigned to. One more
advantage of this is you can never overrun your number of
device limits. So from application if we know MAX_DEVICES
then you can iterate using CreateFile and check how many
devices are connected by simply changing the index as
ezusb-0, ezusb-1…etc in loop.
If you use device interface, you don’t need the loop. You just enumerate
devices using Setup API and you’ll get exact list of all connected
devices. No need to use CreateFile() until you really need to open a
device. There are also other advantages as arrival and removal
notification. I believe Doron already explained it in this thread. What
you described is legacy and already obsolete way. It is mainly useful
for non-PnP devices which create only one device instance used for
communication with application.
The necessary enumeration code using Setup API is ugly but once you
write it, it is universal and can be reused for any device interface.
The driver name also solves
many purpose. For example if you are maintaining a diagnostic
session with your device from your application then each time
you dont need to query for serial number of the device each
time to send any request to the device. Your code know which
device it should send all request to and gets a handle of
that device. All subsequent request will be send using the
same handle. So if the driver is intelligent enough to assign
a name to devices which get connected to the host then it
solves the extra effort of finding each time the device with
a serial number also a considerable application code can be
reduced as only CreateFile API will be used to check if the
device is connected. What do you’ll think ?
With device interfaces app just registers device arrival notification
and doesn’t need to check if device is connected. BTW, do you realize
the driver is unloaded when the last device is disconnected so it can’t
keep serial numbers of previously connected devices?
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
It depends upon what type of device it is. Let’s pretend it is your own USB
Flash Drive. If you plug device #1 into the left USB slot on the front of
the case and device #2 into the right USB slot. After you power down the
system, you remove both devices. Then you power up the system putting the
same devices into the same slots after the OS is loaded, but insert device
#2 into the right USB slot first. What is going to happen to the device
names? Next time, reverse the left and right device and use a different
order each time. If you have a unique serial number for the devices and
properly signed drivers all your plugging and replugging may not cause
prompts but what will happen to those device names? I have discovered that
if I assign a specific drive letter to a USB flash drive it only sticks at
long as I keep using the same USB port each time. Using a different port
will destroy the link between that USB flash drive and the assigned drive
letter. Then, even plugging it back into the correct slot will not cause
the driver letter to revert to my assignment.
The above is why they use device interfaces such as just asking for an
inventory of all serial ports so you can check each and determine which has
the modem connected to it. This is why the term ‘shrug and pray’ is still
applicable to some degree though not as much as when plug and play began
with Windows 95.
wrote in message news:xxxxx@ntdev…
I have used a cypress driver for a diagnostic device. The driver dynamically
assigns name as ezusb-0, ezusb-1…etc to devices connected to the host.
If you now remove the device which is connected first ie ezusb-0 then the
entry of driver object ezusb-0 gets deleted. Again if you replugin the
device it assigns it as ezusb-0 coz the driver algorithm decides the least
number that it can be assigned to. One more advantage of this is you can
never overrun your number of device limits. So from application if we know
MAX_DEVICES then you can iterate using CreateFile and check how many devices
are connected by simply changing the index as ezusb-0, ezusb-1…etc in loop.
The driver name also solves many purpose. For example if you are maintaining
a diagnostic session with your device from your application then each time
you dont need to query for serial number of the device each time to send any
request to the device. Your code know which device it should send all
request to and gets a handle of that device. All subsequent request will be
send using the same handle. So if the driver is intelligent enough to assign
a name to devices which get connected to the host then it solves the extra
effort of finding each time the device with a serial number also a
considerable application code can be reduced as only CreateFile API will be
used to check if the device is connected. What do you’ll think ?
Doron Holan schrieb:
I don’t see how order has anything to do with it. you want it to be property based, not derived from another abstraction like the name or identity on the bus. If I always used the lower serial number and I had 2 instances of the same device, what does that mean?
If only one device is present - no problem. If you add the second, it
depends on the serial number of the two which will be the presented as
first of the two. So the first (in order) device may get renamed in that
case. Thats how it should be in my opinion. The order of the two devices
will never change if it is that way.
What you want is to determine what the device does and make an intelligent policy decision off of that. For an audio device in windows, the INF can indicate if the device should be given preference to be the default audio device or not. Certainly not based on what its symlink name is
Windows adds a number to the second audio device which can not be
changed or influenced by the audio driver. This number may change, the
setting of the default audio device does not help if the first and
second device of the same type change there order (for what reason that
happens I was never able to discover). The user will be confused if that
happens.
I think (but not 100% shure) the symlink name and the number added to
the friendly name are related somehow, so they reflect the same ms
determined order.
/Uwe
We all seem to think that you are missing the point of device interfaces.
The OS itself takes care of naming, iteration, arrival and departure
notification, in a standard language neutral fashion. The cost to you is a
one time effort to refactor the awful setupapi interface into a useable api
That said, it is easy enough to wedge the ezusb stuff, including its user
mode diagnostic application, into the kmdf format.
On Sat, Sep 6, 2008 at 12:21 AM, wrote:
> I have used a cypress driver for a diagnostic device. The driver
> dynamically assigns name as ezusb-0, ezusb-1…etc to devices connected to
> the host. If you now remove the device which is connected first ie ezusb-0
> then the entry of driver object ezusb-0 gets deleted. Again if you replugin
> the device it assigns it as ezusb-0 coz the driver algorithm decides the
> least number that it can be assigned to. One more advantage of this is you
> can never overrun your number of device limits. So from application if we
> know MAX_DEVICES then you can iterate using CreateFile and check how many
> devices are connected by simply changing the index as ezusb-0, ezusb-1…etc
> in loop. The driver name also solves many purpose. For example if you are
> maintaining a diagnostic session with your device from your application then
> each time you dont need to query for serial number of the device each time
> to send any request to the device. Your code know which device it should
> send all request to and gets a handle of that device. All subsequent request
> will be send using the same handle. So if the driver is intelligent enough
> to assign a name to devices which get connected to the host then it solves
> the extra effort of finding each time the device with a serial number also a
> considerable application code can be reduced as only CreateFile API will be
> used to check if the device is connected. What do you’ll think ?
>
> —
> 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
>
–
Mark Roddy
is there any wdf function to retrieve how many device objects have been created for a particular driver and to get the symboliclink name of each of the objects ?
Uwe Kirst wrote:
If you have more than one device of the same type you never know
which is the first one and which the second, […]
Furthermore it seems to vary from time to time which is the first and
which the second device.
With USB it depends on the order of the USB device in the USB tree.
It is fixed until e.g. a user switches off “the middle one” of three
devices, or disconnects and plugs a USB device to a different port.
From the user point of view this is very bad, it causes major
confusion. […]
We solved this problem for our product with “named USB devices”.
Our ethernet-enabled device types already had a “node name” for DHCP.
We renamed this to “device name” and make it available (also on USB-only
devices) as a vendor-specific USB string descriptor.
This device name is initialized with a factory serial, but it can be
easily changed by the user.
Connection to a device is also possible without “device name”, but then
again USB device order is important. So if you know what you do, or only
have one USB device at a given time, all is fine. Otherwise, just give a
meaningful name to your device, refer to this in your configuration
settings, and you never have to care again about where which USB device
is plugged in.
Another possibility would be to use the USB serial number for
differentiating devices, but then we could not have the user change it.
No. WDM does not have such functionality either (at least the latter part of finding the symlinks backpointing to the device objects). Is this for your own driver or for another PDRIVER_OBJECT?
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Sunday, September 07, 2008 8:05 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] how to give a device name to connected usb devices ?
is there any wdf function to retrieve how many device objects have been created for a particular driver and to get the symboliclink name of each of the objects ?
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