Microsoft Windows CE 3.0  

Sample Keyboard Driver

Important:
This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The keyboard driver converts input from the keyboard hardware into keyboard events that it enters into the input system. The driver is also responsible for generating the proper Unicode characters from these keyboard events. The Platform Builder includes a keyboard driver that is divided into components, which facilitates development of keyboard drivers for international keyboard layouts. In addition, some keyboard drivers are complicated by the need to have keys generate multiple virtual keys.

The keyboard driver is different from other device drivers in that it is language dependent. The ScanCodeToVKeyExfunction is responsible for translating between hardware dependent scan codes and standard Windows virtual keys. This function will be dependent on the particular hardware and keyboard layout for the language. The KeybdDriverVKeyToUnicodefunction is responsible for generating the correct Unicode character based on the state of the virtual keys. This function is dependent only on the keyboard layout for the language. Both of these functions are based on translation tables, which can be customized for different languages. For translation tables for Brazilian Portuguese, Dutch, French, German, Italian, Japanese, Portuguese, Spanish, Swedish, UK English, and US English, see Keyboard Mapping. You can create your own translation tables or customize the existing tables, if necessary.

The Windows CE Platform Builder provides two sample keyboard drivers. The first is a layered driver for the ODO reference platform. This driver shows how to remap virtual keys. Virtual key remapping is necessary on smaller Windows CE-based platforms that do not have the full complement of physical keys normally present on desktop PCs. This driver generates virtual keys based on the state of particular physical keys and modifier keys such as SHIFT, ALT, etc. The MDD code for this driver is in the \Public\Common\Oak\Drivers\Keybd2 directory of your Platform Builder installation. The PDD code is in the \Platform\ODO\Drivers\Keybd2 directory.

The second driver is a monolithic driver built for the CEPC reference platform. This driver uses the monolithic model because the controller chip on a standard PC handles both the keyboard and mouse. This driver is also separated into common components and language-dependent components. Code for this driver is in the \Platform\CEPC\kbdmouse directory.

The Windows CE input system loads the keyboard driver at startup time. When the input system starts, it retrieves the name of the keyboard driver DLL from the HKEY_LOCAL_MACHINE\Hardware\DeviceMap\KEYBD\Drivernameregistry key. If no entry is found, the input system uses the default name, Keybddr.dll. It then loads the DLL and verifies that all required entry points exist.

Next, the input system calls the KeybdDriverInitializefunction to perform a one-time initialization. In this function, the driver saves a local copy of the input system callback function. The MDD also calls the KeybdPdd_InitializeDriverfunction to perform any hardware-specific initialization. It then starts the IST to handle keyboard interrupts.

In the sample MDD, the IST of the keyboard driver is named KeybdDriverThread. This thread calls the InterruptInitializefunction to register an event for the SYSINTR_KEYBOARD interrupt. It then waits for the event to be signaled. When the event is signaled, the IST calls the KeybdPdd_GetEventfunction. It then sends the key events returned from the PDD to the input system using the callback function provided by the input system when the KeybdDriverInitializefunction was called.

The input system pulls the keyboard event from the queue and calls back to the driver's KeybdDriverVKeyToUnicoderoutine. The driver analyzes the specified key event and the virtual key state and generates the corresponding characters. The input system then sends the virtual key and the characters to the appropriate application. Note that the keyboard driver must add the flags KEYBD_DEVICE_SILENT or KEYBD_DEVICE_SILENT_REPEAT to the virtual key codes it submits to the input system in order to suppress audible key clicks.

The KeybdDriverGetInfoand KeybdDriverSetModefunctions get and set information about the keyboard. When the main input thread processes a keyboard-connection event, the thread calls the KeybdDriverGetInfofunction to get the virtual-key-to-Unicode data supplied by the driver. The thread also allocates the required memory for the virtual key state data and any extra data required by the driver. Next, it calls the KeybdDriverInitStatesfunction to initialize the memory.

The following list shows the DDI functions for the keyboard driver: