Files
gKeyMapper/docs/daemon-plan.md
2026-10-17 02:57:21 +02:00

336 lines
17 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# gKeyMapper daemon — implementation plan
Status: draft / proposal
Scope: a native C/C++ background service that detects G1–G9 (and later M1–M3/MR
and media keys) on the Logitech G910 and replays the mappings stored by the GUI.
## 1. Goals and non-goals
Goals
- Detect G-key presses in C/C++ and execute the configured action.
- Run with a very small, stable resource footprint (idle ≈ 0 % CPU, few MB RSS,
no interpreter, no polling when nothing happens).
- Reuse the existing `mappings.conf` format as the single source of truth.
- Let the GUI and the daemon run independently; either can start first.
- No Python at runtime.
Non-goals (v1)
- Profiles (M1–M3/MR), per-locale text typing (`typeout`), embedded scripting.
- GUI redesign beyond a status indicator / reload / test button.
## 2. What the Python reference does (and what we keep)
Reference: <https://github.com/JSubelj/g910-gkey-macro-support>
- G-keys are **not** exposed as distinct evdev key codes. The driver therefore
opens the keyboard's **vendor HID interface (USB interface 1) directly via
libusb**, detaches the kernel driver from that interface, and reads raw
interrupt-IN reports.
- On start it sends a control transfer to **disable the firmware F-key→G-key
binding**, so pressing G1..G9 no longer also emits F1..F9 on the normal
keyboard interface.
- Raw report byte patterns are looked up in tables
(`events.macroKeys`, `memoryKeys`, `mediaKeys`, `releaseEvents`) and turned
into actions.
- A **uinput virtual keyboard** replays `shortcut` (press, later release),
`typeout` (per-char), `uinput` (direct `KEY_*`); `run` uses `/bin/bash -c`.
- Config is JSON at `~/.config/g910-gkeys/config.json`, reloaded on directory
change (inotify via `fcntl`), plus `SIGUSR1` reload.
- Ship: a **systemd --user** service and **udev rules** with `TAG+="uaccess"` for
the device and `/dev/uinput`, so no root is needed.
Relevant USB IDs (from the udev rules): `046d:c335`, `c33f`, `c33e`, `c32b`,
`c24d`, `c22d`. The G910 in this project is `046d:c32b`.
What we keep: libusb raw HID access, disabling the F-key binding, uinput output,
config-dir watching. What we change: JSON→our line format, single-threaded
event-driven loop instead of a Python loop with fixed sleeps, fork/exec reaping,
and a real IPC channel to the GUI.
## 3. Architecture overview
```
+---------------------+ mappings.conf (shared truth) +----------------------+
| gkeymapper (GUI) | <------------ write / inotify ---------> | gkeymapper-daemon |
| GTK4 + GIO/GDBus | | libusb + uinput |
| | <===== D-Bus (session bus) ============> | GDBus + inotify |
+---------------------+ status / reload / events +----------+-----------+
| raw HID (iface 1)
v
+----------------------+
| Logitech G910 |
+----------+-----------+
| uinput
v
+----------------------+
| /dev/uinput keyboard |
+----------------------+
```
Key property: the **hot path never crosses IPC**. G-key press → decode → uinput
happens entirely inside the daemon. IPC (D-Bus) is only used for control, status
and notifications, so a slow/absent GUI never delays a keypress.
## 4. Daemon design
### 4.1 Process model
- One process, single-threaded, event loop.
- No threads in v1. `run`/`command` actions are launched with `fork()` +
`execve()`; children are reaped via a `SIGCHLD`/`signalfd` handler so no
zombies accumulate (the reference leaks a `Popen` per invocation).
- `python` type is intentionally dropped.
### 4.2 Event loop
Use one `poll()`/`epoll()` loop over:
- the **libusb** file descriptor (from `libusb_get_pollfds()`; use libusb's async
API or `libusb_interrupt_transfer` on a worker, see below),
- an **inotify** fd for the config file/directory,
- a **signalfd** for `SIGTERM`/`SIGINT`/`SIGUSR1`,
- the **D-Bus** connection (GDBus integrates with the same `GMainContext`).
Preferred: drive libusb asynchronously with `libusb_submit_transfer()` and fold
the reported poll fds into the same loop (libusb has an official "poll with
another event loop" pattern). That yields exactly **0 wakeups while idle**
(excluding the kernel's own HID interrupts). If that is too much work for v1,
fall back to a blocking `libusb_interrupt_transfer(..., timeout=1000)` inside a
dedicated thread that posts events into the main loop — still cheap (1 wake/s).
To keep GDBus and the fd loop together, the loop is easiest on the **GLib main
loop** (`GMainLoop`): GDBus, `GFileMonitor` and `GSocket`/`GSource` cover
inotify and signalfd, and libusb poll fds can be wrapped in a custom
`GSource`. GLib is already a dependency of the GUI, so this adds no new library.
If minimal footprint is the priority over convenience, a raw `epoll` loop is the
alternative; decision point in §11.
### 4.3 Device layer (`libusb`)
- Find the device by vendor/product from the supported-device table; pick
interface 1, endpoint from the same table.
- `libusb_detach_kernel_driver()` on interface 1; remember to
`libusb_attach_kernel_driver()` on shutdown (reference does this).
- Send the "disable F-key to G-key binding" control transfer
(`bmRequestType=0x21, bRequest=0x09, wValue=0x0212, wIndex=1`) and consume the
confirmation reports; ignore the known LED-return patterns
(`\x11\xff\x0f`, `\x11\xff\x10`, `\x11\xff\xff`).
- Hot-plug / re-plug: on `LIBUSB_ERROR_NO_DEVICE`/`IO` re-run discovery with a
small backoff (reference re-inits in place).
- Optional (later): `libusb_hotplug_register_callback` to react to device
add/remove without polling.
The device table in `supported_devices.py` (byte patterns per model) is ported
to a generated C++ header (`constexpr` tables) — keep it a build-time
artifact so the runtime does zero parsing.
### 4.4 Decoding
- The report is a fixed-length byte blob. Build a **compile-time lookup**:
a sorted array of `{report bytes, action id}` with binary search, or a small
open-addressed hash keyed on the first 8 bytes. This replaces the Python
`dict` + `list(...).index()` O(n) scans with O(1)/O(log n) and no allocation.
- Categories: `macro` (G1..G9), `memory` (profiles, later), `media` (later),
`release` (stops a held shortcut), and ignored/known-noise.
### 4.5 Action layer (uinput)
- Open `/dev/uinput` once; `UI_SET_EVBIT` for `EV_KEY`, register the key set used
by the mappings, `UI_DEV_CREATE`. Keep the fd for the daemon's lifetime.
- Emit events by `write()`-ing `struct input_event` (from
`<linux/uinput.h>` / `<linux/input-event-codes.h>` — no libevdev needed).
- `key` mapping = shortcut grammar `ctrl+c,ctrl+v`:
- single combo: press modifiers+key in order, remember the keys, release them
when the keyboard's `release` event arrives (mirror the reference's
`press_release_fifo` stack).
- comma list: `emit_combo()` each group (press+release).
- `command` mapping: `fork()`; in the child `setsid()`, redirect stdio to
`/dev/null`, `execve("/bin/sh", "-c", cmd)`. Reap via `SIGCHLD`.
- `disabled`: no-op.
- Give the uinput device a clear name/IDs (e.g. `gkeymapper virtual keyboard`)
so `libinput`/users can identify it.
### 4.6 Config
- Parse the existing `mappings.conf`:
`G<n>=<type>:<target>` with `type ∈ {key, command, disabled}`.
- Parse at load and on change only; the runtime holds a small pre-parsed action
per G-key (enum + fixed target buffer / `std::string`), so no parsing in the
hot path.
- Watch the config file (and, for atomic-save editors, its directory) with
inotify/`GFileMonitor`; reload on `IN_CLOSE_WRITE`/`IN_MOVED_TO`. Debounce
(e.g. 100 ms) to coalesce editor save bursts.
- Also reload on `SIGUSR1` (manual/test) and on `Reload()` D-Bus call.
### 4.7 Privileges and packaging
- udev rule with `TAG+="uaccess"` for the supported USB IDs and for
`KERNEL=="uinput"` (mirrors the reference's `60-g910-gkeys.rules`).
- `uinput` kernel module must be present; ship `/etc/modules-load.d/` fragment
or document `modprobe uinput` (here it is built in).
- **systemd --user** unit `gkeymapper-daemon.service`:
`Type=dbus`, `BusName=…`, `ExecStart=gkeymapper-daemon`,
`Restart=on-failure`, `Documentation=…`. `BusName` enables D-Bus activation,
so starting the GUI can start the daemon on demand.
- Do **not** require root. Commands run with the user's privileges (the
reference's "executed as root" note is a wiki artifact, not a design goal).
## 5. GUI ↔ daemon interaction
Three layers, from loosest to tightest:
1. **Shared state = the config file** (`~/.config/gKeyMapper/mappings.conf`).
The GUI is the writer, the daemon is a watcher/reader. This alone is enough
for basic operation and is robust: whichever side starts first, the other
converges. The daemon reloads via inotify; no coupling to the GUI process.
2. **Control/status = D-Bus on the session bus** (GDBus; part of GIO, already
linked by the GUI). Used for status, explicit reload, and notifications.
3. **Lifecycle**: the daemon is a `systemd --user` service; the GUI can start it
implicitly by calling a D-Bus method (activation) and can show whether it is
running.
### 5.1 Proposed D-Bus interface
- Bus name: `<app-id>` — decide once (§11). Suggested: `dev.rager.gkeymapper`
(replace the current placeholder `com.example.gkeymapper`).
- Object path: `/dev/rager/gkeymapper/Daemon`
- Interface: `dev.rager.gkeymapper.Daemon`
Methods
| Method | Signature | Purpose |
|---|---|---|
| `Reload` | `() -> ()` | Re-read `mappings.conf` now (GUI "Save" also calls this). |
| `GetStatus` | `() -> (s version, b running, s device, s configPath)` | Status for the GUI footer/indicator. |
| `TestMapping` | `(u index) -> ()` | Fire mapping for G1..G9 without hardware (GUI "Test" button). |
| `SetProfile` | `(s profile) -> ()` | Reserved for M-key profiles (later). |
Signals
| Signal | Signature | Purpose |
|---|---|---|
| `KeyPressed` | `(u index, s action)` | A G-key fired (for GUI highlight/history). |
| `ConfigReloaded` | `(b ok)` | Daemon finished reloading. |
| `DeviceChanged` | `(b present, s device)` | Keyboard attached/detached. |
Notes
- All are control-plane calls; none is on the keypress path.
- `Reload` is best-effort: inotify is the backstop if the call is lost.
- If D-Bus is unavailable, the daemon still works; the GUI degrades to
"no status" and "save only". Signals `SIGUSR1` (reload) / `SIGTERM` remain for
scripted use, matching the reference.
### 5.2 Interaction sequences
Save in the GUI:
```
GUI: write mappings.conf (atomic: temp + rename)
GUI: call Daemon.Reload() [optional, for immediacy]
Daemon: inotify IN_MOVED_TO -> (re)parse -> apply
Daemon: emit ConfigReloaded(ok)
```
Key press:
```
G910 --raw HID--> Daemon -> decode -> uinput emit / fork+exec
Daemon: emit KeyPressed(index, action) [GUI only, non-blocking]
```
Start-up orders:
- Daemon first, GUI later: GUI reads status via D-Bus; no config write needed.
- GUI first, daemon later: GUI writes config; on daemon start it reads the file.
### 5.3 GUI-side changes (small)
- On "Save mappings": keep writing the file, then call `Reload()` (ignore error).
- Add a footer status line: daemon running / device present / last reload, fed by
`GetStatus` + the `DeviceChanged`/`ConfigReloaded` signals.
- Optional "Test" button per row → `TestMapping(index)`.
- The key-name vocabulary must match: the capture dialog already writes
lowercase GDK key names; move the canonical name list into the shared module
(§6) so GUI and daemon agree on the same spellings.
## 6. Code layout
```
src/ # GUI (existing)
daemon/
main.cpp # event loop, wiring
device_libusb.{h,cpp} # discovery, detach/attach, read, disable-binding
decoder.{h,cpp} # report bytes -> action id (compile-time tables)
uinput_keyboard.{h,cpp}# virtual keyboard, emit / combo / press-release stack
actions.{h,cpp} # key / command / disabled execution, child reaping
config.{h,cpp} # mappings.conf parse + watch
ipc_dbus.{h,cpp} # GDBus service
generated/devices.inc # ported from supported_devices.py
shared/
mapping.{h,cpp} # parse/format mappings.conf (used by GUI and daemon)
keys.{h,cpp} # canonical names <-> gdk keyval <-> linux KEY_*
ipc_ids.h # D-Bus name/path/interface constants
data/
60-gkeymapper.rules
gkeymapper-daemon.service
uinput.conf # modules-load.d
po/ # daemon strings, reuse the existing catalogs
```
Build: the Makefile gets a second target `gkeymapper-daemon` and install rules
for the unit, udev rule and modules-load fragment. New build dependency:
`libusb-1.0-0-dev` (GLib/GIO is already required by the GUI).
## 7. Resource-efficiency measures (summary)
- No Python interpreter; native binary, tables in `.rodata`.
- Event-driven loop, **no idle polling** (libusb async + inotify + signalfd; or a
1 s blocking USB read in the simple variant).
- O(1)/O(log n) decode via compile-time tables instead of dict/linear scan.
- One `uinput` fd for the process lifetime; fixed-size event writes; no
per-event heap allocation.
- Config parsed only on load/reload; hot path is table lookups + `write()`.
- `fork`+`exec` for programs, children reaped (no zombies), stdio to `/dev/null`;
no shell parsing for `key`/`uinput` actions.
- Target footprint: idle 0 % CPU, wakeups only on real HID/DBus/file events,
RSS in the low single-digit MB.
## 8. Milestones
- **M0 – Shared core.** `shared/mapping` + `shared/keys`; refactor the GUI to use
them (still file-only). Unit tests for parse/format and key tables.
- **M1 – Device bring-up.** `daemon` opens the G910 via libusb, disables the
F-key binding, logs `G1..G9` presses. No output yet.
- **M2 – Action layer.** uinput keyboard; `key` (shortcut, incl. release) and
`command` work end-to-end. `disabled` no-op.
- **M3 – Config & lifecycle.** config parse/reload (inotify, SIGUSR1), signals,
systemd --user unit + udev rule + modules-load.
- **M4 – IPC.** GDBus service (`Reload`, `GetStatus`, `TestMapping`, signals);
GUI status line + Reload-on-save + optional Test button.
- **M5 – Polish.** Packaging/install rules, docs, translations, hardening
(hot-plug, debounce, error reporting to the GUI).
## 9. Testing strategy
- Unit: mapping parser round-trip, key-name tables, decoder against recorded
byte sequences from the reference tables.
- Device: replay captured reports into the decoder (no hardware needed).
- Integration: `evtest` / `libinput debug-events` to observe the virtual device;
compare `xev` output for a configured shortcut between reference and daemon.
- Permission tests: verify the udev rule grants access as a normal user.
- Resource check: `powertop`/`perf` or simple wakeup counting while idle.
## 10. Risks / open points
- **Device table size**: `supported_devices.py` is large; porting/generating the
byte tables is real work and model-specific.
- **Interface detach** may momentarily disturb the device; must re-attach on
exit and handle crashes gracefully.
- **Permissions**: relies on `TAG+="uaccess"` + a user service; must never fall
back to requiring root silently.
- **`command` environment**: `DISPLAY`/`WAYLAND_DISPLAY`/`XAUTHORITY` and
`PATH` differ between a user service and an interactive shell; decide whether
to inherit the user manager environment (`systemd --user` import-environment)
or document `run` snippets setting `DISPLAY=:0` explicitly.
- **Key-name vocabulary drift** between GUI (GDK names) and daemon (Linux KEY_*)
is the most likely source of silent mismatches — that is why the shared table
in M0 is mandatory before the daemon consumes the file.
- **uinput device identity**: a second keyboard appears; choose stable
name/vendor/product so the desktop does not confuse it with the real one.
## 11. Decisions to make
1. Bus name / app-id: replace `com.example.gkeymapper` with a real reverse-DNS id
(suggested `dev.rager.gkeymapper`)? Affects the `.desktop` name too.
2. Event loop: GLib `GMainLoop` (simplest, reuses GIO) vs. raw `epoll` (leanest).
3. IPC: D-Bus (idiomatic, GIO already present) vs. a Unix socket (no bus
dependency). Recommendation: D-Bus, with signals as a fallback.
4. Scope of v1: keep `key`/`command`/`disabled` only, or also port
`typeout`/`media`?