Purpose of IRP_MN_QUERY_INTERFACE???

NTDEV
1

Hi All,

As earlier I have been discussing about a virtual hub/bus driver which I
have implemented for the Remote redirection of USB devices, I would like to
know what exactly this driver has to reply for IRP_MN_QUERY_INTERFACE???
What is the purpose of the interface structure??? If this is not supported
will it create any issues with Composite devices???

Thanks in advance.

This message, together with any attachment(s), contains confidential and proprietary information of
ServerEngines LLC and is intended only for the designated recipient(s) named above. Any unauthorized
review, printing, retention, copying, disclosure or distribution is strictly prohibited. If you are not the
intended recipient of this message, please immediately advise the sender by reply email message and
delete all copies of this message and any attachment(s). Thank you.

2

Vishwanath Maram wrote:

As earlier I have been discussing about a virtual hub/bus driver which
I have implemented for the Remote redirection of USB devices, I would
like to know what exactly this driver has to reply for
IRP_MN_QUERY_INTERFACE??? What is the purpose of the interface
structure??? If this is not supported will it create any issues with
Composite devices???

It’s exactly the same as the COM QueryInterface concept. It allows
drivers to establish a direct call interface. The GUID identifies what
kind of functions the upper driver wants to call, and the lower driver
(if it supports the interface) returns a set of function pointers to
implement whatever the GUID required.

So, there is no generic answer to this. In order to implement this, you
have to recognize the GUID, and then see if you can learn what functions
are needed to implement that interface.

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

3

Hi Tim,

We were able to make the ISOCH devices (like USB headset) work with our
virtual bus driver, but when we try with Webcam the upper layer drivers
doesn’t respond for the very first packet of ISOCH which is of 24K packet
and earlier we fixed issues with regard to IRP_MN_QUERY_INTERFACE call which
we are now returning some dummy call back function pointers…but now for
this webcam we are not sure as to what exactly is happening???

Any suggestions would be of great help…

Thanks in adanvance…!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, January 04, 2008 11:32 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Purpose of IRP_MN_QUERY_INTERFACE???

Vishwanath Maram wrote:

As earlier I have been discussing about a virtual hub/bus driver which
I have implemented for the Remote redirection of USB devices, I would
like to know what exactly this driver has to reply for
IRP_MN_QUERY_INTERFACE??? What is the purpose of the interface
structure??? If this is not supported will it create any issues with
Composite devices???

It’s exactly the same as the COM QueryInterface concept. It allows
drivers to establish a direct call interface. The GUID identifies what
kind of functions the upper driver wants to call, and the lower driver
(if it supports the interface) returns a set of function pointers to
implement whatever the GUID required.

So, there is no generic answer to this. In order to implement this, you
have to recognize the GUID, and then see if you can learn what functions
are needed to implement that interface.

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

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

This message, together with any attachment(s), contains confidential and proprietary information of
ServerEngines LLC and is intended only for the designated recipient(s) named above. Any unauthorized
review, printing, retention, copying, disclosure or distribution is strictly prohibited. If you are not the
intended recipient of this message, please immediately advise the sender by reply email message and
delete all copies of this message and any attachment(s). Thank you.

4

Vishwanath Maram wrote:

We were able to make the ISOCH devices (like USB headset) work with our
virtual bus driver, but when we try with Webcam the upper layer drivers
doesn’t respond for the very first packet of ISOCH which is of 24K packet
and earlier we fixed issues with regard to IRP_MN_QUERY_INTERFACE call which
we are now returning some dummy call back function pointers…but now for
this webcam we are not sure as to what exactly is happening???

Any suggestions would be of great help…

You can’t return dummy callback functions! If you don’t support the
interface, you have to fail the request. By succeeding, you are
promising to offer services without having any clue what those services are!

I’m not sure what you mean by “upper layer drivers doesn’t respond”.
Most images are much larger than 24K bytes, so it takes many packets to
construct a whole image that can be sent to an application.

How are you responding? Are you filling in the IsoPacket array in the
URB you return?

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

5

Tim,

We are supporting the below interfaces and USB (Headsets) are working after
we started supporting the first interface and other 3-interfaces we were
returning status not supported. Here when are supporting we followed the
API’s definition for all the versions (V0/V1/V2) and returning proper values
only then we were able to make the headsets along with microphone were
working fine.

GUID_BUS_INTERFACE_STANDARD
STATIC_BUSID_SoftwareDeviceEnumerator
USB_BUS_INTERFACE_USBDI_GUID
GUID_USBCAMD_INTERFACE

Now for Webcamera purpose we started supporting “GUID_USBCAMD_INTERFACE”,
here we tried returning all possible ways and after returning the first
received packet from other side we do a IoCompleteIrp() and there is some
exception raised or it never comes out properly… So we are stuck here for
webcamera case. Yeah we are filling the return URB also properly along ISO
Packet Descriptors…

Any clue or suggestions would be of great help.

Thanks in advance.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, January 28, 2008 4:58 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Purpose of IRP_MN_QUERY_INTERFACE???

Vishwanath Maram wrote:

We were able to make the ISOCH devices (like USB headset) work with our
virtual bus driver, but when we try with Webcam the upper layer drivers
doesn’t respond for the very first packet of ISOCH which is of 24K packet
and earlier we fixed issues with regard to IRP_MN_QUERY_INTERFACE call
which
we are now returning some dummy call back function pointers…but now for
this webcam we are not sure as to what exactly is happening???

Any suggestions would be of great help…

You can’t return dummy callback functions! If you don’t support the
interface, you have to fail the request. By succeeding, you are
promising to offer services without having any clue what those services are!

I’m not sure what you mean by “upper layer drivers doesn’t respond”.
Most images are much larger than 24K bytes, so it takes many packets to
construct a whole image that can be sent to an application.

How are you responding? Are you filling in the IsoPacket array in the
URB you return?

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

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

This message, together with any attachment(s), contains confidential and proprietary information of
ServerEngines LLC and is intended only for the designated recipient(s) named above. Any unauthorized
review, printing, retention, copying, disclosure or distribution is strictly prohibited. If you are not the
intended recipient of this message, please immediately advise the sender by reply email message and
delete all copies of this message and any attachment(s). Thank you.

6

Vishwanath Maram wrote:

We are supporting the below interfaces and USB (Headsets) are working after
we started supporting the first interface and other 3-interfaces we were
returning status not supported. Here when are supporting we followed the
API’s definition for all the versions (V0/V1/V2) and returning proper values
only then we were able to make the headsets along with microphone were
working fine.

GUID_BUS_INTERFACE_STANDARD
STATIC_BUSID_SoftwareDeviceEnumerator
USB_BUS_INTERFACE_USBDI_GUID
GUID_USBCAMD_INTERFACE

I can believe you might need to support USB_BUS_INTERFACE_USBDI_GUID,
but not the other three.

Now for Webcamera purpose we started supporting “GUID_USBCAMD_INTERFACE”,
here we tried returning all possible ways and after returning the first
received packet from other side we do a IoCompleteIrp() and there is some
exception raised or it never comes out properly… So we are stuck here for
webcamera case. Yeah we are filling the return URB also properly along ISO
Packet Descriptors…

GUID_USBCAMD_INTERFACE is provided by USBCAMD2, not by the bus. By
offering to support this, you are just confusing things, because the
driver won’t be able to communicate with USBCAMD2.

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

7

Yeah we are supporting only USB_BUS_INTERFACE_USBDI_GUID, but for webcamera
isn’t it required to support GUID_USBCAMD_INTERFACE???

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, January 29, 2008 10:03 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Purpose of IRP_MN_QUERY_INTERFACE???

Vishwanath Maram wrote:

We are supporting the below interfaces and USB (Headsets) are working
after
we started supporting the first interface and other 3-interfaces we were
returning status not supported. Here when are supporting we followed the
API’s definition for all the versions (V0/V1/V2) and returning proper
values
only then we were able to make the headsets along with microphone were
working fine.

GUID_BUS_INTERFACE_STANDARD
STATIC_BUSID_SoftwareDeviceEnumerator
USB_BUS_INTERFACE_USBDI_GUID
GUID_USBCAMD_INTERFACE

I can believe you might need to support USB_BUS_INTERFACE_USBDI_GUID,
but not the other three.

Now for Webcamera purpose we started supporting “GUID_USBCAMD_INTERFACE”,
here we tried returning all possible ways and after returning the first
received packet from other side we do a IoCompleteIrp() and there is some
exception raised or it never comes out properly… So we are stuck here
for
webcamera case. Yeah we are filling the return URB also properly along ISO
Packet Descriptors…

GUID_USBCAMD_INTERFACE is provided by USBCAMD2, not by the bus. By
offering to support this, you are just confusing things, because the
driver won’t be able to communicate with USBCAMD2.

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

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

This message, together with any attachment(s), contains confidential and proprietary information of
ServerEngines LLC and is intended only for the designated recipient(s) named above. Any unauthorized
review, printing, retention, copying, disclosure or distribution is strictly prohibited. If you are not the
intended recipient of this message, please immediately advise the sender by reply email message and
delete all copies of this message and any attachment(s). Thank you.

8

Vishwanath Maram wrote:

Yeah we are supporting only USB_BUS_INTERFACE_USBDI_GUID, but for webcamera
isn’t it required to support GUID_USBCAMD_INTERFACE???

You’re not thinking about this logically. You’re just hacking away,
hoping something works. For each interface, SOMEONE is responsible for
implementing it. In the case of GUID_USBCAMD_INTERFACE, as the
documentation says, the interface is implemented by USBCAMD2.SYS. He is
required to support it. The bus/hub driver is not. Look at the
functions in the interface:

typedef struct {
INTERFACE Interface;
PFNUSBCAMD_WaitOnDeviceEvent USBCAMD_WaitOnDeviceEvent;
PFNUSBCAMD_BulkReadWrite USBCAMD_BulkReadWrite;
PFNUSBCAMD_SetVideoFormat USBCAMD_SetVideoFormat;
PFNUSBCAMD_SetIsoPipeState USBCAMD_SetIsoPipeState;
PFNUSBCAMD_CancelBulkReadWrite USBCAMD_CancelBulkReadWrite;
} USBCAMD_INTERFACE, *PUSBCAMD_INTERFACE;

Clearly, those are not tasks that a generic USB bus driver would know
how to handle!

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

9

Hi Tim,

A basic question once again, can we redirect the webcamera’s on to other
system??? Because I see most of the products which are available in the
market today redirect mass storage, digital still camera’s, printers,
scanners, PDA’s, other wireless devices but I haven’t seen any software
redirector which does redirect the webcamera. So I just wanted this
clarification…

Thanks in advance!!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, January 29, 2008 11:55 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Purpose of IRP_MN_QUERY_INTERFACE???

Vishwanath Maram wrote:

Yeah we are supporting only USB_BUS_INTERFACE_USBDI_GUID, but for
webcamera
isn’t it required to support GUID_USBCAMD_INTERFACE???

You’re not thinking about this logically. You’re just hacking away,
hoping something works. For each interface, SOMEONE is responsible for
implementing it. In the case of GUID_USBCAMD_INTERFACE, as the
documentation says, the interface is implemented by USBCAMD2.SYS. He is
required to support it. The bus/hub driver is not. Look at the
functions in the interface:

typedef struct {
INTERFACE Interface;
PFNUSBCAMD_WaitOnDeviceEvent USBCAMD_WaitOnDeviceEvent;
PFNUSBCAMD_BulkReadWrite USBCAMD_BulkReadWrite;
PFNUSBCAMD_SetVideoFormat USBCAMD_SetVideoFormat;
PFNUSBCAMD_SetIsoPipeState USBCAMD_SetIsoPipeState;
PFNUSBCAMD_CancelBulkReadWrite USBCAMD_CancelBulkReadWrite;
} USBCAMD_INTERFACE, *PUSBCAMD_INTERFACE;

Clearly, those are not tasks that a generic USB bus driver would know
how to handle!

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

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

This message, together with any attachment(s), contains confidential and proprietary information of
ServerEngines LLC and is intended only for the designated recipient(s) named above. Any unauthorized
review, printing, retention, copying, disclosure or distribution is strictly prohibited. If you are not the
intended recipient of this message, please immediately advise the sender by reply email message and
delete all copies of this message and any attachment(s). Thank you.

10

Vishwanath Maram wrote:

A basic question once again, can we redirect the webcamera’s on to other
system??? Because I see most of the products which are available in the
market today redirect mass storage, digital still camera’s, printers,
scanners, PDA’s, other wireless devices but I haven’t seen any software
redirector which does redirect the webcamera. So I just wanted this
clarification…

“Can we” meaning “is it physical possible?” Yes, it’s physically
possible. However, I doubt that you will ever be able to make it work
reliably. Indeed, anything that uses an isochronous pipe is going to be
a problem.

The problem is that webcams (like microphones and speakers) are
real-time devices. At some point, the camera driver will turn on
streaming. As soon as that happens, the buffers in the camera will
start filling. If the buffers aren’t emptied in time, data will be
lost. Your redirection is going to add a significant delay into that
process, long enough to overflow all but the largest camera buffers.
Since most cameras are built by Pacific rim companies on a razor thin
margin, they don’t include such buffers.

Disks, still cams, printers, scanners, etc. are not like that. They all
hold data until it is requested, so a delay doesn’t matter very much.

Is it possible to work around this? To a certain extent, yes. Your
driver needs to recognize when a driver has become a “continuous reader”
by submitting multiple outstanding isochronous URBs. In that case, you
can trigger an equivalent “continuous reader” loop on the remote end.
There will still be an initial delay, and you’ll be highly dependent on
network latency, but there’s a chance.

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