We have created a digital camera for a specific customer who requires
that the camera display an icon in Windows Device Manager under
"Imaging Devices". We can accomplish this using the "Imaging Device"
GUID in the INF file ( GUID = {6bdd1fc6-810f-11d0-
bec7-08002be2092f} ). However, the camera does not support WIA and is
not intended to be a "Still Image" camera. If we submit the device to
USB-IF for compliance testing, will this cause a problem? Are there
any other restrictions/requirements for devices that use this location
in Driver Manager?
Thanks
That's what I tend to use for web cameras, because you do inherit automatic
WIA support.
>However, the camera does not support WIA and is
>not intended to be a "Still Image" camera.
Doesn't matter; Windows will provide automatic WIA and TWAIN support, and
will actually allow applications to grab snapshots from the stream.
If you really don't want it to be exposed in Scanners and Cameras, you can
choose to put it in Media class instead of Image class:
Class=Media
ClassGUID={4d36e96c-e325-11ce-bfc1-08002be10318}
>If we submit the device to
>USB-IF for compliance testing, will this cause a problem?
USB-IF doesn't test the functionality of your device. They won't use the
driver at all. They're going to test your electrical compliance, your
descriptors, your response to power states and resets, etc.
Did you really mean WHQL testing?
>Are there any other restrictions/requirements for devices that use
>this location in Driver Manager?
Not really, no.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Hi and thanks for the reply,
> If you really don't want it to be exposed in Scanners and Cameras, you can
choose to put it in Media class instead of Image class:...
Our customer specifically requires us to use the Image class.
> Doesn't matter; Windows will provide automatic WIA and TWAIN support, and
> will actually allow applications to grab snapshots from the stream.
Our driver package (a user mode DLL plus the Cypress kernel mode
driver) has a
proprietary API used only by the customer. There are is no TWAIN
support (nor
streams available to other applications).
Dave
Hi and thanks for the reply,
> If you really don't want it to be exposed in Scanners and Cameras, you can
> choose to put it in Media class instead of Image class:...
Our customer specifically requires us to use the Image class.
> Doesn't matter; Windows will provide automatic WIA and TWAIN support, and
> will actually allow applications to grab snapshots from the stream.
Our driver package (a user mode DLL and the generic Cypress kernel
mode driver CyUsb.sys) has a
proprietary API used only by the customer. There are is no TWAIN
support (nor streams available
to other applications).
> Did you really mean WHQL testing?
Well, our main goals are to be USB-IF certified and to get the driver
package signed so that we
can perform a "silent" installation without the annoying "not signed"
or "not Windows Logo..." dialog
boxes appearing. We DO NOT need to be Windows Logo compliant.
However, it seems that to get the packaged signed we need WHQL
certification as well as a certificate from
an entity like Verisign (which we have). Correct me if I am wrong,
but this may not be as onerous as it once was:
1. We can perform the WHQL testing in-house using the Driver Test
Manager (DTM).
2. We then email the results to Microsoft (for ~$250.00 !!!!).
3. If the tests pass, we will be emailed the proper certificates to
allow our package to be signed.
If this is incorrect, please let me know!
In addition, there is something called an "unclassified signature".
Will this allow us to use the Image class without
needing to support WIA/STI?
Thanks,
DCR
Dave
Customers very often do not understand what they want. It's the job of a
professional consultant to guide them into adjusting their expectations.
>> Doesn't matter; Windows will provide automatic WIA and TWAIN support, and
>> will actually allow applications to grab snapshots from the stream.
>
>Our driver package (a user mode DLL and the generic Cypress kernel
>mode driver CyUsb.sys) has a proprietary API used only by the customer.
>There are is no TWAIN support (nor streams available to other applications).
If the device is not available for other applications to use, then why
would you put it in a standard device class at all? The purpose of
standard device classes is to say "this device works just like other
devices in this class." Why not just create your own device class?
>> Did you really mean WHQL testing?
>
>Well, our main goals are to be USB-IF certified and to get the driver
>package signed so that we
>can perform a "silent" installation without the annoying "not signed"
>or "not Windows Logo..." dialog
>boxes appearing. We DO NOT need to be Windows Logo compliant.
You have several interesting conflicts in that paragraph. USB-IF testing
has nothing to do with drivers or package signing. It's just another logo
you can put on the box.
And to perform a silent installation, you DO need to be Windows logo
compliant.
>However, it seems that to get the packaged signed we need WHQL
>certification as well as a certificate from
>an entity like Verisign (which we have). Correct me if I am wrong,
>but this may not be as onerous as it once was:
>1. We can perform the WHQL testing in-house using the Driver Test
>Manager (DTM).
>2. We then email the results to Microsoft (for ~$250.00 !!!!).
>3. If the tests pass, we will be emailed the proper certificates to
>allow our package to be signed.
>
>If this is incorrect, please let me know!
That's more or less correct, yes.
>In addition, there is something called an "unclassified signature".
>Will this allow us to use the Image class without needing to support
>WIA/STI?
No. If you expect to qualify your hardware as an Image class device, then
it must behave like an Image class device. Your hardware is NOT a standard
Image class device, so advertising it in the Image class is flat out wrong.
If your device will not support any standard imaging/streaming APIs, then
you should put your device in a custom device class and submit it as an
unclassified device. That's really what it is: a miscellaneous device.