Hidclass has no idea that the 2 enumerated stacks are related (sounds
like you wrote a bus driver). From what it sounds like, your pend of
the read irp is blocking hidclass from processing anymore data. When
you receive a read irp that you don’t have data for, you must pend it in
a non blocking fashion, ie insert it into a list and then return
STATUS_PENDING. You cannot block hidclass’s calling thread context
until you have data to return.
HIDCLASS cannot guarantee that there will be a read irp pended to your
driver at all times, although it tries very hard to this. This means
that if you get data and there is no pending read irp, you must enqueue
the data. Classic producer/consumer problem.
This is how I would design it
Typedef struct _MINI_DEVICE_EXTENSION {
// Other stuff …
KSPIN_LOCK ListLock;
LIST_ENTRY DataList;
LIST_ENTRY IrpList;
} MINI_DEVICE_EXTENSION, *PMINI_DEVICE_EXTENSION;
ListLock guards both the DataList and the IrpList. So when you receive
a read irp, you grab the ListLock, check to see if DataList is empty. If
so, enqueue the irp onto IrpList (make sure to set a cancel routine!)
and return status_pending. Otherwise, complete the IRP inline. When
you receive data, grab the ListLock, check to see if IrpList is empty.
If so, enqueue the data onto DataList. Otherwise, dequeue the irp in a
cancel safe manner and complete the irp w/the data.
If you have not written cancel safe irp queueing code, there are quite a
few examples out there. Ervin Peretz wrote an article of MSJ (which I
think became MSDN magazine) a couple of years back that does a great job
at it.
D
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
From: Seshagiri Babu [mailto:xxxxx@bla.satyam.com]
Sent: Thursday, June 06, 2002 10:23 PM
To: NT Developers Interest List
Subject: [ntdev] RE: HID Mini driver
Let me explain it in more detail. Two pnp devices when inserted
triggers
the HID Mini drivers’ AddDevice. Now there are two sperate device stacks
and HID MINI (HIDCLASS) will be maintaing the FDO’s.
Now due to some operation, data is recieved on the first device.
So
it completes the pending Read Irp from HIDCLASS. Since it has few more
packets to send, it will be waiting for the next read IRp. Surprisingly
the next read Irp is targetted to the other device stack, where it goes
to
pending state due to lack of any data to communicate.
Now if i pump some data on the second device, it completes its Irp
and the first device stack will now be getting the Read Irp. So the
first
device remains blocked waiting for a Read Irp until i operate second
device.
Now how can i ensure that i always have on Irp pending with each
device stack?
cheers
Sesha.
I am very confused here. Does each device object have its own device
stack (ie PDO) and devnode? If so, hidclass treats all device objects
registered with it as individual and separate objects. =20
As for receiving a read on a devobj that doesn’t have any data to
return, you must enqueue the irp (and be sure to handle cancellation
b/c
hidclass *WILL* cancel the irp) and complete it when you do get data.
Be ready for more then one pending read irp at a time as well.
d
-----Original Message-----
From: Seshagiri Babu [mailto:xxxxx@bla.satyam.com]=20
Sent: Thursday, June 06, 2002 9:32 PM
To: NT Developers Interest List
Subject: [ntdev] RE: HID Mini driver
Thanks D. Yeah…thats’ right. I’ll complete a single packet and enque
the
other packets and will be waiitng for more Read IRp’s to follow.
Iam facing some problem here. I have multiple device objects and
the next
Irp is getting targettted to the other device object, which doesn’t
have
any packets to be completed. The initial device object which has
queued
the packets is not getting the next Read Irp…
Now my Q is whether HIDCLASS will be sending only one Read IRp
irresepective of the number of devices i have or will it ensure that
there
is always on READ Irp pending for all the device instances i have!!!
cheers
Sesha.
> You can only return one packet in the read IRP that HIDCLASS sends
you.
> If you have multiple reports to send, you must enqueue them in your
> miniport and wait for the next read irp to come down.
>=20
> d
>=20
> -----Original Message-----
> From: Sai_Prasad [mailto:xxxxx@Satyam.com]=3D20
> Sent: Thursday, June 06, 2002 5:13 AM
> To: NT Developers Interest List
> Subject: [ntdev] HID Mini driver
>=20
> Dear All,
> We have implemented a Hid Mini driver and our driver is supposed
> to
> service multiple (nearly 4) pointing devices.=3D20
>=20
> Now the problem is coming when there are multiple packets to be
> communicated to HIDCLASS from a device, and one packet is completed
in
> response to a Read Irp from HIDCLASS, the next Irp the Hidclass
sends
is
> not
> targetted to the earlier device which has completed the Irp.=3D20
>=20
> Can someone explain this odd behaviour…
>=20
> cheers
> Sesha.
>
************************************************************************
> **=3D20
> This email (including any attachments) is intended for the sole use
of
> the
> intended recipient/s and may contain material that is CONFIDENTIAL
AND
> PRIVATE COMPANY INFORMATION. Any review or reliance by others or
copying
> or
> distribution or forwarding of any or all of the contents in this
message
> is
> STRICTLY PROHIBITED. If you are not the intended recipient, please
> contact
> the sender by email and delete all copies; your cooperation in this
> regard
> is appreciated.
>
************************************************************************
> **
>=20
> —
> You are currently subscribed to ntdev as:
xxxxx@windows.microsoft.com
> To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to %%email.unsub%%