Hello to all. Would it be possible for a KM HID filter to obtain (besides the input report of its own PDO) a remote HID PDO target’s input report? Instead of the remote target completing its report back to Windows, I’d like the local filter to intercept the remote target’s report.
By the way, I’m only working with pen/touch/digitizer devices.
Thanks!
On Apr 12, 2015, at 8:17 PM, xxxxx@gmail.com wrote:
Hello to all. Would it be possible for a KM HID filter to obtain (besides the input report of its own PDO) a remote HID PDO target’s input report? Instead of the remote target completing its report back to Windows, I’d like the local filter to intercept the remote target’s report.
What do you mean by “remote”? Do you simply mean a PDO in another stack?
In order to intercept traffic in another stack, you have to have a filter driver in that stack.
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Yes, I’m sorry for my poor choice of terms and thank you for correcting me. Going with what you’ve said though, if I have a filter on the top of that HID device stack, is it possible to configure that filter such that it refuses read requests from Windows but processes read requests from a driver in another stack?
Right now, I have a similar configuration, but this is what happens. The filter is filtering a HID pen device. It’s very simple, it just inspects the input report and it just completes the request back to whoever sent the read request. If I use the pen on the screen, I observe that the screen responds and I also see the debug messages which show the completion status and some pen data. However, when a driver on another stack issues a (async) read request to this same HID pen device, the completion status is always cancelled (I inspect the status via CompletionParams inside a CompletionRoutine). I’m wondering what I’m doing wrong? Or might this be just plainly not supported/impossible?
Thanks!
xxxxx@gmail.com wrote:
Yes, I’m sorry for my poor choice of terms and thank you for correcting me. Going with what you’ve said though, if I have a filter on the top of that HID device stack, is it possible to configure that filter such that it refuses read requests from Windows but processes read requests from a driver in another stack?
Certainly, but how would you tell the difference?
Right now, I have a similar configuration, but this is what happens. The filter is filtering a HID pen device. It’s very simple, it just inspects the input report and it just completes the request back to whoever sent the read request. If I use the pen on the screen, I observe that the screen responds and I also see the debug messages which show the completion status and some pen data. However, when a driver on another stack issues a (async) read request to this same HID pen device, the completion status is always cancelled (I inspect the status via CompletionParams inside a CompletionRoutine). I’m wondering what I’m doing wrong? Or might this be just plainly not supported/impossible?
A request is a request is a request. The originator doesn’t make any
difference. Is it possible the request had already been canceled by the
time your filter saw it? If you aren’t setting a canceled status, then
the originator should not see a canceled status, EVEN IF the originator
canceled the request.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks. However, my pen filter only sets the completion status based on what was given in the original CompletionParams parameter in the CompletionRoutine. It does not set the status to cancelled by itself. It looks like whenever my other driver issues a read request, it’s cancelled already for some reason. This happens even if the the pen is in range/touching the screen while the other driver sends the read request.
xxxxx@gmail.com wrote:
Thanks. However, my pen filter only sets the completion status based on what was given in the original CompletionParams parameter in the CompletionRoutine. It does not set the status to cancelled by itself. It looks like whenever my other driver issues a read request, it’s cancelled already for some reason. This happens even if the the pen is in range/touching the screen while the other driver sends the read request.
If your filter is not present, do the other driver’s requests succeed?
How are you acquiring the device object to send the request? Do you
have a file object?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.