To understand the behavior of WinUSB backend

[Xiaofan Chen]

I have several questions here.

1) How to install WinUSB as a filter driver?
http://msdn.microsoft.com/en-us/library/ff540207%28v=VS.85%29.aspx
"Winusb.sys is a kernel-mode driver that can be installed as either a filter or
function driver, above the protocol drivers in a USB device's kernel-mode
device stack."

2) What is the limitation if using WinUSB as the function driver of the
whole USB Composite device (lieu of usbccgp.sys)?
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/30854d1855439cb6/d0140b3b9539e1b2?hl=en
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/0657c62e788b1fad?hl=en
http://msdn.microsoft.com/en-us/library/ff540219.aspx

It seems to me, if you want to claim interface 1, you have to claim
interface 0 (the default interface?). And then it seems there is
an issue with the wIndex being ignored.

3) Restriction of WinUSB, Pete has already documented some.
Are there any more restrictions?
http://www.libusb.org/wiki/windows_backend



--
Xiaofan http://mcuee.blogspot.com

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard]

On 2010.06.19 10:21, Xiaofan Chen wrote:
> 2) What is the limitation if using WinUSB as the function driver of the
> whole USB Composite device (lieu of usbccgp.sys)?
> http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/30854d1855439cb6/d0140b3b9539e1b2?hl=en
> http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/0657c62e788b1fad?hl=en
> http://msdn.microsoft.com/en-us/library/ff540219.aspx
>
> It seems to me, if you want to claim interface 1, you have to claim
> interface 0 (the default interface?). And then it seems there is
> an issue with the wIndex being ignored.

I remember having all the problems in the world trying to use WinUSB in
lieu of usbccgp.sys, which is something I played with when I thought it
could lead to simpler code. This was some time ago, and as far as I
recall, I never managed to get WinUsb_GetAssociatedInterface to properly
access the interfaces of a composite device.
I posted about this too
(http://www.winvistatips.com/re-winusb-device-path-t805606.html, which
somehow seems to be a duplicate, in a different forum, of your first
link), as it looks WinUSB only ever sees one interface then, which kind
of defeats the point of replacing usbccgp.sys.

And, indeed, as per the WinUSB specs, you always need to have interface
0 claimed before you can access the other interfaces, because you need
to feed the WinUSB handle of interface 0 before you can retrieve the
handle of the other ones.

I wouldn't mind finding out if anybody ever managed to use WinUSB as a
replacement for composite devices, and then access all the interfaces.

Regards,

/Pete

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Sun, Jun 20, 2010 at 7:10 AM, Pete Batard <[hidden email]> wrote:

> I remember having all the problems in the world trying to use WinUSB in
> lieu of usbccgp.sys, which is something I played with when I thought it
> could lead to simpler code. This was some time ago, and as far as I
> recall, I never managed to get WinUsb_GetAssociatedInterface to properly
> access the interfaces of a composite device.
> I posted about this too
> (http://www.winvistatips.com/re-winusb-device-path-t805606.html, which
> somehow seems to be a duplicate, in a different forum, of your first
> link), as it looks WinUSB only ever sees one interface then, which kind
> of defeats the point of replacing usbccgp.sys.

It is not a forum, but a newsgroup. The newsgroup is aggregated
or mirrored in different places, like Google Groups or WinVistaTips.

So it seems to me that WinUSB is never designed to be the
function driver of a USB composite device.


--
Xiaofan http://mcuee.blogspot.com

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

One more question regarding the default pipe policy for
WinUSB under libusb-1.0.

Document of WinUsb_GetPipePolicy and WinUsb_SetPipePolicy:
http://msdn.microsoft.com/en-us/library/ff728833%28VS.85%29.aspx

Implementation in libusb-1.0 WinUSB backend (copy from libusb-win32-v1)
http://git.libusb.org/?p=libusb-pbatard.git;a=blob;f=libusb/os/windows_usb.c;hb=HEAD

SHORT_PACKET_TERMINATE
IGNORE_SHORT_PACKETS
ALLOW_PARTIAL_READS
AUTO_CLEAR_STALL

ALLOW_PARTIAL_READS is the default anyway and it is compatible
with the libusb codes out there.

IGNORE_SHORT_PACKETS is a bit strange to me. Why turn it on?

SHORT_PACKET_TERMINATE and AUTO_CLEAR_STALL seem
to make libusb WinUSB backend more tolerant to bad device.

To me the choice seems to be sensible for the majority of the device
out there. But maybe there should be an WinUSB only API
to set the different policy settings. Is this possible?

--
Xiaofan http://mcuee.blogspot.com

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge]

Xiaofan Chen wrote:
> maybe there should be an WinUSB only API to set the different
> policy settings.

I would be strongly against a WinUSB specific API addition for this,
but libusb having it's own API for it could certainly make sense!


//Peter

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Sun, Jun 20, 2010 at 2:59 PM, Peter Stuge <[hidden email]> wrote:
> Xiaofan Chen wrote:
>> maybe there should be an WinUSB only API to set the different
>> policy settings.
>
> I would be strongly against a WinUSB specific API addition for this,
> but libusb having it's own API for it could certainly make sense!
>

I see. There are similar Flags for Linux to set up pipe policy,
right?


--
Xiaofan http://mcuee.blogspot.com

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard]

On 2010.06.20 00:49, Xiaofan Chen wrote:
> Implementation in libusb-1.0 WinUSB backend (copy from libusb-win32-v1)
>
> SHORT_PACKET_TERMINATE
> IGNORE_SHORT_PACKETS
> ALLOW_PARTIAL_READS
> AUTO_CLEAR_STALL

Yeah, I copied what Stephan was doing in win32 for init.

Note that, the way the code is written, we are *disabling*
SHORT_PACKET_TERMINATE, IGNORE_SHORT_PACKETS, ALLOW_PARTIAL_READS
(policy=false) and *enabling* AUTO_CLEAR_STALL

> ALLOW_PARTIAL_READS is the default anyway and it is compatible
> with the libusb codes out there.

Except we are disabling it here. I think the reason is so that we get an
explicit error on data size mismatch.
http://msdn.microsoft.com/en-us/library/ff540304%28VS.85%29.aspx seems
to be a bit more explicit about what each of these flags do when enabled
or disabled:

"If the allow partial reads policy parameter is FALSE (that is, zero),
the read request fails whenever the device returns more data than the
client requested.
If the allow partial reads policy parameter is TRUE, the WinUSB driver
saves the extra data and sends the extra data to the client during the
client's next read."

The reason I see for going with disabled is that, without it, we're
introducing uncertainties if extra data is being fed to libusb without
an actual USB readout. It might be better to alert the user that
something's amiss with the data.

I'm not sure what the default would be on other platforms though. If it
turns out that Darwin and Linux have partial reads or something
equivalent, I'll just change that flag.

> IGNORE_SHORT_PACKETS is a bit strange to me. Why turn it on?

As indicated above, we're actually making sure it's off.

> SHORT_PACKET_TERMINATE

"If the short packet terminate policy parameter is TRUE (that is,
nonzero), every write request that is a multiple of the maximum packet
size for the endpoint is terminated with a zero-length packet.
The default value of the short packet terminate policy parameter is FALSE."

I think it makes sense to disable that option here.

> AUTO_CLEAR_STALL

"If the auto clear stall policy parameter is TRUE (that is, nonzero),
the driver fails stalled data transfers, but the driver clears the stall
condition automatically, and data continues to flow on the pipe. This
policy parameter does not affect control pipes.
The default value for the auto clear stall policy parameter is FALSE."

This is the only option we actually enable at the moment.


Now, I agree with Peter that doing anything WinUSB specific for policy
settings sounds like a bad idea (but I could provide configurable
compile time options, if we fell that's needed).
However, if platforms other than Window+WinUSB have similar settings,
and they can be modified as well, adding a new generic API call makes sense.

Regards,

/Pete

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Alan Stern]

On Sun, 20 Jun 2010, Pete Batard wrote:

> Note that, the way the code is written, we are *disabling*
> SHORT_PACKET_TERMINATE, IGNORE_SHORT_PACKETS, ALLOW_PARTIAL_READS
> (policy=false) and *enabling* AUTO_CLEAR_STALL
>
> > ALLOW_PARTIAL_READS is the default anyway and it is compatible
> > with the libusb codes out there.
>
> Except we are disabling it here. I think the reason is so that we get an
> explicit error on data size mismatch.
> http://msdn.microsoft.com/en-us/library/ff540304%28VS.85%29.aspx seems
> to be a bit more explicit about what each of these flags do when enabled
> or disabled:
>
> "If the allow partial reads policy parameter is FALSE (that is, zero),
> the read request fails whenever the device returns more data than the
> client requested.
> If the allow partial reads policy parameter is TRUE, the WinUSB driver
> saves the extra data and sends the extra data to the client during the
> client's next read."
>
> The reason I see for going with disabled is that, without it, we're
> introducing uncertainties if extra data is being fed to libusb without
> an actual USB readout. It might be better to alert the user that
> something's amiss with the data.
>
> I'm not sure what the default would be on other platforms though. If it
> turns out that Darwin and Linux have partial reads or something
> equivalent, I'll just change that flag.

In Linux there's nothing like this -- the device is never allowed to
send more data than the client asked for.  If it tries, the extra data
is not accepted and the read request returns an error status.

> > IGNORE_SHORT_PACKETS is a bit strange to me. Why turn it on?
>
> As indicated above, we're actually making sure it's off.

I don't know what this flag does under Windows.  In Linux we have the
per-URB flag USBDEVFS_URB_SHORT_NOT_OK, which might be similar.  It
causes read requests to return an error status if they terminate early
because of a short packet (normally such early terminations return 0
status).

> > SHORT_PACKET_TERMINATE
>
> "If the short packet terminate policy parameter is TRUE (that is,
> nonzero), every write request that is a multiple of the maximum packet
> size for the endpoint is terminated with a zero-length packet.
> The default value of the short packet terminate policy parameter is FALSE."
>
> I think it makes sense to disable that option here.

In Linux this is selectable by a per-URB flag:
USBDEVFS_URB_ZERO_PACKET.  I don't think you can safely ignore this;
sometimes it is needed.  Of course, libusb could always take care of it
by explicitly writing a 0-length packet and not relying on the kernel's
facility.

> > AUTO_CLEAR_STALL
>
> "If the auto clear stall policy parameter is TRUE (that is, nonzero),
> the driver fails stalled data transfers, but the driver clears the stall
> condition automatically, and data continues to flow on the pipe. This
> policy parameter does not affect control pipes.
> The default value for the auto clear stall policy parameter is FALSE."
>
> This is the only option we actually enable at the moment.

The Linux kernel doesn't have anything like this, although libusb may
implement it internally.  It's not much of an issue because endpoints
other than endpoint 0 almost never stall (except in the mass-storage
protocols, but those generally aren't handled by user applications).

Alan Stern


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Mon, Jun 21, 2010 at 8:51 AM, Alan Stern <[hidden email]> wrote:

>> > AUTO_CLEAR_STALL
>>
>> "If the auto clear stall policy parameter is TRUE (that is, nonzero),
>> the driver fails stalled data transfers, but the driver clears the stall
>> condition automatically, and data continues to flow on the pipe. This
>> policy parameter does not affect control pipes.
>> The default value for the auto clear stall policy parameter is FALSE."
>>
>> This is the only option we actually enable at the moment.
>
> The Linux kernel doesn't have anything like this, although libusb may
> implement it internally.  It's not much of an issue because endpoints
> other than endpoint 0 almost never stall (except in the mass-storage
> protocols, but those generally aren't handled by user applications).
>

There are many firmware not working well with this. For example,
Microchip's USB Stack will lose data toggle when deal with
CLEAR_STALL.
http://www.microchip.com/forums/tm.aspx?m=503200
http://www.microchip.com/forums/tm.aspx?m=458573

All in all, I think it is difficult to only set a default for these
flags. The flags are there for a reason. So maybe it is
a good idea to provide an API for the users to choose
the option. Probably for next libusb 1.1...


--
Xiaofan http://mcuee.blogspot.com

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard]

On 2010.06.21 01:51, Alan Stern wrote:
>>> ALLOW_PARTIAL_READS
>
> In Linux there's nothing like this -- the device is never allowed to
> send more data than the client asked for.  If it tries, the extra data
> is not accepted and the read request returns an error status.

OK, then this will be kept disabled.

>>> IGNORE_SHORT_PACKETS
>>
>> As indicated above, we're actually making sure it's off.
>
> I don't know what this flag does under Windows.

"If the ignore short packets policy parameter is TRUE the host does not
complete a read operation after it receives a short packet. Instead, the
host completes the operation only after the host has read the specified
number of bytes.
If the ignore short packets policy parameter is FALSE, the host
completes a read operation when either the host has read the specified
number of bytes or the host has received a short packet."

In the current code, we're setting it to false (which is the default)

> In Linux we have the
> per-URB flag USBDEVFS_URB_SHORT_NOT_OK, which might be similar.  It
> causes read requests to return an error status if they terminate early
> because of a short packet (normally such early terminations return 0
> status).

I think what we're doing is close enough to not having
USBDEVFS_URB_SHORT_NOT_OK set in Linux (which I guess is the default).

Can libusb apps currently modify these per-URB flags on the fly, and if
yes, do we expect many applications to deviate from the defaults?

>>> SHORT_PACKET_TERMINATE
>>
>> "If the short packet terminate policy parameter is TRUE (that is,
>> nonzero), every write request that is a multiple of the maximum packet
>> size for the endpoint is terminated with a zero-length packet.
>> The default value of the short packet terminate policy parameter is FALSE."
>>
>> I think it makes sense to disable that option here.
>
> In Linux this is selectable by a per-URB flag:
> USBDEVFS_URB_ZERO_PACKET.  I don't think you can safely ignore this;
> sometimes it is needed.  Of course, libusb could always take care of it
> by explicitly writing a 0-length packet and not relying on the kernel's
> facility.

This is where having a generic API call to configure these options would
be useful. Of course, even if we have similar options, we'll have the
issue of having said option apply to the endpoint as a whole on Windows,
vs URBs on Linux.

>>> AUTO_CLEAR_STALL
>
> The Linux kernel doesn't have anything like this, although libusb may
> implement it internally.  It's not much of an issue because endpoints
> other than endpoint 0 almost never stall (except in the mass-storage
> protocols, but those generally aren't handled by user applications).

OK. I'll leave it enabled then, especially as per Xiaofan's additional
comments.

Regards,

/Pete

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Alan Stern]

On Mon, 21 Jun 2010, Pete Batard wrote:

> On 2010.06.21 01:51, Alan Stern wrote:
> >>> ALLOW_PARTIAL_READS
> >
> > In Linux there's nothing like this -- the device is never allowed to
> > send more data than the client asked for.  If it tries, the extra data
> > is not accepted and the read request returns an error status.
>
> OK, then this will be kept disabled.

I think that makes sense.

> >>> IGNORE_SHORT_PACKETS
> >>
> >> As indicated above, we're actually making sure it's off.
> >
> > I don't know what this flag does under Windows.
>
> "If the ignore short packets policy parameter is TRUE the host does not
> complete a read operation after it receives a short packet. Instead, the
> host completes the operation only after the host has read the specified
> number of bytes.
> If the ignore short packets policy parameter is FALSE, the host
> completes a read operation when either the host has read the specified
> number of bytes or the host has received a short packet."
>
> In the current code, we're setting it to false (which is the default)

Yes, that agrees with what the USB spec says to do.  I have to wonder
what bug led people to add this flag to Windows...

> > In Linux we have the
> > per-URB flag USBDEVFS_URB_SHORT_NOT_OK, which might be similar.  It
> > causes read requests to return an error status if they terminate early
> > because of a short packet (normally such early terminations return 0
> > status).
>
> I think what we're doing is close enough to not having
> USBDEVFS_URB_SHORT_NOT_OK set in Linux (which I guess is the default).

SHORT_NOT_OK doesn't have much purpose as part of a userspace API.  
It's really meant for use by kernel drivers; exporting it via usbfs
never made any sense.  Leaving it unset always is fine.

> Can libusb apps currently modify these per-URB flags on the fly, and if
> yes, do we expect many applications to deviate from the defaults?

I don't recall seeing any libusb programming interfaces for setting
these flags.  For the most part they won't matter, but there may be a
few here and there that are needed.

Apart from ZERO_PACKET, only the ISO_ASAP flag seems relevant.  But the
kernel doesn't implement it yet, so there's no use worrying about it
now.

> >>> SHORT_PACKET_TERMINATE
> >>
> >> "If the short packet terminate policy parameter is TRUE (that is,
> >> nonzero), every write request that is a multiple of the maximum packet
> >> size for the endpoint is terminated with a zero-length packet.
> >> The default value of the short packet terminate policy parameter is FALSE."
> >>
> >> I think it makes sense to disable that option here.
> >
> > In Linux this is selectable by a per-URB flag:
> > USBDEVFS_URB_ZERO_PACKET.  I don't think you can safely ignore this;
> > sometimes it is needed.  Of course, libusb could always take care of it
> > by explicitly writing a 0-length packet and not relying on the kernel's
> > facility.
>
> This is where having a generic API call to configure these options would
> be useful. Of course, even if we have similar options, we'll have the
> issue of having said option apply to the endpoint as a whole on Windows,
> vs URBs on Linux.

Either way would be okay.

> >>> AUTO_CLEAR_STALL
> >
> > The Linux kernel doesn't have anything like this, although libusb may
> > implement it internally.  It's not much of an issue because endpoints
> > other than endpoint 0 almost never stall (except in the mass-storage
> > protocols, but those generally aren't handled by user applications).
>
> OK. I'll leave it enabled then, especially as per Xiaofan's additional
> comments.

Alan Stern


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Tim Roberts]

Xiaofan Chen wrote:
> I have several questions here.
>
> 1) How to install WinUSB as a filter driver?
> http://msdn.microsoft.com/en-us/library/ff540207%28v=VS.85%29.aspx
> "Winusb.sys is a kernel-mode driver that can be installed as either a filter or
> function driver, above the protocol drivers in a USB device's kernel-mode
> device stack."
>  

I'm not sure this is possible.  When you use UMDF, WinUSB gets installed
as an upper filter to the UMDF proxy driver, and I THINK that's what
they're trying to say here.  However, Doron Holan of the Microsoft DDK
team has stated that WinUSB cannot act as a general filter driver.
Doron is usually right.

However, it's easy enough to try this.  You would install it like any
other filter driver.  Create a Services entry for it, then add the
service name to the UpperFilters or LowerFilters (which is more likely)
registry entry of the device you want to filter.  It's actually easier
than installing a full driver, because you don't need an INF.


> 2) What is the limitation if using WinUSB as the function driver of the
> whole USB Composite device (lieu of usbccgp.sys)?
>  

I don't think there is a limitation.  You just use
WinUsb_GetAssociatedInterface to switch between the interfaces.


> It seems to me, if you want to claim interface 1, you have to claim
> interface 0 (the default interface?).

WinUsb_Initialize grabs interface 0.  Then you use
GetAssociatedInterface to grab another one.  That shouldn't be a
problem; if you are the composite driver, you own all of the interfaces
anyway.


> And then it seems there is an issue with the wIndex being ignored.
>  

That's a question that has yet to be adequately resolved, as far as I know.

--
Tim Roberts, [hidden email]
Providenza & Boekelheide, Inc.


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

An old thread but may be still useful.

On Tue, Jun 22, 2010 at 1:25 AM, Tim Roberts <[hidden email]> wrote:

> Xiaofan Chen wrote:
>> I have several questions here.
>>
>> 1) How to install WinUSB as a filter driver?
>> http://msdn.microsoft.com/en-us/library/ff540207%28v=VS.85%29.aspx
>> "Winusb.sys is a kernel-mode driver that can be installed as either a filter or
>> function driver, above the protocol drivers in a USB device's kernel-mode
>> device stack."
>>
>
> I'm not sure this is possible.  When you use UMDF, WinUSB gets installed
> as an upper filter to the UMDF proxy driver, and I THINK that's what
> they're trying to say here.  However, Doron Holan of the Microsoft DDK
> team has stated that WinUSB cannot act as a general filter driver.
> Doron is usually right.
>
> However, it's easy enough to try this.  You would install it like any
> other filter driver.  Create a Services entry for it, then add the
> service name to the UpperFilters or LowerFilters (which is more likely)
> registry entry of the device you want to filter.  It's actually easier
> than installing a full driver, because you don't need an INF.

It is indeed possible.

Travis has an inf file now install libusb-win32 device driver
(libusb0.sys) as the function driver and use WinUSB as the
lower filter driver.

The following section adds WinUSB as the lower filter.

[Dev_AddReg]
HKR,,"DeviceInterfaceGUIDs",0x00010000,%Device_Guid%
HKR,,"LowerFilters",0x00010000,"WinUsb"

Test using the benchmark firmware and libusbdotnet benchmark
console program shows that this is indeed working.
http://libusbdotnet.svn.sourceforge.net/viewvc/libusbdotnet/trunk/stage/

>> 2) What is the limitation if using WinUSB as the function driver of the
>> whole USB Composite device (lieu of usbccgp.sys)?
>>
> I don't think there is a limitation.  You just use
> WinUsb_GetAssociatedInterface to switch between the interfaces.
>
>
>> It seems to me, if you want to claim interface 1, you have to claim
>> interface 0 (the default interface?).
>
> WinUsb_Initialize grabs interface 0.  Then you use
> GetAssociatedInterface to grab another one.  That shouldn't be a
> problem; if you are the composite driver, you own all of the interfaces
> anyway.

Indeed this is working now as per the resolution of the following ticket.
http://www.libusb.org/ticket/48

--
Xiaofan

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Mon, Aug 16, 2010 at 8:38 PM, Xiaofan Chen <[hidden email]> wrote:

> An old thread but may be still useful.
>
> On Tue, Jun 22, 2010 at 1:25 AM, Tim Roberts <[hidden email]> wrote:
>> Xiaofan Chen wrote:
>>> I have several questions here.
>>>
>>> 1) How to install WinUSB as a filter driver?
>>> http://msdn.microsoft.com/en-us/library/ff540207%28v=VS.85%29.aspx
>>> "Winusb.sys is a kernel-mode driver that can be installed as either a filter or
>>> function driver, above the protocol drivers in a USB device's kernel-mode
>>> device stack."
>>>
>>
>> I'm not sure this is possible.  When you use UMDF, WinUSB gets installed
>> as an upper filter to the UMDF proxy driver, and I THINK that's what
>> they're trying to say here.  However, Doron Holan of the Microsoft DDK
>> team has stated that WinUSB cannot act as a general filter driver.
>> Doron is usually right.
>>
>> However, it's easy enough to try this.  You would install it like any
>> other filter driver.  Create a Services entry for it, then add the
>> service name to the UpperFilters or LowerFilters (which is more likely)
>> registry entry of the device you want to filter.  It's actually easier
>> than installing a full driver, because you don't need an INF.
>
> It is indeed possible.
>
> Travis has an inf file now install libusb-win32 device driver
> (libusb0.sys) as the function driver and use WinUSB as the
> lower filter driver.
>
> The following section adds WinUSB as the lower filter.
>
> [Dev_AddReg]
> HKR,,"DeviceInterfaceGUIDs",0x00010000,%Device_Guid%
> HKR,,"LowerFilters",0x00010000,"WinUsb"
>
> Test using the benchmark firmware and libusbdotnet benchmark
> console program shows that this is indeed working.
> http://libusbdotnet.svn.sourceforge.net/viewvc/libusbdotnet/trunk/stage/

The above is wrong and the internet archive makes this wrong
information propagated to other places, even to Jan Axelson.
http://www.lvr.com/forum/index.php?topic=296.0

Further testing shows that WinUSB can not be a generic filter.
The above test happened to work because libusb0.sys runs as a filter.
http://libusb.6.n5.nabble.com/Re-libusb-win32-and-WinUSB-as-a-filter-driver-td2642352.html


--
Xiaofan

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel