info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Groups keyboard shortcuts have been updated
Dismiss
See shortcuts
Keyboard input in native app
20 views
Skip to first unread message
Michael H___
Dec 5, 2016, 12:05:01 PM12/5/16
to
I hope, this is the correct group. Please excuse, if not...
Anyway, here is my problem:
I am writing a native app (running at boot time, ie. from BootExec) for WinXP. I am reading keyboard input as follows:
Getting keyboard handles:
- I try to open devices with NtOpenFile for \\Device\\KeyboardClass%i, with %i from 0-31. (I use ACCESS_MASK including SYNCHRONIZE, ie. asynchronous read.)
- I store each successfully opened handle in an array. I ignore all others.
Reading:
- I loop through the handle array. For each handle I call NtReadFile (I am not using events).
- When the loop is finished, I wait for multiple objects (all the keyboard handles, WaitAny, no timeout).
- When a key is pressed, NtWaitForMultipleObjects returns with the index of the signaled handle (I presume).
This all works well. The hardware is as follows:
I have one physical PS/2 keyboard attached. In the Registry I see in 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\kbdclass\Enum' the name '0' with value 'Root\RDP_KBD\0000' and the name '1' with value 'ACPI\PNP0303\4&1d401fb5&0'.
I think the former is the Terminal Service Virtual Keyboard, and the latter is the physical PS/2 keyboard.
Indeed, I get valid handles for 'KeyboardClass0' and 'KeyboardClass1'.
Now comes the strange part:
Everytime I get a scancode from the NtReadFile, it comes from device #0 (the virtual keyboard). Not from the physical keyboard, as I would expect.
Can someone explain why?
kind regards,
Mike
Anyway, here is my problem:
I am writing a native app (running at boot time, ie. from BootExec) for WinXP. I am reading keyboard input as follows:
Getting keyboard handles:
- I try to open devices with NtOpenFile for \\Device\\KeyboardClass%i, with %i from 0-31. (I use ACCESS_MASK including SYNCHRONIZE, ie. asynchronous read.)
- I store each successfully opened handle in an array. I ignore all others.
Reading:
- I loop through the handle array. For each handle I call NtReadFile (I am not using events).
- When the loop is finished, I wait for multiple objects (all the keyboard handles, WaitAny, no timeout).
- When a key is pressed, NtWaitForMultipleObjects returns with the index of the signaled handle (I presume).
This all works well. The hardware is as follows:
I have one physical PS/2 keyboard attached. In the Registry I see in 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\kbdclass\Enum' the name '0' with value 'Root\RDP_KBD\0000' and the name '1' with value 'ACPI\PNP0303\4&1d401fb5&0'.
I think the former is the Terminal Service Virtual Keyboard, and the latter is the physical PS/2 keyboard.
Indeed, I get valid handles for 'KeyboardClass0' and 'KeyboardClass1'.
Now comes the strange part:
Everytime I get a scancode from the NtReadFile, it comes from device #0 (the virtual keyboard). Not from the physical keyboard, as I would expect.
Can someone explain why?
kind regards,
Mike
Michael H___
Dec 6, 2016, 5:33:26 AM12/6/16
to
A follow up (just in case someone has the same problem):
As it turned out, the keyboard that signaled my NtWaitForMultipleObjects was the physical device alright. It came with return value 0 (corresponding to \Device\KeyboardClass0), but still this is the ACPI-keyboard, despite it is enumed as '1' in ...\Services\kbdclass.
The background why I even bothered was, that I failed to set the indicator LEDs. But this had an entirely different reason. My call to NtDeviceIoControlFile(IOCTL_KEYBOARD_SET_INDICATORS, bla bla) always failed with STATUS_INVALID_PARAMETER. I was setting the KEYBOARD_INDICATOR_PARAMETERS.LedFlags to KEYBOARD_NUM_LOCK_ON and the like (#defined in winddk.h), which I found on Google in a hundred code examples. As it turned out, these are completely the wrong flags. They should be 0x01, 0x02 and 0x04 for SCROLL, NUM, CAPS respectively (#defined nowhere). With these flags, the DeviceIoControl call returns ok.
As it turned out, the keyboard that signaled my NtWaitForMultipleObjects was the physical device alright. It came with return value 0 (corresponding to \Device\KeyboardClass0), but still this is the ACPI-keyboard, despite it is enumed as '1' in ...\Services\kbdclass.
The background why I even bothered was, that I failed to set the indicator LEDs. But this had an entirely different reason. My call to NtDeviceIoControlFile(IOCTL_KEYBOARD_SET_INDICATORS, bla bla) always failed with STATUS_INVALID_PARAMETER. I was setting the KEYBOARD_INDICATOR_PARAMETERS.LedFlags to KEYBOARD_NUM_LOCK_ON and the like (#defined in winddk.h), which I found on Google in a hundred code examples. As it turned out, these are completely the wrong flags. They should be 0x01, 0x02 and 0x04 for SCROLL, NUM, CAPS respectively (#defined nowhere). With these flags, the DeviceIoControl call returns ok.
Roberta Bahr
Feb 22, 2020, 3:15:58 AM2/22/20
to
Roberta Bahr
Feb 22, 2020, 3:18:13 AM2/22/20
to
On Monday, December 5, 2016 at 9:05:01 AM UTC-8, Michael H___ wrote:
0 new messages