Windows Drivers - USB Driver Development

Posted August 12, 2003

Chat Date: July 18, 2003

Please note: Portions of this transcript have been edited for clarity

Chat Participants:

• Fred Bhesania, Program Manager on the USB team
• Mark Maszak, Test Lead for the Windows USB team
• Randy Aull, Driver Development Engineer on the windows team
• Eric Sassaman, Program manager, Product Support Services

We know that thousands of people read these transcripts on MSDN, but we would like to know how useful they are to you. Please send us an email at ATEO@Microsoft.com and tell us how this information or redirection to other information sources helped you do your job.

Moderator: Eric (Microsoft)
Welcome to today's Chat. Our topic is Windows Drivers - USB Driver Development. Questions, comments, and suggestions are welcome. Let's introduce our hosts for today!

Host: Fred (Microsoft)
Good day everyone... my name is Fred Bhesania and I am the program manager on the USB team. I would be happy to answer any questions to the best of our ability. Thank you.

Host: Mark (Microsoft)
Hi, I'm Mark Maszak, Test Lead for the Windows USB team.

Host: Randy (Microsoft)
Hi, I'm Randy Aull and I am a driver development engineer on the windows team. I own HID, smartcards, and several other USB client drivers.

Moderator: Eric (Microsoft)
Welcome everyone, let's get started!

Host: Fred (Microsoft)
Q: Any timeframe for highs-peed support in the usbaudio stack?

A: Thank you for asking this question. The USB audio stack today is tuned for full speed devices. e USB DWG (Device Working Group) for audio is working on machine changes in the USB audio stack. Microsoft is participating in these sessions and attending the DWG meetings. The core USB team however does support a feature called periodic ISOC support. It will be available shortly and will allow high-speed USB 2.0 audio devices to stream data at the rate the current USB audio driver expects. This feature (periodic ISOC) will made available in a future service pack of Windows XP and later operating systems.

Host: Randy (Microsoft)
Q: How do I watch Driver events for enabling and disabling devices?

A: From user-mode applications, you can call RegisterDeviceNotification in order to get windows messages for device changes such as arrival or removal.

Host: Randy (Microsoft)
Q: I am developing a HID compliant front-panel for a custom device, what are some SW utilities I can use to test the HID compliance?

A: There is a tool in the DDK called HClient which allows you to manually test your HID device. There is also a HID portion in the USB WHQL tests here: https://www.microsoft.com/whdc/hwtest/device/default.mspx?area=usb

Host: Randy (Microsoft)
Q: Does this API (RegisterDeviceNotification) also notifies the DISABLE and ENABLE EVENT?

A: It notifies the application of device arrival, query removal, removal, etc. You may be able to infer from the query removal notification that it was a disable instead of a surprise removal. If you are developing software client drivers for USB devices, what has been the most frustrating/difficult experience that the Windows team can help improve.

Host: Eliyas (Microsoft)
A: This is follow up to Randy's response. If you register a notification on the handle, you will get DBT_DEVICEREMOVECOMPLETE message when the device is surprise-removed. Follow the Src\general\toaster\exe\notify sample.

Host: Eliyas (Microsoft)
Q: Do you know a simple Demo in the DDK which uses the RegisterDeviceNotification?

A: Yes, the Notify sample that I mentioned earlier demonstrates how to handle all the PNP events in an application.

Host: Eliyas (Microsoft)
Q: Mabye if I knew what ddk was?

A: Check this website <https://www.microsoft.com/whdc/ddk/winddk.mspx>

Host: Fred (Microsoft)
Q: Not really a driver development questions, but is a MC++ dll wrapper a respectable way of exposing "WinAPIs for USB" to other .NET languages?

A: Microsoft is considering developing a module to allow user-mode application to talk to a USB function via user-mode windows API. This project is still in the development/investigation phase. We do not know how it will interact with .NET languages just yet. If we do develop and start a beta process for such a driver and decide to ship it in a product, would you be interested in participating in the beta program? If so, please send an email to msusb2@microsoft.com with the following within 7 days:

1. Subject --> "Volunteer : Windows USB Driver Beta Participation"

2. Body contains --> "Persons's Name : XYZ ; Company Name: XYZ; Title: XYZ; Email : XYZ@xxx.com".

Thank you.

Host: Glen (Microsoft)
Q: How do you develop a usb driver, proggramming language, electronics?

A: If you are looking for resources on developing device hardware, one place you might want to look is https://www.usb-by-example.com

Host: Eliyas (Microsoft)
Q: For utility apps, should usbioctl.h user-mode ioctls be migrated to those in usbuser.h?

A: Both usbioctl.h and usbuser.h header files are available for usermode application both in the DDK and SDK. You don't have to migrate anything. In general, you shouldn't change header files

Host: Randy (Microsoft)
Q: The problem that I am having is relating to how the packets are sent and speed issues. Over the USB bus there are 4 different ways of transmitting data, how do you choose which one you use, and how do you set the packet size?

A: I am assuming that you are talking about endpoint types. The device specifies the type of each endpoint. Control endpoints are generally for controlling/configuring the device. All USB devices have one of these at endpoint 0. Interrupt endpoints are good for devices that periodically transfer data. There is a guaranteed but limited bandwidth with these endpoints. Bulk endpoints are for transferring data that doesn't require strict timing. There is no guaranteed bandwidth, but in practice it is usually greater than that of interrupt endpoints. Isochronous endpoints are for things like streaming audio and video that requires strict timing at the expense of data integrity. There are many books that explain this in detail.

Host: Fred (Microsoft)
Q: I want to control accessing the USB port.For eg. if anybody tries to copy any data from my machine to any USB device i should be able to control it through some s/w

A: There is no easy way to limit enumeration to specific device classes and user privileges easily. You can disable the ports to prevent all enumeration on a USB host controller. There may be third party software that may allow you to do this today though.

Host: Randy (Microsoft)
Q: Marco: Thanks, how do I specify the endpoint to connect to?

A: You might want to read Walter Oney's book https://www.amazon.com/exec/obidos/tg/detail/-/0735618038/002-1753629-5857610?vi=glance

Host: Randy (Microsoft)
Q: I use CreateFile to connect, and then WriteFile to write, I don't see anywhere I can specify the endpoint to contact. HidD_GetCaps reports the maximum report byte length is 8, but you can send up to 64 per packet with any mode other than CONTROL.

A: So it sounds like your device is already a HID device, so you talk with it through the HID APIs. You don't need to specify any endpoints as the HID specification defines these. The report byte length is specified by the HID report descriptor of the device, not by the endpoint limitations.

Host: Fred (Microsoft)
Q: Hi Fred :Also please tell me from where(in Microsoft site or MSDN) i can get the support or help to develop the program to lock the USB port.

A: Unfortunately this infrastructure doesn’t exist in Windows today, so there is nothing that I can point you to. If you do want to develop filter drivers or manipulate INFs, you should kindly refer to the Windows XP Driver Development Kit (DDK) for information. Sorry, there is no silver bullet.

Host: Eliyas (Microsoft)
Q: When using usbioctl.h from the latest DDKs it issues a warning: "using obsolete header file usbioctl.h". So it is not going away?

A: You can ignore the warning for the time being. We wanted to obsolete the header file and move the relevant definition to usbuser.h but we never completed because of other dependency issues. Hopefully, in the next release we will clean that up.

Moderator: Eric (Microsoft)
Thanks for joining us today and thanks for the questions. It's time for us to go now.

For further information on this topic please visit the following:

Windows Drivers Transcripts: Read the archive

Website: Visit the Community Home Page for Windows Platform Development

Top of page