VMware Workstation 4.5
This section addresses the following issues and provides additional details on keyboard mapping in Linux:
This section contains the following:
If your keyboard works correctly with a local X server, and you just want the same behavior with a remote X server (which is also an XFree86 server running on a PC), just power off the virtual machine and close the VMware Workstation window, then add the line
xkeymap.usekeycodeMapIfXFree86 = true
to the virtual machine configuration file or to ~/.vmware/config. Make this change on the host machine, where you run the virtual machine, not on the machine with the remote X server.
If you are using an XFree86-based server that VMware Workstation does not recognize as an XFree86 server, use this instead:
xkeymap.usekeycodeMap = true
If you are using an XFree86 server running locally, and the keyboard does not work correctly, please report the problem to the VMware technical support department.
Unfortunately, keyboard support for the PC (virtual or otherwise) is a complex affair. To do it justice, we have to start with some background information greatly simplified.
Pressing a key on the PC keyboard generates a scan code based roughly on the position of the key. For example, the Z key on a German keyboard generates the same code as the Y key on an English keyboard, because they are in the same position on the keyboard. Most keys have one-byte scan codes, but some keys have two-byte scan codes with prefix 0xe0.
Internally, VMware Workstation uses a simplified version of the PC scan code that is a single nine-bit numeric value, called a v-scan code. A v-scan code is written as a three-digit hexadecimal number. The first digit is 0 or 1. For example, the left-hand Ctrl key has a one-byte scan code (0x1d); its v-scan code is 0x01d. The right-hand Ctrl key scan code is two bytes (0xe0, 0x1d); its v-scan code is 0x11d.
An X server uses a two-level encoding of keys. An X key code is a one-byte value. The assignment of key codes to keys depends on the X server implementation and the physical keyboard. As a result, an X application normally cannot use key codes directly. Instead, the key codes are mapped into keysyms that have names like space, escape, x and 2. The mapping can be controlled by an X application via the function XChangeKeyboardMapping() or by the program xmodmap. To explore keyboard mappings, you can use xev, which shows the key codes and keysyms for keys typed into its window.
To recap, a key code corresponds roughly to a physical key, while a keysym corresponds to the symbol on the key top. For example, with an XFree86 server running on a PC, the Z key on the German keyboard has the same key code as the Y key on an English keyboard. The German Z keysym, however, is the same as the English Z keysym, and different from the English Y keysym.
For an XFree86 server on a PC, there is a one-to-one mapping from X key codes to PC scan codes (or v-scan codes, which is what VMware Workstation really uses). VMware Workstation takes advantage of this fact. When it is using an XFree86 server on the local host, it uses the built-in mapping from X key codes to v-scan codes. This mapping is keyboard independent and should be correct for most, if not all, languages. In other cases (not an XFree86 server or not a local server), VMware Workstation must map keysyms to v-scan codes, using a set of keyboard-specific tables.
Key code mapping is simple, automatic and foolproof. (Keysym mapping is more complex and described later.) However, because the program cannot tell whether a remote server is running on a PC or on some other kind of computer, it errs on the safe side and uses key code mapping only with local X servers. This is often too conservative and has undesirable effects. Luckily, this and other behavior related to key code-mapping can be controlled by powering off the virtual machine and closing the VMware Workstation window, then using a text editor to add configuration settings to the virtual machine's configuration file.
The easiest way to find the X key code for a key is to run xev or xmodmap -pk. Most of the v-scan codes are covered in V-Scan Code Table. The keysym mapping tables described in this section are also helpful.
Use this feature to make small modifications to the mapping. For example, to swap left Ctrl and Caps Lock, use the following lines:
xkeymap.keycode.64 = 0x01d # X Caps_Lock -> VM left ctrl
These configuration lines can be added to the individual virtual machine configuration, to your personal VMware Workstation configuration (~/.vmware/config), or even to the host-wide (/etc/vmware/config) or installation-wide (usually /usr/local/lib/vmware/config) configuration.
When key code mapping cannot be used (or is disabled), VMware Workstation maps keysyms to v-scan codes. It does this using one of the tables in the xkeymap directory in the VMware Workstation installation (usually /usr/local/lib/vmware).
Which table you should use depends on the keyboard layout. The normal distribution includes tables for PC keyboards for the United States and a number of European countries and languages. And for most of these, there are both the 101-key (or 102-key) and the 104-key (or 105-key) variants.
VMware Workstation automatically determines which table to use by examining the current X keymap. However, its decision-making process may sometimes fail. In addition, each mapping is fixed and may not be completely right for any given keyboard and X key code-to-keysym mapping. For example, a user may have swapped Ctrl and Caps Lock using xmodmap. This means the keys are swapped in the virtual machine when using a remote server (keysym mapping) but unswapped when using a local server (key code mapping).
Therefore, keysym mapping is necessarily imperfect. To make up for this defect, you can change most of the behavior using configuration settings:
These are the v-scan codes for the 104-key U.S. keyboard:
The 84-key keyboard has a Sys Req key on the numeric pad:
Keyboards outside the U.S. usually have an extra key (often < > or < > | ) next to the left shift key: