Hello everyone,
we have a solution using filter drivers for keyboard and mouse that allows us to intercept user input. We use this during unattended installations of applications where user interference (by closing running installers, for example) is unwanted.
Our solutions works quite well for keyboard and mouse, but not for touch screens. A cursory look into Microsoft documentation suggests that touch screens do not use the same filtering model as the former input devices.
Is there a way to temporarily intercept touch screen input? Clicks would be enough, as we also allow moving the mouse cursor during such unattended installations (so that the system does not appear frozen and the user might want to try the power or reset buttons).
Thank you!
What OS version? I am pretty sure there are os facilities to automate installs (factory floor being a main consumer), a input filter scripting input is a huge hammer
Bent from my phone
From: xxxxx@lists.osr.com on behalf of xxxxx@materna.de
Sent: Monday, April 24, 2017 1:20:58 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Intercepting touch screen input
Hello everyone,
we have a solution using filter drivers for keyboard and mouse that allows us to intercept user input. We use this during unattended installations of applications where user interference (by closing running installers, for example) is unwanted.
Our solutions works quite well for keyboard and mouse, but not for touch screens. A cursory look into Microsoft documentation suggests that touch screens do not use the same filtering model as the former input devices.
Is there a way to temporarily intercept touch screen input? Clicks would be enough, as we also allow moving the mouse cursor during such unattended installations (so that the system does not appear frozen and the user might want to try the power or reset buttons).
Thank you!
—
NTDEV is sponsored by OSR
Visit the list online at: https:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:
To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>
InjectTouchInput on w8 and later https://msdn.microsoft.com/en-us/library/windows/desktop/hh802881(v=vs.85).aspx might do what you want. If not, you will need to write a hid filter and attach to the touch collection. It won’t be temporary, it will always be there
Bent from my phone
From: Doron Holan
Sent: Monday, April 24, 2017 7:50:30 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Intercepting touch screen input
What OS version? I am pretty sure there are os facilities to automate installs (factory floor being a main consumer), a input filter scripting input is a huge hammer
Bent from my phone
From: xxxxx@lists.osr.com on behalf of xxxxx@materna.de
Sent: Monday, April 24, 2017 1:20:58 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Intercepting touch screen input
Hello everyone,
we have a solution using filter drivers for keyboard and mouse that allows us to intercept user input. We use this during unattended installations of applications where user interference (by closing running installers, for example) is unwanted.
Our solutions works quite well for keyboard and mouse, but not for touch screens. A cursory look into Microsoft documentation suggests that touch screens do not use the same filtering model as the former input devices.
Is there a way to temporarily intercept touch screen input? Clicks would be enough, as we also allow moving the mouse cursor during such unattended installations (so that the system does not appear frozen and the user might want to try the power or reset buttons).
Thank you!
—
NTDEV is sponsored by OSR
Visit the list online at: https:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:
To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>
Hi Doran,
we support Windows versions starting from Windows 7 up to Windows 10.
We know that filtering input can have huge impact, but it also has the advantage of being a very generic solution to the problem.
Our software solution allows the customer to package arbitrary scripts and applications and install them unattended on client computers. Some of this applications must run “interactively” in the user session and are driven by injected input from macro recorders. To allow this installation to work without interference, we implemented our filter drivers years ago.
I don’t know about the os facilities you speak about (and “factory floor” seems to be impossible to google), so I don’t know if these would help us for our use cases. Do you have additional pointers?
Writing a hid filter sounds like what I intended to in the first place, but I somehow missed the possibility. How does filtering input work in a hid filter? The firefly sample does not seem to create a WdfIoQueueCrate (unlike our keyboard and mouse filters). Is there a special way of intercepting ioctls in a hid filter or can I use WdfIoQueueCreate the same way?
Attaching to the touch collection is done by registering the filter in a specific way and not by doing something different in the driver code, correct? Where would I register the equivalent of an upper class filter for the touch collection?
Thank you very much!
You will need to create a queue to handle ioctls. Touch is installed in the hid class, registering as a class upper filter will put you in every single hid, touch and not. You need to install per instance. You can use a compatible that includes the touch usage page and self sign, but sysdev won’t sign it (you aren’t allowed to submit compatible id matches)
Bent from my phone
From: xxxxx@lists.osr.com on behalf of xxxxx@materna.de
Sent: Tuesday, April 25, 2017 2:16:49 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Intercepting touch screen input
Hi Doran,
we support Windows versions starting from Windows 7 up to Windows 10.
We know that filtering input can have huge impact, but it also has the advantage of being a very generic solution to the problem.
Our software solution allows the customer to package arbitrary scripts and applications and install them unattended on client computers. Some of this applications must run “interactively” in the user session and are driven by injected input from macro recorders. To allow this installation to work without interference, we implemented our filter drivers years ago.
I don’t know about the os facilities you speak about (and “factory floor” seems to be impossible to google), so I don’t know if these would help us for our use cases. Do you have additional pointers?
Writing a hid filter sounds like what I intended to in the first place, but I somehow missed the possibility. How does filtering input work in a hid filter? The firefly sample does not seem to create a WdfIoQueueCrate (unlike our keyboard and mouse filters). Is there a special way of intercepting ioctls in a hid filter or can I use WdfIoQueueCreate the same way?
Attaching to the touch collection is done by registering the filter in a specific way and not by doing something different in the driver code, correct? Where would I register the equivalent of an upper class filter for the touch collection?
Thank you very much!
—
NTDEV is sponsored by OSR
Visit the list online at: https:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:
To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>
But doesn’t “installing per instance” mean that I have to know the instances at the time of installation? Sorry for being dense, but let’s say that the user attaches a new touchscreen device - how does our hid filter know to attach to this device unless I register it for the class?
Couldn’t a class filter decide whether a device in the class is in the touch collection and then attach to the device or leave it be?
Yes, you can filter at the class level. The risk is higher. Filtering at the class layer means if you can query for usage page in AddDevice, do so and not attach. Otherwise you will always be in each stack and decide in startdevice if you are in pass through mode or filter mode. Remember that the parent device (the hid miniport) is also installed in the HIDclass and you should not attach to these.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@materna.de
Sent: Tuesday, April 25, 2017 11:44 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Intercepting touch screen input
But doesn’t “installing per instance” mean that I have to know the instances at the time of installation? Sorry for being dense, but let’s say that the user attaches a new touchscreen device - how does our hid filter know to attach to this device unless I register it for the class?
Couldn’t a class filter decide whether a device in the class is in the touch collection and then attach to the device or leave it be?
—
NTDEV is sponsored by OSR
Visit the list online at: https:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:
To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>
Thanks Doron, I now have an idea how we could implement this feature.