Switching to Colemak on Linux

Where a Colemak layout lives on Linux

Colemak on Linux is not a single system-wide setting. The layout is applied by whatever is reading the keyboard at that moment, so it lives in one of three places: the text console, the X11 server, or your Wayland compositor. Set it in the wrong one and nothing appears to happen.

A fourth option skips the operating system completely. A keyboard that remaps in its own firmware, such as a board running QMK or VIA, sends the codes for the letters you want, so every machine you plug it into types Colemak with no configuration at all, including a server console and a machine you do not own. The cost is that your laptop keyboard still types QWERTY.

The rest of this guide covers the three software layers, the reason a remote server almost never needs any of them, and what the switch does to Vim and to your terminal shortcuts.

Check what your system already has

Run these before you change anything. They print the current setting and the list of Colemak variants your X keyboard database offers.

localectl status
setxkbmap -query
localectl list-x11-keymap-variants us | grep colemak

The last command should print colemak and colemak_dh. Colemak has been in xkeyboard-config for years. Colemak-DH arrived in version 2.34, so only an old release will be missing it. As of August 2026, Ubuntu 24.04 and Debian 13 both ship a newer version than that.

If setxkbmap -query reports that it cannot open a display, you are in a Wayland session and the compositor owns the layout. That case has its own section below.

Colemak or Colemak-DH

Colemak moves seventeen keys from their QWERTY positions and leaves ten alone, including Z, X, C and V, so the undo, cut, copy and paste shortcuts stay where your left hand expects them. That compatibility is the whole reason the layout looks the way it does.

Colemak-DH is a modification of Colemak. It relocates D, B and G, and it swaps H with M, because plain Colemak types both D and H by stretching an index finger into the middle column of the keyboard. The official mod keeps every letter on the same finger it used in Colemak, so a Colemak typist moving to DH faces a small change rather than a new layout. The XKB variant is colemak_dh, with colemak_dh_iso for keyboards that have the extra key beside the left shift.

Coming from QWERTY, either one is a single relearning job, so choose on comfort and stop there. Switching layout a second time costs about as much as the first, because the thing you are rebuilding is motor memory tied to key positions.

Set Colemak in X11 with setxkbmap and localectl

setxkbmap us -variant colemak
setxkbmap -query

setxkbmap -query should now report variant: colemak, and typing in any window should produce Colemak letters. The change lasts as long as the X session and writes nothing to disk, which makes it the safe way to try the layout for an hour.

To keep it across reboots:

sudo localectl set-x11-keymap us pc105 colemak
localectl status

The argument order is layout, then model, then variant. localectl status should now show X11 Layout: us and X11 Variant: colemak. localectl also converts the choice into the closest console keymap unless you add --no-convert, so on many systems this single command covers the tty as well. On Debian and Ubuntu, check /etc/default/keyboard afterwards, because that file is what console-setup reads at boot.

Set Colemak on Wayland

A Wayland session has no X server to configure. The compositor loads the keymap and hands it to each application, so the layout is a compositor setting. This is why setxkbmap looks broken there: it either fails to find a display, or it changes XWayland only, and your native Wayland applications ignore it.

On GNOME the setting is a gsettings key:

gsettings set org.gnome.desktop.input-sources sources "[('xkb', 'us+colemak')]"

It applies immediately, with no logout. The string us+colemak is the layout and the variant joined with a plus sign.

On sway, put it in ~/.config/sway/config:

input type:keyboard {
    xkb_layout us
    xkb_variant colemak_dh
}

Reload with swaymsg reload. swaymsg -t get_inputs lists every input device with the layout it is using, which is the check to run when only one keyboard misbehaves.

On KDE Plasma, open System Settings, then Keyboard, then Layouts, and add English (US) with the Colemak variant.

Set Colemak on the text console

The console is the plain-text tty you reach with Ctrl+Alt+F3, and it keeps its own keymap. Nothing you set in X11 or in a compositor reaches it, which matters if you work on a terminal workbench on a bare virtual console.

On Debian and Ubuntu, edit /etc/default/keyboard:

XKBMODEL="pc105"
XKBLAYOUT="us"
XKBVARIANT="colemak"
XKBOPTIONS=""

Then apply it:

sudo setupcon

Type on the console to confirm. console-setup converts that XKB description into a console keymap with ckbcomp, so the console and X share one description on these systems.

On distributions that use kbd keymaps directly, ask for the name first:

localectl list-keymaps | grep -i -e colemak -e latin9
sudo localectl set-keymap en-latin9

The kbd package ships the Colemak console map as i386/colemak/en-latin9, so the name you pass is usually en-latin9 and not colemak. Pass a name that appears in the list, because a name that does not exist is rejected.

sudo loadkeys en-latin9 changes the current console immediately, and sudo loadkeys us puts it back. Treat loadkeys as a test rather than a configuration: it lasts until reboot, and on Debian and Ubuntu the boot-time setupcon run restores whatever /etc/default/keyboard says.

Does a headless VPS need a Colemak layout?

Almost never, and the reason is worth understanding. SSH carries characters, not key positions. Your terminal emulator receives the key press, your local layout turns it into a character, and only that character travels down the connection. The server receives n with no way to know which physical key produced it. So the layout you set on your laptop follows you into every SSH session, into tmux, and into every editor you run remotely, and the remote machine needs no keyboard configuration at all.

Keep that in mind before you start editing keyboard files on production boxes. If you manage a fleet of Linux servers, the layout belongs to the machine in front of you and not to the fleet, so it has no place in your provisioning. The first ten minutes on a new VPS holds more useful work than this.

Two exceptions are worth planning for. The first is a console attached to the machine itself. The browser console in a provider panel usually presents itself to the virtual machine as a keyboard, so key presses arrive as scancodes and the server's own console keymap decides which character appears. That is the one place a layout set on the server takes effect, and it is also your rescue path when SSH stops working, so a half-finished console keymap there is a real risk.

A serial console behaves differently, because it carries characters and your local layout applies. The second exception is a shared machine. A console keymap is system-wide, so setting Colemak on a box other people log into changes it for them too, and they will not guess why.

What happens to Vim's hjkl keys

On Colemak, h does not move. The other three do. j sits under QWERTY's Y, k sits under QWERTY's N, and l sits under QWERTY's U, so the cursor keys are spread across three rows instead of sitting under four fingers.

There are two workable answers, and both have real users.

Keep the defaults and relearn the positions. Nothing else in your setup breaks, every plugin keeps working, and every Vim tip written by anyone else still applies to you exactly as written.

Or remap the four keys that sit under your right hand where hjkl used to be. On Colemak those keys give h, n, e and i. On Colemak-DH the same four physical keys give m, n, e and i, because DH swapped H with M.

noremap n j
noremap e k
noremap i l
noremap l i
noremap k n

n now moves down, e moves up, i moves right, and h was already left. The last two lines hand back the commands you displaced: l starts insert mode, and k repeats the last search. Give the capitals the same treatment, or Shift plus a cursor key will surprise you.

Vim's langmap option does a similar job in fewer lines:

set langmap=nj,ek,il,li,kn

Each pair reads as the character you typed followed by the character Vim should act on. It applies to normal mode only, so insert mode still types Colemak text normally. Two limits are documented in Vim's own help: langmap does not apply to Ctrl or Alt combinations, and plugin mappings written against the default keys can behave strangely under it.

Whichever you choose, choose once. A remap you abandon after a month costs you another month.

What happens to terminal shortcuts

A terminal control code comes from the character, not from the physical key, so every Ctrl shortcut moves with the layout. Ctrl+C, Ctrl+Z, Ctrl+X and Ctrl+V keep their positions, because Colemak deliberately leaves Z, X, C and V where QWERTY has them.

Four shortcuts you use every day do move. Ctrl+D, which ends input, is now where QWERTY has G. Ctrl+R, the history search, is where QWERTY has S. Ctrl+E, end of line, is where QWERTY has K. Ctrl+U, which clears the line, is where QWERTY has I.

tmux keeps its default prefix, because B does not move in Colemak. On Colemak-DH, B moves to the top row and the prefix goes with it, which is the first thing you will notice if you keep a long-running tmux session on a VPS. Rebinding the prefix to a key you like is a one-line change, and it is easier than retraining the same reflex twice.

Desktop shortcuts follow the same rule. A binding on Super+E moves with the layout, because it is defined by the character. A binding on Super+F1 stays put, because function keys are not remapped by the layout.

How long the switch costs you

Nobody can give you a number for your hands. Touch typing is motor memory. You are not learning where the letters are, you are rebuilding the reflex that turns a word into a finger sequence, so the only input that helps is time spent typing.

What people report, and these are self-reported practice logs rather than a controlled measurement, is a first week far below half their old speed and a return to that old speed somewhere between one and three months of daily use. The spread between individuals is wide, so treat those figures as a shape rather than a schedule.

Two habits make it slower. Alternating between QWERTY and Colemak through the day keeps both reflexes weak, so most people who finish the switch commit fully on their main machine. Starting during a busy week means typing badly under time pressure, which trains you to look down at the keys.

Set up the way back before you need it, because the moment you will want QWERTY again is the moment something is broken and someone is waiting.

How to switch back to QWERTY quickly

In X11, setxkbmap us restores QWERTY immediately. On the console, sudo loadkeys us does the same. To undo the persistent setting, run sudo localectl set-x11-keymap us.

A toggle is better than a command you have to type in a layout you cannot type in yet:

setxkbmap -layout us,us -variant colemak, -option grp:win_space_toggle

This loads Colemak as the first layout and plain US as the second, and Super+Space cycles between them. The trailing comma in colemak, is not a typo: it gives the first layout the colemak variant and the second layout none. On GNOME, add both input sources in Settings, where Super+Space already switches them.

Two password prompts live outside your desktop session and need separate attention. The login greeter starts before your session settings are applied, so test it by logging out rather than by trusting the setting. If the disk is encrypted, the passphrase prompt runs from the initramfs, which carries its own copy of the keymap. On Debian and Ubuntu, rebuild it with sudo update-initramfs -u after you change /etc/default/keyboard, then reboot once to test while you still have another way into the machine.

Can I keep one program on QWERTY?

The layout is applied before an application sees the key. The X server or the compositor turns a scancode into a character and hands over the character, so an application cannot ask for a different layout. It can only remap what it receives. That is why the Vim fix lives in Vim's config, and why there is no general per-window layout switch to reach for.

Two approaches do work. The first is per device. If the QWERTY typing happens on a separate keyboard, set the layout on that device instead of on the system:

xinput list
setxkbmap -device 12 -layout us

Take the id from xinput list, and confirm by typing on each keyboard in turn. sway accepts the same settings per input identifier from swaymsg -t get_inputs, and a more specific selector wins over type:keyboard.

The second approach is to do the remap inside the application, as Vim's langmap does. Games almost always have a key binding screen, and rebinding movement keys there takes less time than fighting the layout from outside. For anything with neither, bind the layout toggle above and press it before you launch.

FAQ

Do I need to set Colemak on my VPS?

No, if you reach it over SSH. SSH carries characters, so your layout is resolved on your laptop before anything is sent, and the server receives the same bytes it would receive from a QWERTY typist. The exception is the browser console in your provider's panel, which attaches to the virtual machine as a keyboard and uses the server's own console keymap. That console is your rescue path when SSH fails, so change it only if you are sure, and test it while SSH still works.

Should I learn Colemak or Colemak-DH?

Both are one relearning job from QWERTY, so choose on comfort rather than on migration cost. Colemak-DH relocates D, B and G and swaps H with M, because plain Colemak types D and H with an index-finger stretch into the middle column. The XKB variant names are colemak and colemak_dh, with colemak_dh_iso for keyboards that have the extra key next to the left shift. Run localectl list-x11-keymap-variants us | grep colemak to see which ones your system offers.

What happens to Vim's hjkl keys on Colemak?

h stays where it is. j moves under QWERTY's Y, k under QWERTY's N, and l under QWERTY's U, so the cursor keys spread over three rows. You can relearn them where they land, which keeps every plugin and every tutorial valid, or remap the four keys under your right hand: h, n, e and i on Colemak, and m, n, e and i on Colemak-DH. Vim's langmap option does the same job for normal mode, though it does not apply to Ctrl combinations and it can confuse plugin mappings.

How long until I type at my old speed again?

Expect weeks rather than days, because this is motor memory and the only input is practice. Self-reported practice logs commonly describe a first week far below half the old speed and a return to it after one to three months of daily use. Alternating between QWERTY and Colemak every day stretches that out, because neither reflex gets to settle.

Why did setxkbmap do nothing on my desktop?

Almost certainly because the session is Wayland. Under Wayland the compositor owns the keymap and pushes it to each application, so setxkbmap either cannot find a display or changes XWayland only, and native applications ignore it. Set the layout in the compositor instead: the org.gnome.desktop.input-sources gsettings key on GNOME, xkb_variant in the sway config, or the Layouts page in KDE Plasma's System Settings.