Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Keyboard backlight OSD missing when the toggle key is firmware-handled (e.g. Dell)
Reported by bartcho · filed Aug 21, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
Summary
On laptops where the keyboard-backlight toggle key is handled by firmware (the EC), pressing it changes the backlight but no On-Screen Display (OSD) appears. This worked with the pre-Quattro swayosd OSD and regressed with the Quickshell OSD introduced in Quattro (4.0.0).
Steps to reproduce
- On a Dell laptop (keyboard-backlight device
dell::kbd_backlight, max brightness level 2). - Press the keyboard backlight toggle key (emits
XF86KbdLightOnOff).
Expected
An OSD overlay showing the keyboard-backlight level, like the volume/display OSDs.
Actual
The backlight toggles, but no OSD appears.
Root cause
The Quickshell keyboard-backlight OSD is driven purely by key events:XF86KbdBrightnessUp/Down/OnOff → Hyprland bind (/usr/share/omarchy/default/hypr/bindings/media.lua) → omarchy-brightness-keyboard → omarchy-osd -i keyboard -p <n>.
On Dell (and likely other firmwares), the single keyboard-backlight key is consumed by the EC: the LED brightness changes in sysfs (/sys/class/leds/dell::kbd_backlight/brightness) but the XF86KbdLightOnOff event never reaches Hyprland, so the bound command — and therefore the OSD — never runs. There is no udev/inotify watcher on the backlight device, so the OSD only ever appears when an omarchy command explicitly summons it.
The old swayosd path apparently surfaced the OSD from the brightness change itself, which is why it worked pre-Quattro; Quattro's OSD has no equivalent hardware-event hook.
Suggested fix
Add a watcher (udev rule or an inotify loop) on /sys/class/leds/*kbd_backlight*/brightness that summons the OSD whenever the value changes, so firmware-handled toggles also show it. This mirrors how other DE/HUDs surface keyboard-backlight changes regardless of the input source.
Environment
- Omarchy: 4.0.0-1 (Quattro)
- Kernel: 7.1.8-arch1-3
- Device:
dell::kbd_backlight, max brightness 2 (levels 0/1/2 → 0/50/100%) omarchy debugis not available in this build, so no debug log URL is attached.
Workaround (user-space)
A sysfs watcher + user systemd service that calls omarchy-osd -i keyboard -p <pct> on change restores the OSD. Bindings can be rebound with --no-osd so the watcher is the single OSD source and there is no duplicate popup.
View raw text
## Summary On laptops where the keyboard-backlight toggle key is handled by firmware (the EC), pressing it changes the backlight but no On-Screen Display (OSD) appears. This worked with the pre-Quattro `swayosd` OSD and regressed with the Quickshell OSD introduced in Quattro (4.0.0). ## Steps to reproduce 1. On a Dell laptop (keyboard-backlight device `dell::kbd_backlight`, max brightness level 2). 2. Press the keyboard backlight toggle key (emits `XF86KbdLightOnOff`). ## Expected An OSD overlay showing the keyboard-backlight level, like the volume/display OSDs. ## Actual The backlight toggles, but no OSD appears. ## Root cause The Quickshell keyboard-backlight OSD is driven purely by key events: `XF86KbdBrightnessUp/Down/OnOff` → Hyprland bind (`/usr/share/omarchy/default/hypr/bindings/media.lua`) → `omarchy-brightness-keyboard` → `omarchy-osd -i keyboard -p <n>`. On Dell (and likely other firmwares), the single keyboard-backlight key is consumed by the EC: the LED brightness changes in sysfs (`/sys/class/leds/dell::kbd_backlight/brightness`) but the `XF86KbdLightOnOff` event never reaches Hyprland, so the bound command — and therefore the OSD — never runs. There is no udev/inotify watcher on the backlight device, so the OSD only ever appears when an omarchy command explicitly summons it. The old `swayosd` path apparently surfaced the OSD from the brightness change itself, which is why it worked pre-Quattro; Quattro's OSD has no equivalent hardware-event hook. ## Suggested fix Add a watcher (udev rule or an inotify loop) on `/sys/class/leds/*kbd_backlight*/brightness` that summons the OSD whenever the value changes, so firmware-handled toggles also show it. This mirrors how other DE/HUDs surface keyboard-backlight changes regardless of the input source. ## Environment - Omarchy: 4.0.0-1 (Quattro) - Kernel: 7.1.8-arch1-3 - Device: `dell::kbd_backlight`, max brightness 2 (levels 0/1/2 → 0/50/100%) - `omarchy debug` is not available in this build, so no debug log URL is attached. ## Workaround (user-space) A sysfs watcher + user systemd service that calls `omarchy-osd -i keyboard -p <pct>` on change restores the OSD. Bindings can be rebound with `--no-osd` so the watcher is the single OSD source and there is no duplicate popup.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 08:16 UTC