Optional lookup of existing device work before starting a capture

[smichea]

Hi Emir,

I came across usb-rea through Glama. Your use of existing liquidctl/rivalcfg protocol knowledge to validate the generated output is particularly relevant to a project I maintain.

I created OpenDeviceDB following the release of REA, to help people find existing device-protocol, driver and firmware work. Its MCP server provides read-only lookup_device / search_devices by vendor/model or USB VID:PID and links results back to upstream sources. An unknown device remains explicitly unknown; a matching USB ID alone does not establish exact-unit compatibility.

Would an optional lookup before a capture be useful in usb-rea? The first step could simply show existing projects and their evidence/limitations. It would use the identity supplied by the user; capture files stay in the local analysis workflow. Sharing new findings could remain a separate user-reviewed contribution.

I can prepare a small example if this fits your plans. The server is already published as @opendevicedb/mcp, and its documentation describes the public read-only backend and the separate local-checkout contribution workflow.

Thanks for sharing usb-rea. Written with AI assistance.

[emirmrkaljevic]

Thanks for writing, and for pointing me at OpenDeviceDB. Looking up existing protocol/driver work by VID:PID before someone starts a capture is a good fit for usb-rea, especially as an optional step that stays read-only and keeps the capture local.

I would be happy to look at a small example when you have one. A first cut that only shows matching projects with their evidence and limits (and leaves anything unknown as unknown) sounds right. Sharing new findings as a separate, user-reviewed contribution also matches how I want this to stay.

I will keep the link to @opendevicedb/mcp and the docs you shared.

[emirmrkaljevic]

@smichea a first cut of this is now in main (3bc5f84, not released yet):

usb-rea lookup 1e71:170e
usb-rea lookup capture.pcapng --online

It is offline by default: a small table of devices whose protocol liquidctl, rivalcfg, turing-smart-screen-python or linux-thermalright-lcd-control already implement, with links and known limits (for example a shared WCH serial ID), plus names from the local usb.ids. --online also asks the OpenDeviceDB static API (/api/index.json and the device record), sends only the VID:PID, and falls back to the offline answer if there is no network. Unknown IDs stay unknown, and the output says a matching ID is a hint, not proof. The same thing is the lookup_device MCP tool.

If you'd rather I point it at a different endpoint, or show more of the record (status, install routes), let me know.

[smichea]

Thanks Emir, that was quick! I read 3bc5f84: offline by default, only the VID:PID sent, and "a match is a hint, not proof". That's exactly the spirit I had in mind.

The endpoints you use are the right ones: /api/index.json to find candidates by identifiers.usb, then /api/devices/<id>.json for the record. Two small notes:

• index.json is about 8.7 MB (about 0.8 MB gzipped) and is served with an ETag and a 10-minute max-age. If usb-rea caches it locally and revalidates, repeated lookups stay cheap for you and for us.
• Several records can share one VID:PID (reused vendor chips, bootloaders), so it's best to show every match rather than the first.

If you want to show more of the record, status, summary and projects (the upstream links) are the most useful fields, then install when someone wants to go further. I'd keep the wording neutral: status describes what is documented for that model, not something tested on the user's unit.

I'm happy to add usb-rea to our docs as a client of the static API once it's released, if you're OK with that.

Written with AI assistance.