mesh-tools
652b00b25b
mesh/merge-gate checking again: the gate refused `unknown` because the controller judged with a node-engine validator pinned before mesh-host #117; mesh-co…
mesh/repo-check checking again: the gate refused `unknown` because the controller judged with a node-engine validator pinned before mesh-host #117; mesh-co…
mesh/delivery-group group feat/owned-paths checking: 0 of 2 member(s) ready
mesh/delivery superseded: a newer head of the same pull request
Every directory and archive resource carries `unknown`: move-out for a home folder whose program writes nothing there (the node-engine, delivered in mesh-host #117, moves the rest to ~/.local/state/mesh-moved/<module>/ with a list), module for ~/.ssh and ~/.claude, program elsewhere; `knows` keeps what a program or the operator relies on (powerlevel10k's compiled files, i3's scripts and the asus/g14 drop-ins, dunst's slack rule, betterbird's records, node-env's forge credential, issue 1033). Two shared folders are no longer declared. Each module's README says it. checks/owned holds every manifest to it; checks/sshdir stays while main's merge check runs it (issue 1035). Tests that pin a manifest follow the new key only. Reviewed in three rounds.
55 lines
3.0 KiB
Markdown
55 lines
3.0 KiB
Markdown
# triggerhappy
|
|
|
|
The machine's hotkeys (novox/hq ADR 0212). triggerhappy is the daemon that sees the keys the window
|
|
manager never does, such as a laptop's vendor keys. This module holds `node-hotkeys` and owns the
|
|
daemon's configuration and service. The keys themselves belong to the modules they are for.
|
|
|
|
## What it owns
|
|
|
|
| | |
|
|
|---|---|
|
|
| `/etc/triggerhappy/triggers.d/mesh.conf` | every module's trigger lines, placed with `${contribution:node-hotkeys:trigger}` in module order, each module's under a `# <module>` line |
|
|
| `triggerhappy.service.d/mesh.conf` | the daemon reads only the mesh's file, and runs every trigger as the operator's account (`--user`), after opening the devices as root |
|
|
| `triggerhappy.service` | running and enabled; restarted when either file changes |
|
|
|
|
## How a module adds a key
|
|
|
|
A module declares a `contributions` entry with `seat` `node-hotkeys`, `kind` `trigger`, and as
|
|
`content` one or more trigger lines in triggerhappy's own grammar: the key, its state (`1` pressed,
|
|
`2` held, `0` released), and the command. The command runs as the operator's account. It needs no
|
|
`su` and should name the contributing module's own scripts. The contribution depends on this seat
|
|
(ADR 0210), so a module with keys is refused on a machine without a hotkey holder.
|
|
|
|
To find a key's name, press it while `triggerhappy_dump` listens.
|
|
|
|
## Tools
|
|
|
|
| tool | |
|
|
|---|---|
|
|
| `triggerhappy_keys` | every trigger in force: key, state, command, file and contributing module; warns about a key bound twice |
|
|
| `triggerhappy_devices` | the input devices, by name and event handler |
|
|
| `triggerhappy_dump` | listen for a few seconds and say which keys arrived (needs `sudo -n`) |
|
|
| `triggerhappy_check` | running, as the account, only the mesh's file, no duplicates |
|
|
|
|
## Installed as found
|
|
|
|
triggerhappy is not in the distribution's repositories, so the host cannot install it, and the module
|
|
declares no package. It depends on the machine having it: the service resource refuses loudly, by
|
|
name, on a machine without it. How software from the user repository reaches the mesh, as a pinned
|
|
archive (ADR 0205) or through a repository the mesh serves, is research 027's first question.
|
|
|
|
## Migration
|
|
|
|
On the laptop, the model's module wrote `asus-g14.conf` and its own drop-in. Both move here: the
|
|
model's module now contributes its keys. When it is pushed, the host gives back the original
|
|
`asus-g14.conf` it kept, which still calls the predecessor's `as-user` scripts. Delete that file
|
|
afterwards. The daemon reads only `mesh.conf` from then on, so the file would not fire, but
|
|
`triggerhappy_check` flags any file besides the mesh's.
|
|
|
|
## Files it does not know
|
|
|
|
Each directory or archive this module declares says how it treats a file it did not write (ADR 0422, ADR 0416).
|
|
|
|
- `/etc/systemd/system/triggerhappy.service.d`: everything in it is the program's; the mesh moves nothing out (ADR 0422 §2).
|
|
- `/etc/triggerhappy/triggers.d`: everything in it is the program's; the mesh moves nothing out (ADR 0422 §2).
|