Hi,
I am very new to OSR and general driver programming, so not sure if this is even possible. I’ll cut to the chase.
First - is it possible to write a driver that can listen out for a simulated keypress generated from User Mode (i.e., SendKey or from some python function), then, generate the corresponding “real” keypress event?
The reason for this is I have an assistive tech software (allows for alternate accessible control method) that I need to interface with. One of the methods to do this is to generate an F12 keystroke. However, this program catches and filters out simulated keypress by listening out for LLKBHF_INJECTED flag (LowLevelKeyBoardHookFlag_Injected; 0x10).
I’ve tried doing this via several methods at WinAPI level but none have worked so far - so now I am resorting to this…
… generate the corresponding “real” keypress event?
Could you please expand it a bit - to be honest, I just cannot imagine how a program may physically push the button…
What you can do here is to emulate a separate kbd stack so that you can simulate a keystroke in the kernel. Certainly, this keystroke is going to end up in exactly the same queue that SendInputs() injects its input to, but this approach is, apparently, going to sort out the issue of LLKBHF_INJECTED flag…
First - is it possible to write a driver that can listen out for a simulated keypress generated from User Mode (i.e., SendKey or from some python function), then, generate the corresponding “real” keypress event?
No. SendKeys and keybd_event are handled entirely in user mode. They
never travel to the kernel, so there is no place for a driver to get
involved. Doron is an expert on the input subsystem; perhaps he has
some clever alternative.
The reason for this is I have an assistive tech software (allows for alternate accessible control method) that I need to interface with. One of the methods to do this is to generate an F12 keystroke. However, this program catches and filters out simulated keypress by listening out for LLKBHF_INJECTED flag (LowLevelKeyBoardHookFlag_Injected; 0x10).
So, you’re saying that this software is usually triggered by as F12
keypress, but it specifically rejects an injected F12 keypress? How is
that not an utterly fatal design flaw in the software? The entire POINT
of assistive tech is the need to use alternatives to traditional
hardware input devices. Couldn’t this be seen as a violation of the ADA?
Hi everyone - thank you for your prompt responses!
@anton_bassov - sorry I wasn’t so clear - I didn’t mean the software to literally push the keyboard. I meant, generate a keystroke from the abstract level, so that in turn, it doesn’t have the LLKBHF_Injected flag.
@Tim_Roberts - F12 (or whatever I set it to) is a backup activation mechanism for this software, there is a variety of main activation mechanisms. I believe the reason why they filter out injected keys, but not physical key presses, is to avoid double activations or accidental activations.
@Doron_Holan - I see. so my question is, is there a way I can send a keystroke event from the driver by initiating the method (whatever it may be) from User Mode?
so my question is, is there a way I can send a keystroke event from the driver by initiating the method (whatever it may be)
from User Mode?
As I told you already, you have to emulate a separate kbd stack in the kernel. Instead of calling SendInput() your app will send an IOCTL with the data of interest to your driver, which, in turn, will inject the target keystroke into the same queue that SendInput() does, but without LLKBHF_INJECTED flag. This is the only way to go. Check HID WDK samples for more info…