Create a keyboard layout

The keyboard layouts are dlls loaded in kernel space. The keyboard layouts are a bit strange since the constants used in them have no standard definitions, so the keyboard files have some preprocessor cruft. You can find this stuff in the existing keyboard layouts.

They have a data payload and a single entry point that returns a pointer to the keyboard tables.

The structure has these members:

 modifiers -> modifier_keys -> zero terminated mapping from vk to mod bit

ROSDATA VK_TO_BIT modifier_keys[] = {
  { VK_SHIFT,   KSHIFT },
  { VK_CONTROL, KCTRL },
  { VK_MENU,    KALT },
  { 0,          0 }
};

           -> number of bit combinations listed in modifier bits
   6

           -> modifier_bits 

 { 0, 1, 3, 4, SHFT_INVALID, SHFT_INVALID, 2 } /* Modifier bit order, NONE, SHIFT, CTRL, ALT, MENU, SHIFT + MENU, CTRL + MENU */

Each entry in this list is indexed by a shift state (some combination of bits from the modifier keys table), and tells what column in the VK_TO_WCHARS tables that shift state applies to.

 vk_to_wchar_master -> null terminated list of vk_to_wchar tables of varying widths.  the numberpad
 is a special table and is listed last.

Each vk_to_wchar table is identified by a width, telling how many of the columns indexed by the modifier list are present.

Put the new key-to-char entry in the key_to_chars_Xmod, where X is the number of functions the key has in the particular language. The values of the columns other than column 2 are from the ISO10646 unicode standard. See the tables at http://www.unicode.org/charts/.

ROSDATA VK_TO_WCHARS3 key_to_chars_3mod[] = {
  /* Normal, Shifted, Ctrl */
  /* Legacy (telnet-style) ascii escapes */
  { '3', CAPS, '3', 0xa7, 0xb3 },
  { '7', CAPS, '7', '/', '{' },
  ...

The vitrual key '3' responds to capitalization in this language, produces:
  '3'  unshifted (column 2)
  0xa7 Section sign  Shifted      (1) in the modifier bits
  0xb3 Superscript 3 Ctrl+Shift   (3) in the modifier bits (Alt+Gr)

 dead_key -> most languages have keys on the keyboard which have more than one meaning depending on 
             which key is pressed next.  The dead key table tells which keys these are and what the
             outcomes will be.

 ROSDATA DEADKEY dead_key[] = {
   { DEADTRANS(L'a', L'^', 0xe2, 0x00) },

 In this language, '^' followed by 'a' yields 0xe2, "Latin small letter a with circumflex"

Dead keys are marked in the vk_to_wchar table by a WCH_DEAD and then are searched by first and second keypress in the dead chars table.

 Followed in the main table by three key name tables (zero terminated)
 1. normal key names
 2. extended key names
 3. dead key names

The tables following these are the meat of the system, scancode to virtual key translation tables. Since there are more keys in the unenhanced key table (the 'beige keys') these are listed as 0x80 entries, indexed by scan code. Empty entries are marked VK_EMPTY.

The e0 and e1 scan code to vk tables are zero-terminated lists of scan codes that follow the special e0 and e1 extended keyboard codes. The first column is the scan code and the second column is an 8-bit virtual key code along with any required modifier bits in the upper byte (normally KEXT). The ext-bit is used by various parts of the keyboard system (for example to distinguish left and right shift and control, and to distinguish the windows keys from the alt keys).

Following these are:

 Layout version (1.1 here)
 

And ligature tables, which we don't currently support. These tables are used in languages that use scripts such a devangari, which have special opening character sequences for the beginning of a sentence. As far as I'm aware, languages based on cyrillic or roman alphabets don't use this. It would be great if somebody could help me describe this more fully.

There is a list of virtual key codes available at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/UserInput/VirtualKeyCodes.asp