Theory: buffering in HID class driver?

NTDEV
1

Hi all,

I’m in the process of investigating the inner workings of the HID interface and what the hidclass driver does.

I have several doubts but I think that everything boils down to a few questions. Let’s suppose I have a generic HID device plugged in. It’s not a mouse, joystick, keyboard or any other known input device so the hidclass driver creates just a raw PDO for the user clients to connect to get reports from the device.
The user client process issues a ReadFile on the handle which turns into a read irp. As I understand it, most likely the hidclass driver will create a read irp for the selected collection and send it to the USB stack. Upon completion from the lower USB drivers, the hidclass will complete the request and the user process will return from the read (or set the event if asynch read) and get the report in the buffer.

Now, if the user mode client doesn’t go immediately back into the read, I’d expect some buffering to happen at some level in the USB stack to prevent report loss. After all you never know when the user client will be scheduled again and therefore when it will be able to generate another read irp to be completed.

So basically, is this picture true? If so, where does the buffering happen? what’s the limit of it?

On top of this, the raw PDO accepts multiple user clients and they all get a copy of the current report. However, for the reason explained above, they may be at different stages of their queue. So, does the HID driver implements this buffering on a per client basis (or one big buffer with multiple indexes)?

If I had to offer something along these lines (multiple clients, queuing) on a wdf driver, is there anything that the framework can offer to implement this in an easy way?

Thanks in advance,
Stra

2

HIDclass continuously reads from the usb device, regardless of what the UM client has done (opening a handle, sending a read, etc). remember that one buffer from the device can go to any of the reports/TLCs on the device, so reading of the underlying data cannot be tied to any user mode i/o (in)activity. When you open a handle to a HID, a ring buffer and an io queue is created. When there is data for the particular hid, each active ring buffer gets its own copy of the data. This means that app1 cannot affect the state of app2 b/c it is reading more slowly than app2. If there is no data in the ring buffer when a read arrives, it is placed in the handle’s io queue (and when subsequent data arrives, the irp is dequeued and completed). HidD_SetNumInputBuffers can change the size of the buffer (HidD_GetNumInputBuffers gives you the current size).

Now, does KMDF help here? Yes in terms of building blocks. You can create a WDFQUEUE read queue when you process a create and parent the queue with the WDFFILEOBJECT. You would have to keep the list of active WDFFIELOBJECTs on each raw pdo. If you have a usb device, you can use the KMDF continuous reader to always read data from the device. managing the ring buffer and when to queue/dequeue a request would be implemented in your driver.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, December 13, 2007 3:55 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Theory: buffering in HID class driver?

Hi all,

I’m in the process of investigating the inner workings of the HID interface and what the hidclass driver does.

I have several doubts but I think that everything boils down to a few questions. Let’s suppose I have a generic HID device plugged in. It’s not a mouse, joystick, keyboard or any other known input device so the hidclass driver creates just a raw PDO for the user clients to connect to get reports from the device.
The user client process issues a ReadFile on the handle which turns into a read irp. As I understand it, most likely the hidclass driver will create a read irp for the selected collection and send it to the USB stack. Upon completion from the lower USB drivers, the hidclass will complete the request and the user process will return from the read (or set the event if asynch read) and get the report in the buffer.

Now, if the user mode client doesn’t go immediately back into the read, I’d expect some buffering to happen at some level in the USB stack to prevent report loss. After all you never know when the user client will be scheduled again and therefore when it will be able to generate another read irp to be completed.

So basically, is this picture true? If so, where does the buffering happen? what’s the limit of it?

On top of this, the raw PDO accepts multiple user clients and they all get a copy of the current report. However, for the reason explained above, they may be at different stages of their queue. So, does the HID driver implements this buffering on a per client basis (or one big buffer with multiple indexes)?

If I had to offer something along these lines (multiple clients, queuing) on a wdf driver, is there anything that the framework can offer to implement this in an easy way?

Thanks in advance,
Stra

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

3

BTW, Doron, you just described how GPS driver supporting multiple virtual COM posts discussed sooner today could behave. In principle, GPS device can be also taken as HID because coordinates change according to human move :slight_smile:

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, December 14, 2007 1:25 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Theory: buffering in HID class driver?

HIDclass continuously reads from the usb device, regardless of what the UM client has done (opening a handle, sending a read, etc). remember that one buffer from the device can go to any of the reports/TLCs on the device, so reading of the underlying data cannot be tied to any user mode i/o (in)activity. When you open a handle to a HID, a ring buffer and an io queue is created. When there is data for the particular hid, each active ring buffer gets its own copy of the data. This means that app1 cannot affect the state of app2 b/c it is reading more slowly than app2. If there is no data in the ring buffer when a read arrives, it is placed in the handle’s io queue (and when subsequent data arrives, the irp is dequeued and completed). HidD_SetNumInputBuffers can change the size of the buffer (HidD_GetNumInputBuffers gives you the current size).

Now, does KMDF help here? Yes in terms of building blocks. You can create a WDFQUEUE read queue when you process a create and parent the queue with the WDFFILEOBJECT. You would have to keep the list of active WDFFIELOBJECTs on each raw pdo. If you have a usb device, you can use the KMDF continuous reader to always read data from the device. managing the ring buffer and when to queue/dequeue a request would be implemented in your driver.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, December 13, 2007 3:55 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Theory: buffering in HID class driver?

Hi all,

I’m in the process of investigating the inner workings of the HID interface and what the hidclass driver does.

I have several doubts but I think that everything boils down to a few questions. Let’s suppose I have a generic HID device plugged in. It’s not a mouse, joystick, keyboard or any other known input device so the hidclass driver creates just a raw PDO for the user clients to connect to get reports from the device.
The user client process issues a ReadFile on the handle which turns into a read irp. As I understand it, most likely the hidclass driver will create a read irp for the selected collection and send it to the USB stack. Upon completion from the lower USB drivers, the hidclass will complete the request and the user process will return from the read (or set the event if asynch read) and get the report in the buffer.

Now, if the user mode client doesn’t go immediately back into the read, I’d expect some buffering to happen at some level in the USB stack to prevent report loss. After all you never know when the user client will be scheduled again and therefore when it will be able to generate another read irp to be completed.

So basically, is this picture true? If so, where does the buffering happen? what’s the limit of it?

On top of this, the raw PDO accepts multiple user clients and they all get a copy of the current report. However, for the reason explained above, they may be at different stages of their queue. So, does the HID driver implements this buffering on a per client basis (or one big buffer with multiple indexes)?>

If I had to offer something along these lines (multiple clients, queuing) on a wdf driver, is there anything that the framework can offer to implement this in an easy way?

Thanks in advance,
Stra

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

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

4

Yes, exactly so. The pattern of continuously reading data and then redistributing it to multiple clients is applicable all over the devices space.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, December 13, 2007 4:46 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Theory: buffering in HID class driver?

BTW, Doron, you just described how GPS driver supporting multiple virtual COM posts discussed sooner today could behave. In principle, GPS device can be also taken as HID because coordinates change according to human move :slight_smile:

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, December 14, 2007 1:25 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Theory: buffering in HID class driver?

HIDclass continuously reads from the usb device, regardless of what the UM client has done (opening a handle, sending a read, etc). remember that one buffer from the device can go to any of the reports/TLCs on the device, so reading of the underlying data cannot be tied to any user mode i/o (in)activity. When you open a handle to a HID, a ring buffer and an io queue is created. When there is data for the particular hid, each active ring buffer gets its own copy of the data. This means that app1 cannot affect the state of app2 b/c it is reading more slowly than app2. If there is no data in the ring buffer when a read arrives, it is placed in the handle’s io queue (and when subsequent data arrives, the irp is dequeued and completed). HidD_SetNumInputBuffers can change the size of the buffer (HidD_GetNumInputBuffers gives you the current size).

Now, does KMDF help here? Yes in terms of building blocks. You can create a WDFQUEUE read queue when you process a create and parent the queue with the WDFFILEOBJECT. You would have to keep the list of active WDFFIELOBJECTs on each raw pdo. If you have a usb device, you can use the KMDF continuous reader to always read data from the device. managing the ring buffer and when to queue/dequeue a request would be implemented in your driver.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, December 13, 2007 3:55 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Theory: buffering in HID class driver?

Hi all,

I’m in the process of investigating the inner workings of the HID interface and what the hidclass driver does.

I have several doubts but I think that everything boils down to a few questions. Let’s suppose I have a generic HID device plugged in. It’s not a mouse, joystick, keyboard or any other known input device so the hidclass driver creates just a raw PDO for the user clients to connect to get reports from the device.
The user client process issues a ReadFile on the handle which turns into a read irp. As I understand it, most likely the hidclass driver will create a read irp for the selected collection and send it to the USB stack. Upon completion from the lower USB drivers, the hidclass will complete the request and the user process will return from the read (or set the event if asynch read) and get the report in the buffer.

Now, if the user mode client doesn’t go immediately back into the read, I’d expect some buffering to happen at some level in the USB stack to prevent report loss. After all you never know when the user client will be scheduled again and therefore when it will be able to generate another read irp to be completed.

So basically, is this picture true? If so, where does the buffering happen? what’s the limit of it?

On top of this, the raw PDO accepts multiple user clients and they all get a copy of the current report. However, for the reason explained above, they may be at different stages of their queue. So, does the HID driver implements this buffering on a per client basis (or one big buffer with multiple indexes)?>

If I had to offer something along these lines (multiple clients, queuing) on a wdf driver, is there anything that the framework can offer to implement this in an easy way?

Thanks in advance,
Stra

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

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

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

5

Michal Vodicka wrote:
> In principle, GPS device can be also taken as HID
> because coordinates change according to human move :slight_smile:

[fun]
In the future we might use GPS as a mouse replacement.

This would definitely add a “workout” element to the OS – no more
complaints about people not getting enough exercise by using editors or
word processors, and also much fewer RSI issues… :slight_smile:
[/fun]

6

You would either need a very large monitor or something surpassing military grade accuracy from the GPS data :slight_smile:

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Friday, December 14, 2007 2:08 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Theory: buffering in HID class driver?

Michal Vodicka wrote:
> In principle, GPS device can be also taken as HID
> because coordinates change according to human move :slight_smile:

[fun]
In the future we might use GPS as a mouse replacement.

This would definitely add a “workout” element to the OS – no more
complaints about people not getting enough exercise by using editors or
word processors, and also much fewer RSI issues… :slight_smile:
[/fun]

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

7

Oh my … just think … the sun decides to burp, GPS tanks, and everyone’s
mouse quits working, followed by MILLIONS of phone calls to tech support …
which tanks the phone system …

:slight_smile:

–
The personal opinion of
Gary G. Little

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
You would either need a very large monitor or something surpassing military
grade accuracy from the GPS data :slight_smile:

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Friday, December 14, 2007 2:08 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Theory: buffering in HID class driver?

Michal Vodicka wrote:
> In principle, GPS device can be also taken as HID
> because coordinates change according to human move :slight_smile:

[fun]
In the future we might use GPS as a mouse replacement.

This would definitely add a “workout” element to the OS – no more
complaints about people not getting enough exercise by using editors or
word processors, and also much fewer RSI issues… :slight_smile:
[/fun]

—
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

8

Standalone monitors are obsolete :slight_smile: PDA, mobile phone or glasses with virtual screen. GPS usually doesn’t work inside buildings so it’d be necessary anyway :slight_smile:

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Peter Wieland[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, December 14, 2007 9:40 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Theory: buffering in HID class driver?

You would either need a very large monitor or something surpassing military grade accuracy from the GPS data :slight_smile:

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Friday, December 14, 2007 2:08 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Theory: buffering in HID class driver?

Michal Vodicka wrote:
> In principle, GPS device can be also taken as HID
> because coordinates change according to human move :slight_smile:

[fun]
In the future we might use GPS as a mouse replacement.

This would definitely add a “workout” element to the OS – no more
complaints about people not getting enough exercise by using editors or
word processors, and also much fewer RSI issues… :slight_smile:
[/fun]

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

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

9

Hagen Patzke wrote:

In the future we might use GPS as a mouse replacement.

Hey, why not, it’s already been used as a paint program:

http://www.gpsdrawing.com/gallery.htm

I particularly like this one:

http://www.gpsdrawing.com/gallery/land/usa/az/spaceinvaders.html

Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)

10

> Now, if the user mode client doesn’t go immediately back into the read, I’d
expect

some buffering to happen at some level in the USB stack to prevent report
loss.

I have doubts that HIDCLASS does this, probably this is done in USBHID.SYS

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

11

Doubt no more ;). Hidclass does buffer data from the device (up to N packets which is configurable). Hidusb just translates HID generic I/O to transport specific I/O.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Friday, December 14, 2007 1:59 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Theory: buffering in HID class driver?

Now, if the user mode client doesn’t go immediately back into the read, I’d
expect
some buffering to happen at some level in the USB stack to prevent report
loss.

I have doubts that HIDCLASS does this, probably this is done in USBHID.SYS

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

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