Duh! I should have thought of that. And if my device has multiple responses to a single user app WriteFile request the order in which the driver completes the queued IOCTL_HID_READ_REPORTs will determine the order in which they are returned in response to the user apps subsequent ReadFile requests, correct?
Now in this case if the user apps second or any subsequent ReadFile request is received by the framework before the driver has completed an additional IOCTL_HID_READ_REPORT, the framework should return a status PENDING to the user app until a completed request if available, correct?
Hidclass manages the state where you complete an IOCTL_HID_REPORT and the app doesn’t have a pending read by maintaining a ring buffer of reports. When the read comes in, the oldest report is copied out of the ring.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, February 29, 2016 8:24 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Where are hidusb and hidparse in the driver hiearchy in relation to mshidumdf and a hid minidriver?
Duh! I should have thought of that. And if my device has multiple responses to a single user app WriteFile request the order in which the driver completes the queued IOCTL_HID_READ_REPORTs will determine the order in which they are returned in response to the user apps subsequent ReadFile requests, correct?
Now in this case if the user apps second or any subsequent ReadFile request is received by the framework before the driver has completed an additional IOCTL_HID_READ_REPORT, the framework should return a status PENDING to the user app until a completed request if available, correct?
—
NTDEV is sponsored by OSR
Visit the list online at: https:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:
To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>
My user app issues asynchronous Read requests, so what status does it get back from the framework if a new response from the device/driver is not yet available?
Hidclass handles this, not your miniport driver. Hidclass does not use WDF, it is a WDM driver, so there is no framework response. Hidclass responds in this case with marking the request pending and returning STATUS_PENDING.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, February 29, 2016 9:14 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Where are hidusb and hidparse in the driver hiearchy in relation to mshidumdf and a hid minidriver?
My user app issues asynchronous Read requests, so what status does it get back from the framework if a new response from the device/driver is not yet available?
—
NTDEV is sponsored by OSR
Visit the list online at: https:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:
To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>
xxxxx@gmail.com wrote:
I would like to ask a question related to the vhidmini2 sample based virtual driver that I created previously. After much experimentation I concluded that the driver never receives user app ReadFile requests, even though it’s able to return responses to the user app. It appears that the framework periodically sends IOCTL_HID_READ_REPORT messages to the driver, regardless of whether the user app has issued a ReadFile request or even if the app is running.
If you are a keyboard or mouse device, then you are automatically sucked
in to the pool of input devices, and the operating system will ask you
for updates just like it does for other devices.
If you are not keyboard or mouse, then you shouldn’t see requests unless
a user app opens the device.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Doron,
Thanks for the clarification. So the user app does get STATUS_PENDING back but it comes from the HIDClass driver not the framework. Got it.
Tim,
My device is not a mouse or keyboard. However, the vhidmini2 sample driver model, on which I built the driver, results in a driver that receives periodic IOCTL_HID_READ_REPORTs from the framework regardless of whether the user app issued any ReadFile requests or is even running (and there are no other apps running that use this device). I discovered this after countless hours of experimentation. I concluded that there is no correlation between these IOCTL_HID_READ_REPORTs and the user app ReadFile requests. On the other hand, user app WriteFile requests do correlate to IOCTL_HID_WRITE_REPORT events in the driver.
Randy