I have a hidclass minidriver that delays a request to
IOCTL_HID_GET_REPORT_DESCRIPTOR by 2 seconds to workaround a bug in the
Tablet PC service (wisptis.exe).
This is great but it causes the driver to fail the SPPTS (
http://msdn.microsoft.com/en-us/library/ff567576(VS.85).aspx).
I am looking at trying returning STATUS_PENDING… for WDF is it as simple as
putting the request in a manual queue and then completing in it a work item
or such?
Cheers,
Dan
All requests are pended by kmdf regardless of the type of top level dispatching queue you have configured for your driver.
d
dent from a phpne with no keynoard
From: Daniel Newton
Sent: November 01, 2010 9:35 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] STATUS_PENDING WDF
I have a hidclass minidriver that delays a request to IOCTL_HID_GET_REPORT_DESCRIPTOR by 2 seconds to workaround a bug in the Tablet PC service (wisptis.exe).
This is great but it causes the driver to fail the SPPTS (http://msdn.microsoft.com/en-us/library/ff567576(VS.85).aspx).
I am looking at trying returning STATUS_PENDING… for WDF is it as simple as putting the request in a manual queue and then completing in it a work item or such?
Cheers,
Dan
— 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
Oh right, the “Windows On/Off Transitions Solutions Guide” mentions that
kmdf does that for IRP_MN_START_DEVICE and IRP_MN_QUERY_DEVICE_RELATIONS so
it makes sense to be a global policy.
So is there any other way of passing SPPTS short of reducing the delay in
completing IOCTL_HID_GET_REPORT_DESCRIPTOR?
On Tue, Nov 2, 2010 at 6:29 PM, Doron Holan wrote:
> All requests are pended by kmdf regardless of the type of top level
> dispatching queue you have configured for your driver.
>
> d
>
> dent from a phpne with no keynoard
>
> ------------------------------
> From: Daniel Newton
> Sent: November 01, 2010 9:35 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] STATUS_PENDING WDF
>
> I have a hidclass minidriver that delays a request to
> IOCTL_HID_GET_REPORT_DESCRIPTOR by 2 seconds to workaround a bug in the
> Tablet PC service (wisptis.exe).
>
> This is great but it causes the driver to fail the SPPTS (
> http://msdn.microsoft.com/en-us/library/ff567576(VS.85).aspx).
>
> I am looking at trying returning STATUS_PENDING… for WDF is it as simple
> as putting the request in a manual queue and then completing in it a work
> item or such?
>
> Cheers,
> Dan
> — 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
>
> Oh right, the “Windows On/Off Transitions Solutions Guide” mentions that kmdf does that for IRP_MN_START_DEVICE and IRP_MN_QUERY_DEVICE_RELATIONS so it makes sense to be a global policy
That is an incorrect conclusion to make. KMDF pends all app i/o (read, write, ioctl,internal ioctl) automatically, or in other words, all IO that is presented via a WDFQUEUE. You cannot make the assumption that since we do that for app io that we do it for all IRPs (power, pnp, create, close, etc).
d
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Newton
Sent: Tuesday, November 02, 2010 2:06 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] STATUS_PENDING WDF
Oh right, the “Windows On/Off Transitions Solutions Guide” mentions that kmdf does that for IRP_MN_START_DEVICE and IRP_MN_QUERY_DEVICE_RELATIONS so it makes sense to be a global policy.
So is there any other way of passing SPPTS short of reducing the delay in completing IOCTL_HID_GET_REPORT_DESCRIPTOR?
On Tue, Nov 2, 2010 at 6:29 PM, Doron Holan > wrote:
All requests are pended by kmdf regardless of the type of top level dispatching queue you have configured for your driver.
d
dent from a phpne with no keynoard
________________________________
From: Daniel Newton >
Sent: November 01, 2010 9:35 PM
To: Windows System Software Devs Interest List >
Subject: [ntdev] STATUS_PENDING WDF
I have a hidclass minidriver that delays a request to IOCTL_HID_GET_REPORT_DESCRIPTOR by 2 seconds to workaround a bug in the Tablet PC service (wisptis.exe).
This is great but it causes the driver to fail the SPPTS (http://msdn.microsoft.com/en-us/library/ff567576(VS.85).aspx).
I am looking at trying returning STATUS_PENDING… for WDF is it as simple as putting the request in a manual queue and then completing in it a work item or such?
Cheers,
Dan
— 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
— 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
Daniel Newton wrote:
Oh right, the"Windows On/Off Transitions Solutions Guide" mentions
that kmdf does that for IRP_MN_START_DEVICE and
IRP_MN_QUERY_DEVICE_RELATIONS so it makes sense to be a global policy.So is there any other way of passing SPPTS short of reducing the delay
in completing IOCTL_HID_GET_REPORT_DESCRIPTOR?
I’m not sure why you think pending the IRP and then completing it later
is going to be any better than your current delay strategy. The
application will see exactly the same result – the request will not be
completed.
That test requires that the entire system be fully operational within a
relatively short period of time when coming back to S0. Your delay, no
matter how you implement it, will cause that to fail.
What kind of bug are you working around by delaying a report descriptor
request for two seconds?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>seconds to workaround a bug in the Tablet PC service (wisptis.exe).
Maybe it’s better to delay the start of this service by 2 seconds? or to restart it automatically later a bit?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
On Wed, Nov 3, 2010 at 11:12 AM, Tim Roberts wrote:
> Daniel Newton wrote:
> > Oh right, the"Windows On/Off Transitions Solutions Guide" mentions
> > that kmdf does that for IRP_MN_START_DEVICE and
> > IRP_MN_QUERY_DEVICE_RELATIONS so it makes sense to be a global policy.
> >
> > So is there any other way of passing SPPTS short of reducing the delay
> > in completing IOCTL_HID_GET_REPORT_DESCRIPTOR?
>
> I’m not sure why you think pending the IRP and then completing it later
> is going to be any better than your current delay strategy. The
> application will see exactly the same result – the request will not be
> completed.
>
I wanted to return STATUS_PENDING to the caller (didnt realize kmdf did this
anyhow)
>
> That test requires that the entire system be fully operational within a
> relatively short period of time when coming back to S0. Your delay, no
> matter how you implement it, will cause that to fail.
>
> What kind of bug are you working around by delaying a report descriptor
> request for two seconds?
>
>
The tablet pc service will stop reporting digitizer input if the digitizer
is unplugged and replugged relatively quickly.
>
>seconds to workaround a bug in the Tablet PC service (wisptis.exe).
Maybe it’s better to delay the start of this service by 2 seconds? or to
restart it automatically later a bit?
That would open up another can of worms surely:
> - messing with a system service
And adding filter drivers is easier and lesser messing???
- the addition of my own service to manage restarting another service
Filter drivers seem to be more complex.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Daniel Newton wrote:
On Wed, Nov 3, 2010 at 11:12 AM, Tim Roberts > mailto:xxxxx> wrote:
>
>
> I’m not sure why you think pending the IRP and then completing it
> later
> is going to be any better than your current delay strategy. The
> application will see exactly the same result – the request will
> not be
> completed.
>
>
> I wanted to return STATUS_PENDING to the caller (didnt realize kmdf
> did this anyhow)
That’s not how things work. Unless they are using overlapped I/O, an
application cannot tell the difference between blocking 2 seconds in an
ioctl handler, and returning STATUS_PENDING but setting a 2 second timer
to complete the request. User mode applications never see
STATUS_PENDING unless they use overlapped I/O, and even then most apps
just call GetOverlappedResult, which blocks again.
>
>
> What kind of bug are you working around by delaying a report
> descriptor
> request for two seconds?
>
>
> The tablet pc service will stop reporting digitizer input if the
> digitizer is unplugged and replugged relatively quickly.
Interesting. What leads you to believe this is bug in the service, as
opposed to a bug in your device or your driver? I’m not saying it is
one or the other, although most unplug/replug issues come down to driver
problems.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</mailto:xxxxx>
On Wed, Nov 3, 2010 at 11:50 AM, Maxim S. Shatskih
wrote:
> > - messing with a system service
>
> And adding filter drivers is easier and lesser messing???
>
> > - the addition of my own service to manage restarting another service
>
> Filter drivers seem to be more complex.
>
>
I don’t have a filter driver (well apart from mshidkmdf), I have a HID
minidriver to present my device as a digitizer
>
> I wanted to return STATUS_PENDING to the caller (didnt realize kmdf
> did this anyhow)That’s not how things work. Unless they are using overlapped I/O, an
application cannot tell the difference between blocking 2 seconds in an
ioctl handler, and returning STATUS_PENDING but setting a 2 second timer
to complete the request. User mode applications never see
STATUS_PENDING unless they use overlapped I/O, and even then most apps
just call GetOverlappedResult, which blocks again.
Yes I realise that. I understand it is recommended that STATUS_PENDING be
returned from IRP_MN_START_DEVICE and IRP_MN_QUERY_DEVICE_RELATIONS so that
the pnp manger can parallelize the enumeration process. I guess my hope was
that hidclass or whatever could be convinced to parallelize the retrieval of
the hid descriptors also.
> The tablet pc service will stop reporting digitizer input if the
> digitizer is unplugged and replugged relatively quickly.Interesting. What leads you to believe this is bug in the service, as
opposed to a bug in your device or your driver? I’m not saying it is
one or the other, although most unplug/replug issues come down to driver
problems.
Wisptis has a large delay before unloading and releasing driver handles
when the device is surprise removed (I have talked to MS devs who
acknowledge this problem but it isn’t a priority to patch). If you plug in
the device before wisptis has unloaded it will not reload or reinitialise
properly and will drop any digitizer input (the descriptor delay somehow
fixes this). I have seen some drivers with a root enumerated HID minidriver
so they don’t have any of these issues to contend with.
btw wisptis = “tablet pc service” it is just easier to type the one word.
Cheers,
Dan
>Yes I realise that. I understand it is recommended that STATUS_PENDING be returned from
IRP_MN_START_DEVICE
Pend START_DEVICE?
Sorry, but you first need to pass it down, then wait for the stack below to complete it, then do your own stuff.
I cannot understand how pending it can help in this picture.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Yrs, oems start device on the way up the stack. This allows the is to boot faster by allowing multiple devices to start concurrently.
d
dent from a phpne with no keynoard
-----Original Message-----
From: Maxim S. Shatskih
Sent: November 03, 2010 3:36 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] STATUS_PENDING WDF
>Yes I realise that. I understand it is recommended that STATUS_PENDING be returned from
>IRP_MN_START_DEVICE
Pend START_DEVICE?
Sorry, but you first need to pass it down, then wait for the stack below to complete it, then do your own stuff.
I cannot understand how pending it can help in this picture.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
—
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