Xmodmap
| Development status | Active |
|---|---|
| Operating system | Linux, BSD |
| Type | Utility software |
| License | GNU General Public License 2 |
xmodmap is a utility for modifying X Server keymaps and pointer (mouse) button mappings. It can also be used as a tool to display the current keymaps and mouse button mappings as functional within the X Server. An important thing to keep in mind, XModMap "modifies" the current layout. Due to it's design, it cannot completely replace XKB as the ultimate way to set keyboard layouts for X. Adding alternate layers is not possible with xmodmap unless they are previously set with XKB.
XModMap is considerably easier to understand and use than compared to XKB as it is very overwhelming as it has a lot of feature bloat.
Like loadkeys, xmodmap works with a configuration file that specifies all of the keysyms that are to be changed. As well, only the keys that are specified to be changed, are changed. The rest are left as per the previous configuration.
Desktop Environments (DE) and/or Window Managers (WM) specific configurations for shortcuts does not apply here for binding keycodes. Some DE/WM specific environments may have their own extra set of layer that deals with shortcuts for certain functionality, such as switching between active windows, run programs, killing unresponsive programs via "point and click", etc. For such shortcut configurations it is best to check one's own DE/WM environments and to see how shortcuts are bound. KDE4 for instance has most of their shortcuts setup via global shortcuts. As such it does not conflict with xmodmap specific setups.
Introduction to XKB
TODO (Needed as xmodmap heavily depends on the state of XKB)
Basic xmodmap usage
xmodmap ideally works when it is executed to run a xmodmap specific configuration file. However xmodmap can also allow one to change parameters one at a time without the need to constantly reload the entire xmodmap specific configuration file.
xmodmap when executed to load a xmodmap specific configuration file it will be a little more resource demanding (more CPU specific) in the first few seconds or so when setting up the keyboard settings according to user requirements. Keep in mind that the initial period only lasts for a short period on a modern machine and during that time certain keys may not work depending on how it is setup. The benefits for this method is that when setup properly xmodmap can then be set to work in a more non-interactive mode thereby eliminating the need for the user to constantly interact with the program unless for instance when switching between differently sized keyboards for instance or keyboards that sends out different keycodes for certain keys.
For instance xmodmap is here is told to run a xmodmap specific configuration file named hhkb.xmodmap. The filename can be an arbitrary name as long as the contents specifically complies with xmodmap's "language". The way to execute it as such would be:
xmodmap hhkb.xmodmap
xmodmap when executed to run a specific string allows the user to load specific setups without the need for xmodmap to re-load the entire xmodmap setup that it was using. In other words, adding extra keycodes to make the system interpret certain commands that the keycode is equivalent to does not demand more of CPU usage compared to the former case above (when to load a xmodmap specific configuration file). In this particular case it also allows xmodmap to evaluate (to an extent) user's settings and throw any exception when there is an issue with the said command. If and when an exception happens on the interactive level, xmodmap does not apply the specific setup that the user requested. This is handy for those who are unfamiliar with the syntax for instance. Bear in mind that xmodmap does not ask the user whether or not to overwrite a certain configuration (e.g. keycode 111 = Enter on the current configuration and the new command replaces the Enter for Space) as xmodmap interprets that is exactly what the user wants without asking. Therefore it is always best to check the current configuration before modifying with the new one as once executing the new one will overwrite the old one without warning.
Example of where xmodmap is told to "test" and execute a single parameter for instance to swap Enter with Space for keycode 111 would be:
xmodmap -e "keycode 111 = space"
xmodmap can also print the current configuration setup as well as to show xmodmap's grammar (specific language/parameters) as well as plenty others. These information may be found via xmodmap -help, man/info pages.
xmodmap specific configuration file
xmodmap configuration file does not need to be concise however when dealing with multiple keyboards that have different layouts for certain keys, it is best to write a concise configuration file that way there would be no erroneous setup. Remember, the concept of "garbage in, garbage out" can also apply here.
When writing a configuration file there is no real need to be a specific layout (apart from using the correct syntaxes) to be set. However keeping a nice format of a xmodmap configuration file would not only be beneficial to a single person should they for instance share their xmodmap configuration file around.
xmodmap configuration file can be simply put into two groups for simplicity sake. The first group would be the keycodes and their specific output followed by shifts, locks, controls and mods (modifiers).
Modifiers are particularly handy for using keyboard modifiers to achieve a specific output. An example of this would be to use a Alt key to mimick AltGR behaviour so when for instance one holds down the AltGR key and presses the letter u on the keyboard (with the exact same keycode) it would appear on the screen as ü instead. However, modifiers will only work in combination of one modifier key at a time. If one wants to bind Ctrl+Alt+A to output as "å", it will not work.
Up to four modifiers can be defined (shift keys are an exception and as such cannot be used in the same manner as modifiers would work). By default the first "set" of commands from the keycode would be using the very first modifier. This does not mean that in order for one to type out the letter "a" they would need to hold Alt for instance in order for the machine to be able to produce the letter "a" on the screen. Rather as such the first set of modifiers would not only define the default behaviour of the keycode when received by the machine but when that first set of modifier is defined as such it would also output as it is. This is why in most default cases for the first set of modifiers are usually set as Alt keys.
For example, one wants to type the letter "o" on the keyboard, it would output as "o". When setting the first modifier (mod1) to left Alt the output would still be outputted as "o" regardless if left Alt was held down or not. Again this is beneficial in cases where one wants to type out "ö" for instance they would be normally using the right Alt (mimicking AltGR behaviour) to output as intended and to not confuse programs that the first set of modifier is defined as "ö" which would most likely break the default behaviour of most programs.
Locks, controls are more or less the shifts in terms of default behaviour. That is when holding down either of the Shift keys, it would capitalise the letter being outputted. However one can redefine such cases if need be. Locks are lock keys such as Caps Lock, Num Lock and Scroll lock. Controls are both left and right Control keys respectively. Ideally when rebinding certain default behaviour of such groups of keys (whether it would be Controls, Shifts or Locks) it is best to not have the same key being defined in both their respective area as well as within the Modifiers area.
TODO more expansion on the subject
