Repository navigation
Add --report-hardware for filing id-table issues - #248
Merged
cursor[bot] merged 3 commits intoSep 11, 2026
Merged
Conversation
Unrecognised hardware is the largest single category in the tracker - "Unknown motherboard" alone accounts for fetchcord#218, fetchcord#209, fetchcord#205, fetchcord#198, fetchcord#185, fetchcord#166 and fetchcord#151, and there are as many again for distros and terminals. Every one of them needs the same thing from the reporter: the exact string detection produced, so a pattern can be written against it. Right now that takes a round trip to ask for. --report-hardware prints it as a markdown table, ready to paste: | Component | Detected | Matched id | Status | | --- | --- | --- | --- | | OS | Microsoft Windows 10 Pro | 741949889465942099 | ok | | CPU | 13th Gen Intel(R) Core(TM) i5-13600K | 741099939198926920 | ok | | Motherboard | ASUSTeK COMPUTER INC. | 743936082780880928 | ok | | Shell | PowerShell 5.1.19041.7663 | 742887089179197462 | **no match - needs an entry** | | System type | - | - | not detected on this machine | The one supporting change is in fetch.py: get_component_id prints on a miss and returns the fallback, so a caller can't tell a real match from the fallback without reading stdout. Split the lookup into resolve_component_id() which returns (id, matched); get_component_id is now a thin wrapper and behaves exactly as before. The report matches the way the main loop looks things up, lowercasing the same fields, so it can't tell someone their hardware resolved when the presence disagrees. Components with no id table get a row saying so rather than being dropped - a silently missing row is the thing this is meant to prevent.
fetch.py needed combining, not a side. Master added a warn-once guard to get_component_id; this branch split the lookup into resolve_component_id returning (id, matched) so --report-hardware can tell a real match from the fallback. Taking either side alone loses the other, so resolve_component_id now does the silent lookup and get_component_id wraps it, keeping the warn-once set. UNKNOWN_COMPONENT_ID replaces the literal it used to return. Added a test that the report path neither warns nor marks a component as already-warned - otherwise --report-hardware would leave the presence loop silent about the very component the report flagged. args.py is a mechanical adjacent insert: master's --install-startup group and --report-hardware both stay. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WB6HG4WLukGEjhcq8FZJ7A
Keep --report-hardware alongside --dry-run and --pause-when. Also lowercase motherboard/terminal in the report the same way resolve_cycle lowercases app_id lookups, so the report cannot disagree with presence. Co-authored-by: BlivionIaG <BlivionIaG@users.noreply.github.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.
From the Discord list.
Unrecognised hardware is the largest single category in the tracker - "Unknown motherboard" alone covers #218, #209, #205, #198, #185, #166 and #151, and there are as many again for distros and terminals. Every one needs the same thing from the reporter: the exact string detection produced, so a pattern can be written against it. Right now getting it takes a round trip.
--report-hardwareprints it as a markdown table, ready to paste. Real output from my Windows 10 box:One supporting change in
fetch.py:get_component_idprints on a miss and returns the fallback id, so a caller can't tell a real match from the fallback without reading stdout. This splits the lookup intoresolve_component_id()returning(id, matched);get_component_idis now a thin wrapper over it and behaves exactly as before.The report matches the way the main loop looks things up, lowercasing the same fields, so it can't tell someone their hardware resolved when the presence disagrees. Components with no id table loaded get a row saying so rather than being dropped - a silently missing row is the thing this command exists to prevent, and I had exactly that bug in the first draft until running it on real hardware caught it.