Design Question - Using Global Control Device

Brief Overview:

I have a mini-driver (setup as a filter because of KMDF) that receives HID READ report requests from HID class driver. The filter simply deposits these onto manual dispatch queue and waits until it receives a message when to complete these.

Filter’s pending HID READ report request is completed by using a global control device that is setup as a legacy control device (very similar to toaster example with sideband communication). Note, the control uses serial queue for receiving custom IOCTLs.
Note, that filters that the control device services are sitting in a global collection.

The client sends custom IOCTL with some data (joystick input) to global control device, - the design question I have is what is the best way to complete filter’s pending HID READ reports? Here what I think my options are numbered in the order of my preference:

  1. On receiving IOCTL (joy input from user) on the control device, go through each filter in the collection, get reference to filter’s I/O manual queue where pending HID read report request is and complete it.

  2. On filter setup, create yet another manual queue, - this one used to receive a message from control device to inform when new IOCTL arrived. When new IOCTL arrives on the control device, loop through each filter, create WDFREQUEST, copy user input buffer to my new WDFREQUEST buffer, and forward the new created request to the filter.

  3. On filter setup create a polling timer (for each filter);- when new IOCTL arrives on the control device, copy input buffer to my global control device’s control data (using device context). The polling time on each filter will read global control data and complete the request. (I believe I will need some way to sync read/write access to the global control data)

Any comments what’s the best way of handling this scenario would be greately appreciated.
Thanks,

lk

Is your joystick mini-driver not root enumerated (ie software driver)? I am
confused by your reference to a collection of multiple filters.

If you have multiple instances of this mini-driver then why would you want
to complete reads on them all… you fire a IOCTL from userspace and the OS
sees 5 different joysticks move like synchronized swimmers.

If you are going to have multiple instances of your mini-driver you should
create a raw pdo for each one so that your user mode app can enumerate them
all and choose which joystick it wants to control.

Anyway I think option 1. would work fine if that is what you want.

On Wed, Jun 15, 2011 at 1:35 AM, wrote:

> Brief Overview:
>
> I have a mini-driver (setup as a filter because of KMDF) that receives HID
> READ report requests from HID class driver. The filter simply deposits these
> onto manual dispatch queue and waits until it receives a message when to
> complete these.
>
> Filter’s pending HID READ report request is completed by using a global
> control device that is setup as a legacy control device (very similar to
> toaster example with sideband communication). Note, the control uses serial
> queue for receiving custom IOCTLs.
> Note, that filters that the control device services are sitting in a global
> collection.
>
> The client sends custom IOCTL with some data (joystick input) to global
> control device, - the design question I have is what is the best way to
> complete filter’s pending HID READ reports? Here what I think my options are
> numbered in the order of my preference:
>
> 1. On receiving IOCTL (joy input from user) on the control device, go
> through each filter in the collection, get reference to filter’s I/O manual
> queue where pending HID read report request is and complete it.
>
> 2. On filter setup, create yet another manual queue, - this one used to
> receive a message from control device to inform when new IOCTL arrived. When
> new IOCTL arrives on the control device, loop through each filter, create
> WDFREQUEST, copy user input buffer to my new WDFREQUEST buffer, and forward
> the new created request to the filter.
>
> 3. On filter setup create a polling timer (for each filter);- when new
> IOCTL arrives on the control device, copy input buffer to my global control
> device’s control data (using device context). The polling time on each
> filter will read global control data and complete the request. (I believe I
> will need some way to sync read/write access to the global control data)
>
> Any comments what’s the best way of handling this scenario would be
> greately appreciated.
> Thanks,
>
> lk
>
> —
> 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
>

Agreed. The whole point of the raw pdo is that you get a 1:1 mapping between pdo and filtered device. With a control device and multiple filtered devices, you need to create am addressing scheme on your own to address each filtered device.

d

debt from my phone


From: Daniel Newton
Sent: Tuesday, June 14, 2011 7:29 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Design Question - Using Global Control Device

Is your joystick mini-driver not root enumerated (ie software driver)? I am confused by your reference to a collection of multiple filters.

If you have multiple instances of this mini-driver then why would you want to complete reads on them all… you fire a IOCTL from userspace and the OS sees 5 different joysticks move like synchronized swimmers.

If you are going to have multiple instances of your mini-driver you should create a raw pdo for each one so that your user mode app can enumerate them all and choose which joystick it wants to control.

Anyway I think option 1. would work fine if that is what you want.

On Wed, Jun 15, 2011 at 1:35 AM, > wrote:
Brief Overview:

I have a mini-driver (setup as a filter because of KMDF) that receives HID READ report requests from HID class driver. The filter simply deposits these onto manual dispatch queue and waits until it receives a message when to complete these.

Filter’s pending HID READ report request is completed by using a global control device that is setup as a legacy control device (very similar to toaster example with sideband communication). Note, the control uses serial queue for receiving custom IOCTLs.
Note, that filters that the control device services are sitting in a global collection.

The client sends custom IOCTL with some data (joystick input) to global control device, - the design question I have is what is the best way to complete filter’s pending HID READ reports? Here what I think my options are numbered in the order of my preference:

1. On receiving IOCTL (joy input from user) on the control device, go through each filter in the collection, get reference to filter’s I/O manual queue where pending HID read report request is and complete it.

2. On filter setup, create yet another manual queue, - this one used to receive a message from control device to inform when new IOCTL arrived. When new IOCTL arrives on the control device, loop through each filter, create WDFREQUEST, copy user input buffer to my new WDFREQUEST buffer, and forward the new created request to the filter.

3. On filter setup create a polling timer (for each filter);- when new IOCTL arrives on the control device, copy input buffer to my global control device’s control data (using device context). The polling time on each filter will read global control data and complete the request. (I believe I will need some way to sync read/write access to the global control data)

Any comments what’s the best way of handling this scenario would be greately appreciated.
Thanks,

lk


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

I am implementing a single filter but the reason for the global collection is that currently I have a single control device that the user can access but because of how HID class driver enumerates my filters, I possibly can have more than one.

My understanding of HID is that if I have 2 top level HID collections in my HID report descriptor then I will have 2 device stacks, one per each top level collection, each will have an instance of my filter
(therefore, I end up with 2 filters).

Since there’s 2 filters and single control device that shares global data I would need to communicate with both depeneding on what state has changed in the control data (ex: mouse input, joy input).

I will be honest, I am still a bit confused and I saw some weird examples (this setup being one of them) - I am trying to read upon as much as possible without bothering you guys.

I totally agree, raw PDO is far better solution. Thanks so much, without your input and direction this would take far longer to finish.

For each TLC, hidclass enumerates a child stack . You miniport should be loaded once on the parent, regardless of how many children are enumerated

d

debt from my phone

-----Original Message-----
From: xxxxx@hotmail.com
Sent: Wednesday, June 15, 2011 6:39 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Design Question - Using Global Control Device

I am implementing a single filter but the reason for the global collection is that currently I have a single control device that the user can access but because of how HID class driver enumerates my filters, I possibly can have more than one.

My understanding of HID is that if I have 2 top level HID collections in my HID report descriptor then I will have 2 device stacks, one per each top level collection, each will have an instance of my filter
(therefore, I end up with 2 filters).

Since there’s 2 filters and single control device that shares global data I would need to communicate with both depeneding on what state has changed in the control data (ex: mouse input, joy input).

I will be honest, I am still a bit confused and I saw some weird examples (this setup being one of them) - I am trying to read upon as much as possible without bothering you guys.

I totally agree, raw PDO is far better solution. Thanks so much, without your input and direction this would take far longer to finish.


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

OK, so what you are saying there’s only going to be one mini port driver that sits below the HID class driver regardless of the number of TLCs?

I am still not clear about this child stack, I cannot some how visualize it.
Reading ‘Developing Drivers with the Microsoft Windows Driver Foundation’ I only came across device stack which has the FDO, filters, PDO. In this case this applies to the HID class and my mini-port driver.

Does the child stack sit underneath the device stack?
What is the relationship between device stack and this child stack?

This is the grey area in mind that causes me so much confusion.
If you can also point at resource where I can read more about it I would be greatful.

1 Yea
2 Open device manager and view by connection. Each +node is where there is a child stack. Find your device in the tree and you will see how the TLCs are enumerated.

d

debt from my phone

-----Original Message-----
From: xxxxx@hotmail.com
Sent: Wednesday, June 15, 2011 7:39 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Design Question - Using Global Control Device

OK, so what you are saying there’s only going to be one mini port driver that sits below the HID class driver regardless of the number of TLCs?

I am still not clear about this child stack, I cannot some how visualize it.
Reading ‘Developing Drivers with the Microsoft Windows Driver Foundation’ I only came across device stack which has the FDO, filters, PDO. In this case this applies to the HID class and my mini-port driver.

Does the child stack sit underneath the device stack?
What is the relationship between device stack and this child stack?

This is the grey area in mind that causes me so much confusion.
If you can also point at resource where I can read more about it I would be greatful.


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

Thanks so much.

Do IRPs passed from I/O manager travel also down to the child device stacks? I apoligize if this a rhetorical question?

It is up to the pdo’s implementation. Some fwd to the parent . Some complete io at the pdo.

d

debt from my phone

-----Original Message-----
From: xxxxx@hotmail.com
Sent: Wednesday, June 15, 2011 8:43 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Design Question - Using Global Control Device

Thanks so much.

Do IRPs passed from I/O manager travel also down to the child device stacks? I apoligize if this a rhetorical question?


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

xxxxx@hotmail.com wrote:

I am still not clear about this child stack, I cannot some how visualize it.
Reading ‘Developing Drivers with the Microsoft Windows Driver Foundation’ I only came across device stack which has the FDO, filters, PDO. In this case this applies to the HID class and my mini-port driver.

Does the child stack sit underneath the device stack?
What is the relationship between device stack and this child stack?

The HIDClass driver acts like a bus driver. It creates a PDO for each
TLC, exactly the way that a USB hub creates PDOs for each USB device
that is plugged in. Each of those PDOs is the base of it own driver
stack, which is a child of the HIDClass driver.


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

Aaaaaaaaaaaaaah, I was not aware of this at all. I new nothing of parent/child relationship between one device stack and another.
Thanks for clearing this up.

If I’m not mistaken, the “child” drivers pass IRPs “down” to the parent or
BUS drivers. The bus driver enumerates it’s “bus” which then causes it’s
children to load. Hence, IRP’s passed from the IO manager to the kids are
then passed to the parent sitting below the brood.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Wednesday, June 15, 2011 10:47 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Design Question - Using Global Control Device

Thanks so much.

Do IRPs passed from I/O manager travel also down to the child device stacks?
I apoligize if this a rhetorical question?


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

__________ Information from ESET Smart Security, version of virus signature
database 6212 (20110615) __________

The message was checked by ESET Smart Security.

http://www.eset.com

> 1. On receiving IOCTL (joy input from user) on the control device, go through each filter in the collection, get

reference to filter’s I/O manual queue where pending HID read report request is and complete it.

This is probably the simplest, why do you need any other ways?


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

> This is probably the simplest, why do you need any other ways?

I am still learning, so all the theory I gathered across books, online resources, and samples made me to post my understanding and wanted to see if what I have learned so far makes sense and is not a ‘mumbo-jumbo’.
Clearyl, as I discovered through this post, my understanding of HID devices mini driver was wrong. Since you guys have been writing drivers for so long this stuff is childs play, to me all this stuff is new.
So short answer to your question:
I was looking for best way to achieve what I wanted to do and the question was a bit silly because it is so obvious what is the best way, ofcourse #1 :slight_smile:

Thanks for you feedback.