hidusbfx2 inf file doesn't make sence

NTDEV
1

I am looking at the hidusbfx2 sample in the (7600.16385.0) WDK, but the inf file for the driver seem to contradict the docs.

As I understand, the hidkmdf driver is supposed to be the dummy function driver that forwards the irps to the kmdf hidusbfx2 lower filter driver, according to both the docs and the comments in the inf itself.

However, it seems as if the inf is written so that the hidusbfx2 is the function driver, and the hidkmdf is an upper filter.

From the file:

;
; hidkmdf is the function driver and hidusbfx2 is the lower filter
;
[hidusbfx2.Inst.NT.Services]
AddService = hidkmdf,hidkmdf_Service_Inst,
AddService = hidusbfx2,0x00000002, hidusbfx2_Service_Inst

However, the 0x00000002 flag in hidusbfx2’s AddService, according to MSDN, “Assigns the named service as the PnP function driver”.

And also:

[hidusbfx2_Parameters.AddReg]
HKR,“UpperFilters”,0x00010000,“hidkmdf”

What’s that all about?

I can see that stack-wize hidkmdf still seats above hidusbfx2 as an upper filter, but I have no idea what are the implications of that. Netiher have I actually tested it, so I have no idea if it does the trick :stuck_out_tongue:

2

Why doesn’t it make sense? In the bigger picture, FDO and upper filter (and lower filter) just dictate the order in which you are added to the stack and how the various pieces are layered. Most of the time, the role (fdo, filter) indicates its responsibilities in the stack (power policy ownership, io contract, etc), but not always. In this case, it is the upper filter. The INF could have been written such that hidkmdf was the fdo and hidusbfx2 was a lower filter, the stack would have been built the same. In the end, nothing different, the 2 drivers are layered in the same order

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Saturday, September 19, 2009 8:32 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] hidusbfx2 inf file doesn’t make sence

I am looking at the hidusbfx2 sample in the (7600.16385.0) WDK, but the inf file for the driver seem to contradict the docs.

As I understand, the hidkmdf driver is supposed to be the dummy function driver that forwards the irps to the kmdf hidusbfx2 lower filter driver, according to both the docs and the comments in the inf itself.

However, it seems as if the inf is written so that the hidusbfx2 is the function driver, and the hidkmdf is an upper filter.

From the file:

;
; hidkmdf is the function driver and hidusbfx2 is the lower filter
;
[hidusbfx2.Inst.NT.Services]
AddService = hidkmdf,hidkmdf_Service_Inst,
AddService = hidusbfx2,0x00000002, hidusbfx2_Service_Inst

However, the 0x00000002 flag in hidusbfx2’s AddService, according to MSDN, “Assigns the named service as the PnP function driver”.

And also:

[hidusbfx2_Parameters.AddReg]
HKR,“UpperFilters”,0x00010000,“hidkmdf”

What’s that all about?

I can see that stack-wize hidkmdf still seats above hidusbfx2 as an upper filter, but I have no idea what are the implications of that. Netiher have I actually tested it, so I have no idea if it does the trick :stuck_out_tongue:

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

Thanks for the reply, Doron.

I think that there are actually three issues here:

  1. Wether an arrangement where the shim driver is the upper filter and the wdf driver is the fdo is generally valid? According to you it is, and I take your word for it.

  2. Wether this arrangement is valid for the hidusbfx2 sample unchanged?
    Other than the fact that the docs and comments say that hidkmdf is the fdo and hidusbfx2 is the lower filter, looking at the code also implies that it depends on that. For example, on hidsubfx’s AddDevice handler (from driver.c):

//
// Tell framework this is a filter driver. Filter drivers by default are
// not power policy owners. This works well for this driver because
// HIDclass driver is the power policy owner for HID minidrivers.
//
WdfFdoInitSetFilter(DeviceInit);

Checking that example is somewhat untrivial for me, since I don’t actually have the fx kit.

  1. If the sample would work that way or the other, then why have all the docs say one thing, and then do the other? Was the inf written the other way at some older release, and been changed? And if so why? Is there any benefit for having hidkmdf be the upper filter instead of the fso (or having usbfx be the fso instead of lower filter)?

Once again, thanks for your time.

4

the docs being out of sync with the sample is a bug, please send feedback using the link on the doc page as such. The only advantage I can see for using the fdo+upper filter is that a lot of different companies like to put lower filters on hid stacks, this arrangement makes that a little easier. Hidusbfx2 calls SetFilter b/c in reality, even though it is installed as an fdo, it functionally is a filter (primarily it needs to relinquish power policy ownership)

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Sunday, September 20, 2009 12:06 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] hidusbfx2 inf file doesn’t make sence

Thanks for the reply, Doron.

I think that there are actually three issues here:

  1. Wether an arrangement where the shim driver is the upper filter and the wdf driver is the fdo is generally valid? According to you it is, and I take your word for it.

  2. Wether this arrangement is valid for the hidusbfx2 sample unchanged?
    Other than the fact that the docs and comments say that hidkmdf is the fdo and hidusbfx2 is the lower filter, looking at the code also implies that it depends on that. For example, on hidsubfx’s AddDevice handler (from driver.c):

//
// Tell framework this is a filter driver. Filter drivers by default are
// not power policy owners. This works well for this driver because
// HIDclass driver is the power policy owner for HID minidrivers.
//
WdfFdoInitSetFilter(DeviceInit);

Checking that example is somewhat untrivial for me, since I don’t actually have the fx kit.

  1. If the sample would work that way or the other, then why have all the docs say one thing, and then do the other? Was the inf written the other way at some older release, and been changed? And if so why? Is there any benefit for having hidkmdf be the upper filter instead of the fso (or having usbfx be the fso instead of lower filter)?

Once again, thanks for your time.

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

Thanks