WdfRequest and HID report

OSR_Community_User · January 20, 2011, 8:41am

Dear,

I’m trying from a lower filter driver to generate a HID report to create a “software mouse movement”. Presently I’m able to alter the form of a HID report by modifying the buffer of the WDFREQUEST object in the completion routine.

What I’d like to do is create one, without sending any request to the driver below me in the stack.

Tell me if I’m wrong but I understand that :

Windows issue a IoRead request that goes through my filter, to the hardware (I’m calling FilterForwardRequestWithCompletionRoutine in my filter driver).
When the hardware has data to send back to the computer it bubbles up the request all the way up, with the data in it.
Then the completion routine is called in my filter.
And finally WdfRequestComplete continue de forward the response to the driver above till it reaches Windows.

I’m not sure to be right on this, could you please confirm ?

I did try to call in my IoRead callback :

WdfRequestComplete(Request, status);
return;

instead of

FilterForwardRequestWithCompletionRoutine(Request, WdfDeviceGetIoTarget(device));
return;

Hoping this would just send windows an empty report without going down to the hardware but I ended up freezing all mice plugged (even the one with no filter driver at all). Windows did not crash though.

Can you help me sort this out ? maybe clarifying some of the concept and pointing to a sample in the wdk will do.

Best regards,

Tim_Roberts · January 20, 2011, 12:32pm

xxxxx@gmail.com wrote:

I’m trying from a lower filter driver to generate a HID report to create a “software mouse movement”. Presently I’m able to alter the form of a HID report by modifying the buffer of the WDFREQUEST object in the completion routine.

What I’d like to do is create one, without sending any request to the driver below me in the stack.

Tell me if I’m wrong but I understand that :

Windows issue a IoRead request that goes through my filter, to the hardware (I’m calling FilterForwardRequestWithCompletionRoutine in my filter driver).

When the hardware has data to send back to the computer it bubbles up the request all the way up, with the data in it.

Then the completion routine is called in my filter.

And finally WdfRequestComplete continue de forward the response to the driver above till it reaches Windows.

I’m not sure to be right on this, could you please confirm ?

Yes.

Can you help me sort this out ? maybe clarifying some of the concept and pointing to a sample in the wdk will do.

Clarify what concept? If you want to return your own information in the
request, then you need to fill in the output buffer of the read
requests, and use WdfRequestCompleteWithInformation to tell the system
how much data you have returned.

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

Doron_Holan · January 20, 2011, 12:42pm

the input stacks no longer work because the stacks are constantly sending reads which you are synchronously completing. if you want to spontaneously insert new HID packets, you have 2 choices

move your filter location. inserting new mouse data is very easy as a mouse upper filter driver, not in your current filter location below hidclass
if you don’t want to move your filter, you will need to split the read irp flow through your driver. for incoming reads, you must now queue them. when you have spontaneous io to report, you dequeue a read and complete it with your info. you must now also send your own reads down the stack to get the real data. when those reads complete, you must dequeue one of the reads you received (if none are present, you must enqueue the data somewhere so when you get an incoming read, you complete it immediately)

d

OSR_Community_User · January 20, 2011, 12:43pm

Is there anything else to do besides calling WdfRequestCompleteWithInformation ?

Do I need to create a new request or the one passed as a parameter to the IoRead callback will do, just by modifying its buffer ?

I did try that, with a call to WdfRequestCompleteWithInformation, and it looks like just after completing the request, the OS sends a new Read request (and that looks normal). However, the OS does not respond anymore to my other mouse, and I cannot update the driver anymore using devcon… I feel like I’m in an infinit loop or something. I tried adding in the buffer some mouse wheel scroll data but nothing happens…

Any clue ?

OSR_Community_User · January 20, 2011, 12:50pm

Hummm I think I’m not below hidclass but below mouclass and mouhid. Does it make a difference ?

My final goal btw is being able to generate mouse report from a raw custom HID interface. What’s the best option to do that ?

I’ll probably have one .sys file for the two interface, to have them communicating, and then when getting the correct raw data on my custom hid interface, I’d like to generate HID mouse report on the mouse interface.

Doron_Holan · January 20, 2011, 12:59pm

being below mouhid is no different than being below hidlcass, you are dealing with read requests. above mouhid and below mouclass you are dealing with a callback function and it is much easier to report spontaneous data there.

if you have a custom hid interface, your whole design is overly complicated and incorrect. you want a custom HID miniport (or the KMDF equivalent). in this hid miniport you get the incoming reads and can fill them in with whatever you want, either fabricated or hw generated input.

d

OSR_Community_User · January 21, 2011, 3:36am

If I set my lower filter on a mouse device (mouse guid in the inf file), am I below mouhid or below mouclass ?

I tried moving my filter but I do not always see hid reports (I’m probably not looking at the right place). In my current lower filter I see a IoRead for every os request and I can modify response from the device, and the looked very easy at first.

I see your point concerning the hid miniport but my device hardware has both interface (mouse and raw, in order to have a mouse working without a driver) and i’d’like to drop mouse packets when in “custom driver mode” rather than generic hid mouse.

Is this still valid ? Will this miniport create its own interfaces ? What will become my “hardware” interfaces ?

In case I’d like to try the upper filter, what’s the callback function you’re talking about ?

Many thanks for your help.

Alex

OSR_Community_User · January 21, 2011, 4:58am

I tried moving my filter above the HID device (instead of below the mouse device) and with the following code, none of my callbacks are called :

//
// Configure the default queue to be Parallel.
//
WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioQueueConfig,
WdfIoQueueDispatchParallel);

ioQueueConfig.EvtIoRead = FilterEvtIoRead;
ioQueueConfig.EvtIoWrite = FilterEvtIoWrite;
ioQueueConfig.EvtIoInternalDeviceControl = FilterEvtIoInternalDeviceControl;
ioQueueConfig.EvtIoDefault = FilterEvtIoDefault;
ioQueueConfig.EvtIoDeviceControl = FilterEvtIoDeviceControl;

status = WdfIoQueueCreate(device,
&ioQueueConfig,
WDF_NO_OBJECT_ATTRIBUTES,
WDF_NO_HANDLE // pointer to default queue
);

Isn’t the IoRead request supposed to pass through the entiere stack ?
Where should I “inject” my HID report then ?

Thanks again,

Alex

Maxim_S_Shatskih · January 21, 2011, 5:33am

> Isn’t the IoRead request supposed to pass through the entiere stack ?

No, below kbd/mouclass, there is no more read IRPs.

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

OSR_Community_User · January 21, 2011, 5:48am

I also tried a mouse device upper filter and no IoRead as well. Could you please clarify what happens from the OS “I want data” and when it finaly gets the data ?

I can’t find anywhere else than below mouclass to work on the the HID reports.

I must be missing something.

Thanks,

Alex

Maxim_S_Shatskih · January 21, 2011, 5:54am

> I can’t find anywhere else than below mouclass to work on the the HID reports.

Below mouclass you only see ServiceCallback calls up. Look at KBDFILTR sample on how to filter them.

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