- Device Interface Classes
- Posted by Gerhard Steup on July 17th, 2003
Is there a way to enumerate device interfaces without
knwoing the class guids?
I can only get interfaces with SetupDiGetClassDevs if I
have a guid.
And I only can use SetupDiEnumDeviceInterfaces when I have
a DeviceInfoSet.
What I would need to know is, if there is a way to get a
list of all known interface classes, that I then could use
in SetupDi... functions.
(User Mode environment)
- Posted by Eliyas Yakub [MSFT] on July 17th, 2003
There isn't a documented way to get the all device interface classes
registered in the system. The reasoning for not providing such an interface
is that to be able to use an interface, you need to know the nature of the
device (keyboard, mouse, disk). You can't just randomly open a interface
guid and do read/write/ioctl on it. I brought up this issue long time ago
with our PNP engineer and this is what he had to say:
"The purpose of device interfaces is to separate the functionality provided
by a device (i.e., what the user cares about) from the details pertaining to
the device's installation/configuration (i.e., which users should seldom, if
ever, care about). Someone registering for notification about a particular
interface class should know (a) what the interface is and (b) how to use it.
This implies they know the relevant headerfile(s) for the interface of
interest, and included in such a headerfile would be the interface class
GUID used in enumeration of and notification registration for members of
that class."
--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/hwdev/driver/kb-drv.mspx
- Posted by Eliyas Yakub [MSFT] on July 18th, 2003
Where do you think the information given by SetupDi is coming from? When the
device is enumerated and installed, the system queries the bus driver about
the device for all kinds of IDs and stores them in the registry. So what you
get out of SetupDi (device specific information) is what is present in the
hardware. You don't have to do any matching with the descriptor.
You don't have to parse the InstanceID to get VID/PID information. You
should use SetupDiGetDeviceRegistryProperty functions to get the HW Id and
go from there.
I think you definitely need to read DDK documentation and Walter Oney's
book to understand device driver concepts and APIs before doing anything.
--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/hwdev/driver/kb-drv.mspx
- Posted by Gerhard Steup on July 19th, 2003
I think you didn't understand, what I was saying. Let me
rephrase what I am doing:
I have a list of USB devices descriptors for all the end
devices connected (discovered the same way usbview does).
I also have a list of devices that match my interface
class (enumerated through SetupDi)
Now some of those devices in the usbview list are the same
as the ones in the SetupDi list, but which ones are they?
I use VID/PID to find out. On the usbview side I ONLY have
descriptors (VID/PID is part of the USB device descriptor
as integers). I cannot get the symbolic name or any
registry properties for end-devices only for hubs.
On the SetupDi side I have the symbolic path and Registry
properties (VID/PID is part of the device ID string). I
cannot get the device descriptors as I need a handle to
the hub device (which I don't have unless I go down the
usbview path).
How do I match them up in a better way? I have looked
through DDK and header files up and down and couldn't find
anything, probably I am missing something.
doing anything.
I think so too, that's why I already ordered it yesterday.