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.
omarchy-hw-fingerprint misses the Chipsailing CS9711: vendor 2541 unlisted, and its product string reads "Fingprint"
Reported by francesc · filed Sep 2, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #7535 (R-1645). GitHub close reason: completed.
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?
- Not yet mapped to any requirement or component.
- 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?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
What happens
omarchy-hw-fingerprint does not detect the Chipsailing CS9711 (USB 2541:0236), so on a machine with that reader:
- Setup → Security → Fingerprint is hidden.
default/omarchy/omarchy-menu.jsoncgates it on"when": "omarchy-hw-fingerprint". - `omarchy-setup-security-fingerprint` refuses to run, exiting 1 at the
if ! omarchy-hw-fingerprintguard before installing or configuring anything. install/user/first-run/setup-fingerprint.hookskips it too.
The reader itself works fine — libfprint-cs9711-rebase-git drives it, fprintd enrols and verifies against it, and pam_fprintd.so authenticates sudo with it. Only the detection step misses.
Why it misses — two independent reasons
$ lsusb | grep -i chip
Bus 001 Device 002: ID 2541:0236 Chipsailing CS9711Fingprint
$ cat /sys/bus/usb/devices/1-2/product
CS9711Fingprint- Vendor `2541` is not in `fingerprint_vendors` (
27c6 138a 06cb 08ff 1c7a 147e). - The product-string fallback misses too — the device's own firmware descriptor reads
CS9711Fing`print`, missing theer, so[[ $product == *fingerprint* ]]does not match.
So both detection paths fail on a typo in the hardware plus an unlisted vendor.
Suggested fix
Adding 2541 to fingerprint_vendors is enough. The vendor is single-purpose (Chipsailing makes fingerprint modules), and the existing has_kernel_driver guard already covers the concern that list is there to manage — the reader sits with no kernel driver bound, as libfprint drives it over libusb.
If you would rather not widen the vendor list, matching *fingprint* alongside *fingerprint* in the product check also catches it, though that is a workaround for one vendor's typo rather than a general improvement.
Environment
- omarchy 4.0.2-1, omarchy-settings 4.0.2-1
- Arch, Hyprland via uwsm
- Reader: Chipsailing CS9711, USB
2541:0236, external USB module - Driver:
libfprint-cs9711-rebase-git(AUR); stocklibfprintdoes not support this sensor
View raw text
## What happens `omarchy-hw-fingerprint` does not detect the Chipsailing CS9711 (USB `2541:0236`), so on a machine with that reader: - **Setup → Security → Fingerprint is hidden.** `default/omarchy/omarchy-menu.jsonc` gates it on `"when": "omarchy-hw-fingerprint"`. - **`omarchy-setup-security-fingerprint` refuses to run**, exiting 1 at the `if ! omarchy-hw-fingerprint` guard before installing or configuring anything. - `install/user/first-run/setup-fingerprint.hook` skips it too. The reader itself works fine — `libfprint-cs9711-rebase-git` drives it, `fprintd` enrols and verifies against it, and `pam_fprintd.so` authenticates sudo with it. Only the detection step misses. ## Why it misses — two independent reasons ``` $ lsusb | grep -i chip Bus 001 Device 002: ID 2541:0236 Chipsailing CS9711Fingprint $ cat /sys/bus/usb/devices/1-2/product CS9711Fingprint ``` 1. **Vendor `2541` is not in `fingerprint_vendors`** (`27c6 138a 06cb 08ff 1c7a 147e`). 2. **The product-string fallback misses too** — the device's own firmware descriptor reads `CS9711Fing`**`print`**, missing the `er`, so `[[ $product == *fingerprint* ]]` does not match. So both detection paths fail on a typo in the hardware plus an unlisted vendor. ## Suggested fix Adding `2541` to `fingerprint_vendors` is enough. The vendor is single-purpose (Chipsailing makes fingerprint modules), and the existing `has_kernel_driver` guard already covers the concern that list is there to manage — the reader sits with no kernel driver bound, as libfprint drives it over libusb. If you would rather not widen the vendor list, matching `*fingprint*` alongside `*fingerprint*` in the product check also catches it, though that is a workaround for one vendor's typo rather than a general improvement. ## Environment - omarchy 4.0.2-1, omarchy-settings 4.0.2-1 - Arch, Hyprland via uwsm - Reader: Chipsailing CS9711, USB `2541:0236`, external USB module - Driver: `libfprint-cs9711-rebase-git` (AUR); stock `libfprint` does not support this sensor
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.
No decision has been recorded yet.