Pete
Fri May 02 19:27:18 CDT 2008
We aren't calling UpdateDriverforPlugAndPlayDevices every time one of our
devices is plugged in, but that doesn't mean you'll like what we are doing.
Our device exports descriptors indicating it conforms to the USB audio class
specification. Nevertheless, we want it driven by our driver if our driver
is installed. Because our driver has not passed WHQL, the system decides its
own class driver is a better match than our driver, even though ours is a
better match according to the standard USB rules.
Because our plans do not include the driver ever passing WHQL, and because
we have a process lying around all the time anyway, we added code to detect
the appearance of an instance of our device and wait for it to be matched
with a driver. If that driver happens to be the system's class driver, we
instruct the system to replace its own driver with ours, which is where the
WHQL warning comes in. Once this is done, the system remembers that it has
been done, and we don't have to do it again, because the next time the
device comes online, the system will match it with our driver automagically,
and our happy little babysitter process will see that everything has already
gone according to plan and do nothing.
If you were to protest that this whole strategy stinks, I wouldn't be in a
position to argue otherwise. The strategy was chosen before my time, and we
have been employing it successfully for years in multiple products, and the
only reason this issue has come up now is that we haven't needed to support
multiple devices before. My job is only to make sure the implementation is
as clean and smooth as it can be.
You mention that the second and subsequent calls will try to replace the
driver on all instances of the device, but the story can't be quite that
simple. If it were, I would expect the second instance to cause two WHQL
warnings, the third instance to cause three WHQL warnings, the fourth
instance to cause four WHQL warnings, and so on. Instead, what happens is
that the fourth instance causes one warning and the fifth instance causes
two warnings. So something weird is going on. My tester thinks it might have
something to do with the fact that different instances are on different
controllers, but we haven't yet found any practical value to that theory.
Any insight welcome.
Pete Gontier
http://www.m-audio.com/
pete (at) m-audio (dot) com
On 5/2/08 3:55 PM, in article #9iWheKrIHA.2064@TK2MSFTNGP05.phx.gbl, "Ray
Trent" <rat@nospam.nospam> wrote:
> Wait... are you calling UpdateDriverforPlugAndPlayDevices every time one
> of your USB devices is plugged in? That would be wrong. And it wouldn't
> surprise me if you would get weird results (because the second and
> subsequent calls will try to update the driver on all the devices
> currently plugged in, resulting in multiple messages).
>
> Pete Gontier wrote:
>> My app calls UpdateDriverForPlugAndPlayDevices and it works. The driver is
>> installed, the device works, everybody is happy. Except...
>>
>> If more than one instance of the model in question is on the bus (it's a USB
>> device), then I get not just one WHQL warning but at least one more. And the
>> pattern is very weird.
>>
>> Let's say the user plugs in one of my devices, and my app calls
>> UpdateDriverForPlugAndPlayDevices, and the user gets a WHQL warning, and she
>> says continue, and everything works. Peachy, right? Now she plugs in a
>> second device and she gets two warnings. Weird! Let's say she says continue
>> two more times and then plugs in a third device. Now she gets three
>> warnings, but the weirdness is just getting started. She plugs in a fourth
>> instance of the device and she gets one warning (expected) but then she
>> plugs in a fifth instance and gets two warnings.
>>
>> Remember, I get the extra warnings even if all but one instance of the
>> device in question already has the driver. But, just to be paranoid, I made
>> sure I was not calling UpdateDriverForPlugAndPlayDevices again due to
>> re-entrant delivery of messages to my window.
>>
>> Of course, I am looking to inhibit the extra WHQL warnings. Any ideas?