Usermode equivalent available?

Hi,

is there a usermode equivalent for IOCTL_INTERNAL_USB_RESET_PORT or IOCTL_INTERNAL_USB_CYCLE_PORT? Is there maybe some library exporting any function that has a gate to these IOCTLs from usermode? Maybe i can drop something similar by opening a handle to a device from usermode? Would be a DIF_PROPERTYCHANGE have the same effect?

Not exposed to user mode. Why do you want it? What driver controls the device?

d

debt from my phone


From: xxxxx@arcor.de
Sent: 4/11/2012 9:20 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Usermode equivalent available?

Hi,

is there a usermode equivalent for IOCTL_INTERNAL_USB_RESET_PORT or IOCTL_INTERNAL_USB_CYCLE_PORT? Is there maybe some library exporting any function that has a gate to these IOCTLs from usermode? Maybe i can drop something similar by opening a handle to a device from usermode? Would be a DIF_PROPERTYCHANGE have the same effect?


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

On Thu, Apr 12, 2012 at 12:28 PM, Doron Holan wrote:
> Not exposed to user mode. Why do you want it? What driver controls the
> device?

Just wondering why not? Some user want to have the ability to reset the
device from user mode (eg: the device may be buggy).

This is identified as No 1 limitation of WinUSB backend of libusb-1.0
Windows implementation.

Reference: http://www.libusb.org/wiki/windows_backend
1) WinUSB cannot be used to send an actual reset command to an
USB device. This is a limitation of the Microsoft driver.

2) WinUSB cannot be used to set a device configuration that is
different from the default one. This is a limitation of the Microsoft driver.

3) WinUSB does not support multiple concurrent applications
(as per the ​MSDN documenation).

4) WinUSB does not support isochronous transfers.

5) When using interface control requests (LIBUSB_RECIPIENT_INTERFACE),
WinUSB overrides the low byte of wIndex with the destination interface.
This is a limitation of the Microsoft driver. See ​here for more details.
http://www.lvr.com/forum/index.php?topic=331

We develop the KMDF based libusbk.sys to get rid of the above
limitations other than 2) which is a KMDF limitation.


Xiaofan

According to the thread linked below, a DIF_PROPERTYCHANGE with a StateChange of DICS_PROPCHANGE is enough to make a USB device recycle and be re-enumerated.

http://forums.codeguru.com/showthread.php?t=418183

However I’m not sure if this will cause the root hub driver to properly cycle the device (like the CYCLE_PORT ioctl does) or just to stop the FDO for the device and restart it.

Hmmm… if people *really* want these things (ISO transfers, multiple simultaneous users) aren’t they better served by writing a UMDF driver? I mean, we started with operating systems where every application had to know how to program the disk controller to do I/O… we’ve moved a bit beyond this stage by now. If you have a specific niche device that you want to control with a specific application, then WinUSB is a pretty cool solution. OTOH, if you want to take full control and make that device available to multiple applications simultaneously, isn’t the overall control of the device better placed in a central location, with applications using an abstract interface based on Read/Write/Ioctl and the applications relieved of the burden of knowing precisely how the device works?

Peter
OSR

Btw a usb umdf driver uses winusb, so any (perceived) limitations winusb, so does umdf EXCEPT for multiple app access.

d

debt from my phone


From: xxxxx@osr.com
Sent: 4/12/2012 6:42 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Usermode equivalent available?

Hmmm… if people *really* want these things (ISO transfers, multiple simultaneous users) aren’t they better served by writing a UMDF driver? I mean, we started with operating systems where every application had to know how to program the disk controller to do I/O… we’ve moved a bit beyond this stage by now. If you have a specific niche device that you want to control with a specific application, then WinUSB is a pretty cool solution. OTOH, if you want to take full control and make that device available to multiple applications simultaneously, isn’t the overall control of the device better placed in a central location, with applications using an abstract interface based on Read/Write/Ioctl and the applications relieved of the burden of knowing precisely how the device works?

Peter
OSR


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

On Thu, Apr 12, 2012 at 9:41 PM, wrote:
>


>
> Hmmm… if people really want these things (ISO transfers, multiple
> simultaneous users) aren’t they better served by writing a UMDF driver?
> I mean, we started with operating systems where every application had
> to know how to program the disk controller to do I/O… we’ve moved a bit
> beyond this stage by now.

I am not a driver expert and do not know much about UMDF.
But libusbK is just like WinUSB to enable
user mode “driver”, similarly for libusb-win32.

Introduction to libusbk.
http://libusbk.sourceforge.net/UsbK3/usbk_about.html

Comparisons of libusbk.sys, libusb0.sys and winusb.sys
http://libusbk.sourceforge.net/UsbK3/usbk_comparisons.html

A dedicated UMDF driver may be better but just like WinUSB,
libusbK can be a good alternative for many applications.

> If you have a specific niche device that you want to control with
> a specific application, then WinUSB is a pretty cool solution.

Yes we agree. But some users just need a little bit more.
Some users want to have isoc transfer even though it
is a very small minority.
Eg: https://github.com/OpenKinect/libfreenect/tree/master/platform/windows

Some users want reset.
http://libusb.6.n5.nabble.com/Vista-and-port-cycling-td3407163.html
http://sourceforge.net/mailarchive/message.php?msg_id=27595508

libusbk library supports libusb0.sys, libusbk.sys and winusb.sys actually.
The API kind of provide libusbK specific API and WinUSB API
at the same time. We know that WInUSB will be the de facto
generic USB drivers so we want to support it and provides a bit
more ease-to-use API to end users. We are kind of targeting Jungo
Windriver USB users as well if you look at the API.
http://libusbk.sourceforge.net/UsbK3/modules.html

> OTOH, if you want to take full control and make that device available
> to multiple applications simultaneously, isn’t the overall control
> of the device better placed in a central location, with applications
> using an abstract interface based on Read/Write/Ioctl and the applications
> relieved of the burden of knowing precisely how the device works?

I think you have a good point here. I myself am a bit fuzzy
about the multiple application scenario. But from the history
of libusb related project, it seems there are successful use cases
as well.

For high performance applications, probably a dedicated kernel
driver is still better. But there are probably not many good driver
developer (KMDF or UMDF) out there…,


Xiaofan

Hi Peter

Does this mean that UMDF now supports ISOCH on USB? (I believe it used not
to). That’s good news as I mostly work in audio, so ISOCH is pretty
important. Luckily I have avoided drivers for a while now, but you never
know when the next one will loom. My desire to fiddle in the kernel recedes
with every post I enjoy reading here…

This recent document suggests not though :frowning:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff540215(v=vs.85).aspx

“A UMDF-based client driver is not an option for USB devices that support
isochronous endpoints.”

Mike

>>>>

The contents of this email are CONFIDENTIAL and do not form a basis for
contract.
----- Original Message -----
From: xxxxx@osr.com
To: Windows System Software Devs Interest List
Sent: Thursday, April 12, 2012 2:41 PM
Subject: RE:[ntdev] Usermode equivalent available?

Hmmm… if people *really* want these things (ISO transfers, multiple
simultaneous users) aren’t they better served by writing a UMDF driver? I
mean, we started with operating systems where every application had to know
how to program the disk controller to do I/O… we’ve moved a bit beyond
this stage by now. If you have a specific niche device that you want to
control with a specific application, then WinUSB is a pretty cool solution.
OTOH, if you want to take full control and make that device available to
multiple applications simultaneously, isn’t the overall control of the
device better placed in a central location, with applications using an
abstract interface based on Read/Write/Ioctl and the applications relieved
of the burden of knowing precisely how the device works?

Peter
OSR


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

On Thu, Apr 12, 2012 at 10:09 PM, Doron Holan wrote:
> Btw a usb umdf driver uses winusb, so any? (perceived) limitations winusb,
> so does umdf EXCEPT for multiple app access.
>

Good point. Just wondering why that difference between
WinUSB and UMDF if USB UMDF driver uses winusb.


Xiaofan

Not to the best of my knowledge, no. I did not mean to imply that.

Sorry for any misunderstanding,

Peter
OSR

The difference is abstraction. For a umdf driver usb is just a transport. It can transform the io interface into something else, like wpd or sensor security device. It can also enable many clients. A raw winusb device is purely app to device, 1:1 with usb as the only abstraction, not the io interface.

d

debt from my phone


From: Xiaofan Chen
Sent: 4/12/2012 7:16 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Usermode equivalent available?

On Thu, Apr 12, 2012 at 10:09 PM, Doron Holan wrote:
> Btw a usb umdf driver uses winusb, so any (perceived) limitations winusb,
> so does umdf EXCEPT for multiple app access.
>

Good point. Just wondering why that difference between
WinUSB and UMDF if USB UMDF driver uses winusb.


Xiaofan


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

Xiaofan Chen wrote:

  1. When using interface control requests (LIBUSB_RECIPIENT_INTERFACE),
    WinUSB overrides the low byte of wIndex with the destination interface.
    This is a limitation of the Microsoft driver.

One can also argue that this is a security measure. The USB spec
requires that the low byte of wIndex be set to the interface number when
the recipient is set to “interface”. Devices that use that field for
other purposes are broken.


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

1 it is a privileged operation. Even if the user was an admin this can directly effect other stacks in a composite device

2 windows as a whole from a windows provided class driver pov only supports the default config

3 correct. There is no way to know what is stateful and what is not. If you want concurrent app access, layer a umdf driver stack on winusb

4 yup. Neither does kmdf natively. The market for isoch support is extremely small, difficult to argue the cost benefit

5 this is so you only target your interface on a composite device. Letting a user mode stack manipulate a sibling interface is bad security and encapsulation, no?

d

On Fri, Apr 13, 2012 at 4:58 AM, wrote:

Doron’s response to the 5 WinUSB limitation pointed out by
Pete Batard (author of libusb-1.0 WinUSB backend, author
of libwdi).
http://www.libusb.org/wiki/windows_backend#KnownRestrictions

> 1 it is a privileged operation. Even if the user was an admin
> this can directly effect other stacks in a composite device

Yes I agree. But there are applications which need this
one and not targeting composite device.

> 2 windows as a whole from a windows provided class driver
> pov only supports the default config

Again this is not a major issue. libusbk.sys (based on
kmdf) has the same limitation. libusb0.sys (wdm) support
this.

> 3 correct. There is no way to know what is stateful and what
> is not. If you want concurrent app access, layer a umdf driver
> stack on winusb

Okay.

> 4 yup. Neither does kmdf natively. The market for isoch
> support is extremely small, difficult to argue the cost benefit

I agree this is probably difficult to argue for the cost benefit
inside Microsoft. But again there are users who want this
feature. libusb0.sys has limit support of isochronous transfer
support. libusbk.sys aims to have better isochronous transfer
support. There are applications out there (some related to
audio) who want this feature.

> 5 this is so you only target your interface on a composite
> device. Letting a user mode stack manipulate a sibling interface
> is bad security and encapsulation, no?
>

I agree with you. And as per Tim, the device can be considered
as a broken device.

On the support of broken USB device, KMDF is less forgiven
(so does winusb and libusbk.sys) than wdm (say libusb0.sys).
But I think this is a good thing that Microsoft breaks non-compliant
USB device more and more (XP is too forgiven).


Xiaofan