docs: the quirk contribution workflow was stale, and one shipped quirk was undocumented - #94
Merged
Merged
Conversation
…k was undocumented Closes #84. Closes #85. @rampa3 reported that docs/hardware-compatibility.md still documents the OLD quirk workflow. Confirmed: it listed three steps, omitting both the registration in crates/visage-hw/src/quirks.rs and the tests. Following it produces a quirk that is embedded nowhere and read never. That is the same drift this repository has now hit five times — one process, two documents, one updated. The registration step and its guards were added to contrib/hw/README.md on 2026-08-17 and the compatibility doc was never touched. A contributor reading the wrong one ships an inert quirk, and the failure is silent by design: quirk_db() skips an unregistered entry rather than panicking, because the daemon authenticates logins and one bad contribution must not stop it starting. At runtime an unregistered quirk is indistinguishable from no quirk. #85 asked for the disable-external-tools and power-cycle test to be recommended before submission. Added to both documents as an explicit step. It is a real negative control — it is what made #76 trustworthy, since @rampa3 ran it on their own contribution before submitting. FOUND WHILE HERE, unreported: the quirk table was missing an entry. contrib/hw/ ships five quirks and quirks.rs registers five; the table listed four. The missing one is 04f2:b6d0, the Lenovo ThinkPad P14s Gen 2a — @rampa3's own contribution from #76, and the project's first external hardware quirk. An owner of that laptop reading the compatibility page would have concluded their camera was unsupported when it has shipped since v0.4.0-rc.1. Both documents now describe the same six steps, verified equal, with contrib/hw/README.md named as authoritative. An earlier revision of this change left them at six and five, which would have been the very defect being fixed. Signed-off-by: ccross <cescross2@gmail.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #84. Closes #85.
#84 — the workflow was three steps and needed five
@rampa3 is right.
docs/hardware-compatibility.mddocumented:visage discover→ VID:PID.tomland submit a PRFollowing that produces a quirk that is embedded nowhere and read never. The registration in
crates/visage-hw/src/quirks.rsand the tests were added tocontrib/hw/README.mdon 2026-08-17 and this document was never touched.This is the same drift the repo has now hit five times — one process, two documents, one updated (see also #75, #78,
TimeoutStopSec, and the MSRV field in #93).And it fails silently by design:
quirk_db()skips an unregistered entry rather than panicking, because the daemon authenticates logins and one bad contribution must not stop it starting. The cost is that at runtime an unregistered quirk is indistinguishable from no quirk — no error, no crash, the emitter just never fires.#85 — the power-cycle test is now a step, not folklore
Disabling external emitter tools and power-cycling before testing is a real negative control, and it is what made #76 trustworthy — @rampa3 ran it on their own contribution before submitting. It is now an explicit step in both documents rather than something that only exists in a PR comment.
Found while here, and nobody had reported it
The quirk table was missing an entry.
The missing one is
04f2:b6d0— the Lenovo ThinkPad P14s Gen 2a, @rampa3's own contribution from #76 and the project's first external hardware quirk. An owner of that laptop reading the compatibility page would have concluded their camera was unsupported, when it has shipped since v0.4.0-rc.1.One note on the change itself
Both documents now describe the same six steps, verified equal, with
contrib/hw/README.mdnamed as authoritative. An earlier revision of this branch left them at six and five — which would have been precisely the defect being fixed, in the PR fixing it.🤖 Generated with Claude Code