HLK Change for Camera People

I posted some weeks ago about a non-UVC USB camera we have that has
passed WHQL several times before, currently passes HCK for Windows 7 and
8, but fails HLK for Windows 10 with an “interface not found” error
inside the test code.  I’m currently 14 very frustrating days into my
attempt to get Microsoft’s tech support people to treat me as something
other than an idiot, a battle that I do not recall fighting the last
time I submitted a support incident.

One of the tidbits that just came out of that exchange is that in the
RS4 release (1803), they plan to require that all USB cameras use the
UVC driver (usbvideo.sys).  I’m amazed this is being attempted again. 
Microsoft tried to enforce that restriction 8 or 10 years ago, but were
forced to revoke it after industry backlash.  Nothing has changed since
then.  There are still many, many USB cameras in the industrial control
world that are not UVC compliant.  Part of that is because of
requirements that do not fit neatly into UVC, but part of it is that the
industrial control world changes very, very slowly.  I’m still
supporting, testing, and certifying drivers for devices designed in
2006, before there was good UVC support in camera chips, and those
cameras are still being sold into new installations.

So, if any of my colleagues are doing non-UVC USB cameras, now is the
time to speak up.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Hi Tim,

Thank you for going through the painful process of MS tech support and keeping us up to date with your findings. My company produces USB cameras with proprietary USB device drivers, so we are very much interested in the points you’re bringing up. I’m not sure what next steps to take as one of the non-UVC USB camera people, but I just wanted to answer the rallying call.

So far we have been running HCK signing only for our drivers, as HCK signing still appears to validate the driver for use on Windows 10 machines, at least as new as Build 10586. But the RS4 release changes and the enforcing of their UBC driver on our devices would impact our products significantly.

Tim

Hi,

Can you elaborate on what your affected device actually is? Is it a camera using the USB Video Class but you want to use your own driver matching by VID/PID? Are you trying to hook it into the DirectShow layer?

If you are just a USB camera device that doesn’t use the USB Video class ID nor tries to hook into DirectShow, I don’t see how Microsoft would treat it any differently than any other custom USB device. There would be no way for them to even know it is a camera from the USB device descriptors or the INF file. This is how industrial USB cameras typically operate, so I don’t see how they could be affected by a change that you describe.

Eric

Entirely correct.

Because, it IS a custom USB device. It’s an Industrial Control Peripheral, an Industrial Vision Controller, and not a camera at all. And it should not be WHQL’ed as a camera. If you WHQL it as a camera, then people have the right to expect it to work like a camera in their commodity system. And that’s not what it does.,

Peter
OSR
@OSRDrivers

eric.gross@ni.com wrote:

Can you elaborate on what your affected device actually is? Is it a camera using the USB Video Class but you want to use your own driver matching by VID/PID? Are you trying to hook it into the DirectShow layer?

No, the device is not USB Video Class.  It is in vendor class, but the
driver is in Class=Image or Class=Media.

If you are just a USB camera device that doesn’t use the USB Video class ID nor tries to hook into DirectShow, I don’t see how Microsoft would treat it any differently than any other custom USB device. There would be no way for them to even know it is a camera from the USB device descriptors or the INF file. This is how industrial USB cameras typically operate, so I don’t see how they could be affected by a change that you describe.

It’s not clear what you mean by “hook into DirectShow”.  They can’t tell
anything from the descriptors, but the driver is an AVStream driver,
specifically so it can be used through DirectShow.  It’s the deadly
combination of USB and Class=Image that, apparently, will be a trigger
for WHQL.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Hi Tim,

Thanks for the clarification. I’m a bit unfamiliar with the video software layers (AVStream) under Windows, so I think my terminology was a bit off.

I’m most familiar with USB3 Vision, which has a defined USB sub-class under Misc (EF 05). This is commonly used by industrial cameras. Typically the vendor provides a driver that works with their own API to configure the camera and retrieve images (there is another use case with class drivers provided by another vendor, but ignore that for now). Often they also provide some sort of software filter driver that “hooks into DirectShow” (forgive my terminology, again) as a filter driver to provide compatibility with DirectShow applications. Thus, their main driver is not an AVStream driver or listed as image or media class in the INF.

Would splitting your driver into a USB driver plus a filter driver be a reasonable workaround? I don’t know any particular downsides on this approach, but I do know that this is the route most of the vendors delivering USB3 Vision devices take. It may have some historical reasons since many vendors also ship similar GigE Vision devices, and those don’t typically have a standard kernel driver associated with them since they just talk over UDP.

Eric

On Apr 13, 2018, at 1:49 PM, eric.gross@ni.com wrote:
>
> Would splitting your driver into a USB driver plus a filter driver be a reasonable workaround? I don’t know any particular downsides on this approach, but I do know that this is the route most of the vendors delivering USB3 Vision devices take.

These cameras were designed in 2006, and the driver is common to about 20 different camera front-ends. They are still being sold, but it is quite unlikely that the vendor is going to redesign their software stack at this point, just to satisfy an arbitrary and seemingly pointless rule created by WHQL.

They’ll just have to tell their clients to complain to Microsoft.

Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Yeah, MS’s support when you hit seemingly-bogus WHQL limitations is pretty terrible… Good luck.

Sorry to be sorta “limited” here… but if you’re making the device, and you’re gonna use custom drivers anyways, wouldn’t you just make it USB and Class = FF and be DONE with it?

It’s an *industrial* vision device, not a “camera” per se.

I apologize if this is a silly question. But I would appreciate it if you would enlighten me.

Peter
OSR
@OSRDrivers

xxxxx@osr.com wrote:

Sorry to be sorta “limited” here… but if you’re making the device, and you’re gonna use custom drivers anyways, wouldn’t you just make it USB and Class = FF and be DONE with it?

It’s an *industrial* vision device, not a “camera” per se.

I apologize if this is a silly question. But I would appreciate it if you would enlighten me.

Exactly.  That’s what it is.  If I call it “video class” in the
descriptors, then I’m saying I conform to UVC and I get what I deserve. 
Instead, we use Class=FF.

The issue is that my custom AVStream driver specifies Class=Image in the
INF file, which is the only way I can be recognized as a capture
driver.  The WHQL testing apparently sees that “this is a capture driver
that drives a USB device”, and that is apparently the combination they
intend to prohibit.

But, you know, now that you have pointed this out, this does seem like a
totally unreasonable restriction.  I wonder if perhaps my support
incident contact (who after 20 days has STILL not offered me any
suggestions or advice) does not understand the situation.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.