Seth Kenlon

Authored Comments

I sometimes do this with Xmodmap.

In theory, you have to use `xev` to find out the correct keycodes for your keyboard, but honestly I'm using the same codes across three systems without a problem.

Put something like this in a file called ~/.xmodmap
"""
remove Lock = Caps_Lock
remove Control = Control_L
keycode 66 = Control_L
keycode 37 = Control_L
add Control = Control_L
"""

This removes the "lock"iness of the CapsLock key,
then removes control from the left control to provide a clean slate.
Then it assigns keycode 66 (caps lock on my keyboard) the Control_L signal.
Then it assign keycode 37 (left control on my keyboard) the Control_L signals.
Then it ensures that Control_L is a Control key.

Strictly speaking, this is overkill, but I have found the added explicitness to be useful within some stubborn environments.

To manifest this in your session, run:

$ xmodmap ~/.xmodmap

To make it happen at login, run the xmodmap command as part of your .bash_rc or .bash_profile or .profile or whatever autostart script you prefer.

Great question, Osqui. Systemd .device units can do the same task, and that's the topic of my next article (intended as a companion to this one).

However, udev is still important for two reasons: firstly, not all Linuxen ship with systemd, and secondly because there are some things not visible to Systemd that are visible to udev, so you would have to use udev tags to prompt Systemd to act.

Given these two factors, I'm not clear on whether Systemd intends to eventually replace udev or just provide an additional means of achieving many of the same results. I don't always love udev (I'm still not convinced it's actually able to reload its rules without a reboot) but I'd hate to lose it entirely, since my Slackware systems don't run Systemd.