Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting... Please check out the Community Guidelines in the
Announcements and Administration Category.

Usermode equivalent available?

OSR_Community_UserOSR_Community_User Posts: 110,218
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?

Comments

  • Doron_HolanDoron_Holan Posts: 10,360
    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 <xxxxx@microsoft.com> 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
  • AEvansAEvans Posts: 7
    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.
  • <quote>
    We develop the KMDF based libusbk.sys to get rid of the above limitations...
    </quote>

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Doron_HolanDoron_Holan Posts: 10,360
    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?


    We develop the KMDF based libusbk.sys to get rid of the above limitations...


    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, <xxxxx@osr.com> wrote:
    > <quote>
    > We develop the KMDF based libusbk.sys to get rid of the above limitations...
    > </quote>
    >
    > 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
  • Mike_KempMike_Kemp Posts: 291
    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 :-(

    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?


    <quote>
    We develop the KMDF based libusbk.sys to get rid of the above limitations...
    </quote>

    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 <xxxxx@microsoft.com> 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
  • <quote>
    Does this mean that UMDF now supports ISOCH on USB? (I believe it used not
    to).
    </quote>

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

    Sorry for any misunderstanding,

    Peter
    OSR

    Peter Viscarola
    OSR
    @OSRDrivers

  • Doron_HolanDoron_Holan Posts: 10,360
    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
  • Tim_RobertsTim_Roberts Posts: 12,623
    Xiaofan Chen wrote:
    > 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.

    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Doron_HolanDoron_Holan Posts: 10,360
    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, <xxxxx@microsoft.com> 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
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!