Hi all,

I have writen a filter driver for a USB HID mouse in
Windows XP.Now I need to support selective suspend
feature.I am fallowing the DDK sample (selSusp) as a
reference.

But, while submitting the Idle Notification IRP to the
lower driver, "IoCallDriver" call fails with an
error "STATUS_INVALID_DEVICE_REQUEST".

Can any body please let me what might be the problem and
how can I resolve this.

TIA
Raghav

It's quite tricky to write a HID Mouse filter driver and get it to work
correctly, so there are a number of possible problems. One of the
drivers in the stack, for example, feels like it's the bottom of the
stack and doesn't forward requests on down further (I have this vague
memory that it was HIDUSB). We ended up having to install ourselves as a
filter both below hidusb and above mouhid.

Don't know if this has anything to do with your problem, though...

Raghav wrote:

--
.../ray\..

Thanks for the information.

I think you mean to say that I need to write a lower
filter driver for HIDUSB in order to support selective
suspend.In this case, my moufilter driver will send the
idle request to the lower driver in the stack. Please
correct me if I am wrong. What exactly I need to handle
in the HIDUSB filter driver?

According to "Programming the Microsoft® Windows® Driver
Model, Second Edition" book, HIDCLASS can send an Idle
request to support selective suspend. This IRP has to
pass through the HIDUSB.sys

I am also referring to the "Power saving of using USB
Selective Suspend Support Whitepaper" as a reference. But
it talks about the USBClientDriver just above the USB Hub
Driver. That's why I am having doubt on whether it is
possible to support selective suspend in the mouhid
driver level or not. Can you please clarify this and
suggest me the right direction to go forward.


Thanks,
Raghav

selective suspend for HIDs is controlled by a registry key. if you set the
registry value for the HIDCLASS FDO in its devnode, HID does the selective
suspend for you ... value name is "SelectiveSuspendEnabled", type REG_DWORD,
value is 0x1. see the HID_SelSus_Inst install section in
%windir%\inf\input.inf.

d

--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Raghav" <anonymous@discussions.microsoft.com> wrote in message
news:06a101c3aff6$1a158760$a401280a@phx.gbl...
Thanks for the information.

I think you mean to say that I need to write a lower
filter driver for HIDUSB in order to support selective
suspend.In this case, my moufilter driver will send the
idle request to the lower driver in the stack. Please
correct me if I am wrong. What exactly I need to handle
in the HIDUSB filter driver?

According to "Programming the Microsoft® Windows® Driver
Model, Second Edition" book, HIDCLASS can send an Idle
request to support selective suspend. This IRP has to
pass through the HIDUSB.sys

I am also referring to the "Power saving of using USB
Selective Suspend Support Whitepaper" as a reference. But
it talks about the USBClientDriver just above the USB Hub
Driver. That's why I am having doubt on whether it is
possible to support selective suspend in the mouhid
driver level or not. Can you please clarify this and
suggest me the right direction to go forward.


Thanks,
Raghav

A side note: don't expect to get high performance out of this. It takes
the HID stack quite some time to recover from the selective suspend
request (around 1/3 second on one reasonably high-performance XP
platform we had to deal with).

That's not a lot of time for a printer, but it's only slightly less than
an eternity for a mouse...

One other thing to note, depending on what you're trying to do, is that
lots of USB mice out there (MS Intellimice, for example) get quite
unhappy if you enable selective suspend for them... In the case of at
least some Intellimice, they stop working until you click a button.
Since it only takes ~4-5 seconds of inactivity to activate selective
suspend, this can be quite painful.

Doron Holan [MS] wrote:

--
.../ray\..

resume time is entirely gated on the usb controller and usb mouse powering
up. if the mouse has slow f/w, it is the gate. very simple mice which i
have SS'ed come back w/no user lag whatsoever. As for SS'ing intellimice,
movement will not wake them up when they are powered down (the camera stops
sampling), but the button and wheel do wake the device back. b/c of this,
this is why SS is not automatically enabled on these mice.

d

--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Ray Trent" <rat@synaptics.com.spamblock> wrote in message
news:OHVEAjIsDHA.2304@tk2msftngp13.phx.gbl...

Interesting... When we looked into this last, the .3 second delay
appeared to be almost entirely in the HID stack (which was being torn
down completely for the device that was SS'd) being built back up,
drivers paged back in, IRPs being sent around, registry settings being
re-read, etc. Our device was responding in microseconds... I.e., we were
getting REMOVE_DEVICE's on SS, and ADD_DEVICE's on SS resume, plus all
the usual start up IRPs and stuff.

Of course, it was hard for us to judge how much of the delay was in the
early NEC USB 2.0 controller on that machine... it had a few unrelated
problems, so who knows...

Has MS changed this a lot in the last year or two?

Doron Holan [MS] wrote:

--
.../ray\..

SS of a HID device does not tear down the enumerated PDOs for USB (in
bluetooth, it does for other reasons though).

d

--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Ray Trent" <rat@synaptics.com.spamblock> wrote in message
news:OtNsE3tsDHA.3224@tk2msftngp13.phx.gbl...

I went back and looked at some saved debug output, and you're right, my
memory was faulty (this was ~2 years ago :-). All we were getting was an
idle request on suspend and a StartDevice on resume (well, plus all the
other stuff you'd expect)...

However, while my memory could again be tricking me :-), I'm nearly
certain we performed the experiment of putting out a DbgPrint with a
timestamp when the wakeup packet was received, and then again when we
got the corresponding StartDevice, and observed a ~.3 second delay
between the two. (damn, but I wish that I had saved a file with that
debug output)..., and that this was consistent with the observed behavior.

Any ideas on what might have been wrong with the (early NEC EHCI USB
2.0) host controller or our driver or the HID/USB stack that might have
caused that?

Doron Holan [MS] wrote:

--
.../ray\..

you will only see a Dx irp (D2 most likely) and then a D0 irp. no start
device requests. perhaps you mapped a power up to D0 irp as a start device
call.

d

--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Ray Trent" <rat@synaptics.com.spamblock> wrote in message
news:OCBmGvEtDHA.1888@TK2MSFTNGP10.phx.gbl...