docs: link the published device driver catalog - #720
Conversation
|
Hold this one — the link target does not resolve yet. GitHub Pages is not enabled on That matters more than usual today. The site's four install buttons and its closing CTA had been pointing at five README anchors deleted months ago — every visitor who clicked one landed at the top of the README with no instructions in view, and nothing noticed. srcfl/ftw-web#6 fixed it this morning; #719 is building the guard so it cannot recur. Adding a fresh dead link on the same day would be a poor trade. The same dependency blocks srcfl/ftw-web#7, which points "Browse drivers" at the same URL, and srcfl/device-drivers#51 is still an open draft. Order that works: enable Pages on |
|
Done and merged in the device driver repo. |
|
Retracting the hold — the blocker is gone. Pages is live on Same applies to srcfl/ftw-web#7, which points "Browse drivers" at the same URL and was waiting on the same dependency. Note those two conflict with each other on the "Write a driver" / "Browse drivers" block — ftw-web#6 already landed and rewrote it, so #7 needs a rebase before it will merge. This one is |
miravoss26
left a comment
There was a problem hiding this comment.
Adds a README paragraph and a docs-list entry linking the published device catalog (srcfl.github.io/device-drivers), with the useful caveat that a listing isn't an install claim.
- Docs-only, one file. CI is green (go test + vet passed, the rest path-skipped).
- No secrets, deps, or network/authz surface. The link is the org's own Pages domain.
Accurate and consistent with the catalog wording elsewhere. Safe to merge from my read. (mergeable shows UNKNOWN, but that's GitHub not having recomputed yet; nothing in the diff blocks it.)
…uide FTW and srcfl/device-drivers both carried a "how to write a driver" guide, 220 and 268 lines. They overlap on the entry points, the DRIVER block, the sign convention and the build-and-test loop, and there is no mechanism that keeps them agreeing. The upstream copy is built around blueprint/BLUEPRINT.lua and is the one a driver author reaches for, so the FTW copy is the one that quietly goes stale — and #720 is currently moving the website's "Write a driver" link upstream, which makes that worse. Split by what each repository actually owns. Authoring moves upstream, and this page keeps what only FTW can answer: what its host registers, how a capability is granted, when the host calls driver_default_mode, where FTW resolves a driver file from, and how to test one against a running instance. The host API is now a table generated from what lua.go registers, including http_patch and its allow_write gate from #716. Every name in it was checked against host.RawSetString in lua.go; the two Blixt L1 aliases stay in the prose below the table rather than the table itself. Removed content is covered elsewhere: entry points, sign convention, manifest and make targets upstream, and the drivers-beta promotion paragraph was already a duplicate of device-repository.md, which this page links to. README is untouched — #720 is editing the same section and has right of way. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
The README told a reader to send driver changes to srcfl/device-drivers but never said which devices are already covered. That repository now publishes a searchable catalog, generated from its manifests and driver sources on every push, so this points at it from the Drivers section and the documentation index. The page states hardware evidence rather than implying it: 5 of the 80 drivers report being confirmed against physical hardware and 28 report that they have not been, which matches what FTW actually installs. Documentation only, no user-visible change, so no Changeset. Signed-off-by: Hugo Karlsson <48095810+HuggeK@users.noreply.github.com> Co-authored-by: HuggeK <48095810+HuggeK@users.noreply.github.com>
9c69092 to
f5a2fae
Compare
…uide FTW and srcfl/device-drivers both carried a "how to write a driver" guide, 220 and 268 lines. They overlap on the entry points, the DRIVER block, the sign convention and the build-and-test loop, and there is no mechanism that keeps them agreeing. The upstream copy is built around blueprint/BLUEPRINT.lua and is the one a driver author reaches for, so the FTW copy is the one that quietly goes stale — and #720 is currently moving the website's "Write a driver" link upstream, which makes that worse. Split by what each repository actually owns. Authoring moves upstream, and this page keeps what only FTW can answer: what its host registers, how a capability is granted, when the host calls driver_default_mode, where FTW resolves a driver file from, and how to test one against a running instance. The host API is now a table generated from what lua.go registers, including http_patch and its allow_write gate from #716. Every name in it was checked against host.RawSetString in lua.go; the two Blixt L1 aliases stay in the prose below the table rather than the table itself. Removed content is covered elsewhere: entry points, sign convention, manifest and make targets upstream, and the drivers-beta promotion paragraph was already a duplicate of device-repository.md, which this page links to. README is untouched — #720 is editing the same section and has right of way. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
…uide FTW and srcfl/device-drivers both carried a "how to write a driver" guide, 220 and 268 lines. They overlap on the entry points, the DRIVER block, the sign convention and the build-and-test loop, and there is no mechanism that keeps them agreeing. The upstream copy is built around blueprint/BLUEPRINT.lua and is the one a driver author reaches for, so the FTW copy is the one that quietly goes stale — and #720 is currently moving the website's "Write a driver" link upstream, which makes that worse. Split by what each repository actually owns. Authoring moves upstream, and this page keeps what only FTW can answer: what its host registers, how a capability is granted, when the host calls driver_default_mode, where FTW resolves a driver file from, and how to test one against a running instance. The host API is now a table generated from what lua.go registers, including http_patch and its allow_write gate from #716. Every name in it was checked against host.RawSetString in lua.go; the two Blixt L1 aliases stay in the prose below the table rather than the table itself. Removed content is covered elsewhere: entry points, sign convention, manifest and make targets upstream, and the drivers-beta promotion paragraph was already a duplicate of device-repository.md, which this page links to. README is untouched — #720 is editing the same section and has right of way. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
…uide FTW and srcfl/device-drivers both carried a "how to write a driver" guide, 220 and 268 lines. They overlap on the entry points, the DRIVER block, the sign convention and the build-and-test loop, and there is no mechanism that keeps them agreeing. The upstream copy is built around blueprint/BLUEPRINT.lua and is the one a driver author reaches for, so the FTW copy is the one that quietly goes stale — and #720 is currently moving the website's "Write a driver" link upstream, which makes that worse. Split by what each repository actually owns. Authoring moves upstream, and this page keeps what only FTW can answer: what its host registers, how a capability is granted, when the host calls driver_default_mode, where FTW resolves a driver file from, and how to test one against a running instance. The host API is now a table generated from what lua.go registers, including http_patch and its allow_write gate from #716. Every name in it was checked against host.RawSetString in lua.go; the two Blixt L1 aliases stay in the prose below the table rather than the table itself. Removed content is covered elsewhere: entry points, sign convention, manifest and make targets upstream, and the drivers-beta promotion paragraph was already a duplicate of device-repository.md, which this page links to. README is untouched — #720 is editing the same section and has right of way. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
The README tells a reader to send driver changes to
srcfl/device-drivers, but never says which devices are already covered. That repository now publishes a searchable catalog at https://srcfl.github.io/device-drivers/, generated from its manifests and driver sources on every push tomain.This links it from two places:
srcfl/device-drivers;The page shows all 80 drivers with their protocol, emitted DER types, control capability, tier and version, plus every tested model family — searchable by manufacturer or model number, so
SH10RTfindssungrow.It states hardware evidence rather than implying it: 5 drivers report being confirmed against physical hardware and 28 report in their own
verification_notesthat they have not been. Those are the same drivers and versions FTW installs from the signed channel.Note
The catalog is live. srcfl/device-drivers#51 merged and its Pages workflow has run — https://srcfl.github.io/device-drivers/ serves
200, so the link does not 404 and this is ready to merge.Counts verified against the published page
The three figures above were re-checked against the live catalog rather than restated from the source PR: 80 drivers, 5 with
hardware_verified: true, and 28 whoseverificationblock reportslevel: unverified/ "Not verified on hardware".The README itself deliberately states no numbers — only that the page distinguishes confirmed from unconfirmed — so it cannot go stale as drivers are added.
Why the changeset check failed earlier
Not a problem with this PR. The old
changeset-checkworkflow ranchangeset statusbefore deciding the docs allowlist, andchangeset statusreports "packages have been changed but no changesets were found" for any diff inside a package — a README-only diff included.#721 reordered the gate so the allowlist is decided first. That merged 19 minutes after this PR's last run, so the branch has been updated onto it.
Why no Changeset
Documentation only — no behaviour, API, config or UI change, so there is nothing for a release note to describe.
🤖 Generated with Claude Code