Skip to content

keyd-setup.md

Latest commit

 

History

History
141 lines (93 loc) · 7.3 KB

keyd-setup.md

File metadata and controls

141 lines (93 loc) · 7.3 KB
Raw

keyd setup

Guides related to my keyd setup.

Repeat previous key

Both Meta keys are overloaded in keyd-default.conf: holding either key keeps normal Meta behavior, while tapping either key runs keyd's repeat() action through overloadt2 with a 120 ms tap window. This repeats the last emitted key or macro, so typing three backticks can be done as:

` meta meta

Use overloadt2, not plain overload, for this binding. repeat() holds the previous output until the repeat key is released; plain overload runs tap actions during the physical key release and can leave the repeated key held.

Modifier symmetry

Any keyd mapping that uses a paired keyboard modifier should keep working with both the left and right physical modifier keys. In keyd layer headers, right Alt is represented as altgr, so every ...+alt layer needs an equivalent ...+altgr layer with the same mappings unless a task explicitly asks for an asymmetric binding.

For example, Ctrl+Alt+V must include both Alt variants:

[control+alt]
v = layer(signal_show_clipboard_history)

[control+altgr]
v = layer(signal_show_clipboard_history)

Readline-aware behavior

Keyd is the right place to remap keys, but not to make decisions based on the current readline cursor position. If a shortcut needs to behave differently at the start or end of a shell edit buffer, put the stateful part in bash/readline itself with bind -x and the READLINE_LINE / READLINE_POINT variables, then let keyd keep emitting the same physical chord.

If a keyd-only repeat is good enough and you want to keep the modifier physically held, use an explicit oneshotm repeat layer and put the repeated binding in a composite layer that also includes the held modifier. Avoid overloadi for readline repeats: it keys off any recent non-action key, so normal typing can keep the idle window alive and make a later navigation press look like a repeat.

Ctrl+Alt+P opens the shared snippets picker through signal_open_snippets; the picker reads the public utilities/dot-local/share/dotfiles/snippets/ tree and, when present, the optional private for-my-eyes-only/dot-local/share/dotfiles/snippets/ tree. Ctrl+Alt+B opens the Pedalboard MIDI profile picker through signal_open_pedalboard_profiles; profile metadata is owned by audio/dot-local/share/dotfiles/pedalboard-midi-profiles.tsv.

MIDI mode and keyd limits

MIDI controller mode should be modeled as keyd layers observed through keyd listen, not as a second evdev consumer. A daemon that opens keyd virtual keyboard through evdev and then calls EVIOCGRAB fights the existing keyd device owner, can fail with resource busy, can miss key-up/state transitions when another remapper is in the path, and can leak raw keyboard shortcuts into REAPER while MIDI learn is waiting. Keep keyd as the only physical keyboard consumer: Tab+m toggles the persistent [midi] layer, keyd emits +midi_* and -midi_* layer events, and keyboard-midi-controller translates those layer events to MIDI.

The stock keyd parser is also too small for a BeatStep-style layer set. This repository patches both MAX_LAYERS and MAX_SECTIONS from 32 to 128 with assets/patches/keyd/increase-max-layers-for-midi.patch; both constants matter because each declared layer is also an INI section. If either constant stays at 32, keyd check or the running keyd service can abort while parsing the rendered /etc/keyd/default.conf.

When the keyd binary itself has just been rebuilt or patched, restart keyd.service; do not rely on keyd reload. Reload asks the already-running daemon to parse the new config, so an old daemon that still has MAX_SECTIONS=32 can crash on the expanded MIDI config while the keyd reload client spins at high CPU waiting for a reply.

Latin chars with keyd

This guide is specific to xorg only

Before discovering keyd I had to constantly switch between english and spanish layouts in order for me to write words like mañana but at the same time use chars like <>|~... this was a very painful workflow.

Now instead of switching between language layouts I just map all these special characters (á, é, í, ó, ú, ñ) to a <modifier>+<letter> combination. For example, pressing alt+a writes á. This is far more quickly and pleasant than having to switch layouts and then remember to switch then back.

Process to map new chars

My process to map new chars is as follows:

  1. First on /etc/keyd/default.conf I add the new special char that I want to use:
[ids]

*

[main]

leftalt = layer(spanish)

[spanish:A]

# Map a to á
a = á

...

# Map n to ñ
n = ñ

[spanish+shift]

# Map a to Á
a = Á

...

# Map n to Ñ
n = Ñ
  1. That's not all, you need to find a keyd-specific XKB sequence string for your char (á, ñ, etc...) from here: /usr/share/keyd/keyd.compose and then copy it to your .XCompose file, usually in ~/.XCompose or create a new one if it doesn't exists.

Example

Find and copy your char from the /usr/share/keyd/keyd.compose file (that file is automatically generated by keyd upon installation):

...
<Cancel> <0> <1> <1> : "¥"
<Cancel> <0> <1> <2> : "¦"
<Cancel> <0> <1> <3> : "§"
<Cancel> <0> <1> <4> : "¨"
<Cancel> <0> <1> <5> : "©"
<Cancel> <0> <1> <6> : "ª"
<Cancel> <0> <1> <7> : "«"
<Cancel> <0> <1> <8> : "¬"
<Cancel> <0> <1> <9> : "­"
<Cancel> <0> <1> <a> : "®"
<Cancel> <0> <2> <p> : "á" <- copy this
<Cancel> <0> <3> <5> : "ñ" <- copy this
<Cancel> <0> <1> <t> : "Á" <- copy this
<Cancel> <0> <2> <9> : "Ñ" <- copy this
...
  1. Paste your keyd-specific XKB sequence string on your ~/.XCompose file like this:
<Cancel> <0> <2> <p> : "á"
<Cancel> <0> <3> <5> : "ñ"
<Cancel> <0> <1> <t> : "Á"
<Cancel> <0> <2> <9> : "Ñ"
  1. Finally you must logout and login again so the ~/.XCompose can be re-executed by your system again.

Important

Even thought the man keyd page recommends this:

Unicode Support If keyd encounters a valid UTF8 sequence as a right hand value, it will try and translate that sequence into a macro which emits a keyd-specific XKB sequence. In order for this to work, the sequences defined in the compose file shipped with keyd (/usr/share/keyd/keyd.compose) must be accessible. This can be achieved globally by copying the file to the appropriate location in /usr/share/X11/locale, or on a per-user basis by symlinking it to ˜/.XCompose. E.g. ln -s /usr/share/keyd/keyd.compose ˜/.XCompose Additionally you will need to be using the default US layout on your display server. Users of non-english layouts are advised to set their layout within keyd (see Layouts) to avoid conflicts between the display server layout and keyd's unicode functionality. Note: You may have to restart your applications for this to take effect. Note 2: The generated compose sequences are affected by modifiers in the normal way. If you want shift to produce a different symbol, you will need to define a custom shift layer (see the included layout files for an example).

That was actually a pretty bad idea for me because my i3 keymaps (and the whole i3 app) stopped working so that's why I don't symlink the whole keyd.compose file and instead just copy the lines that I need from it.