You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The initial LinuxProvider (branch feat/linux-provider) reads hardware sensors dependency-free from /proc and /sys and emits the canonical sensor IDs the default instrument panel binds to:
This is deliberately minimal and portable (no external binaries required). It proves the Providers → Store → Binding → Widgets → Renderer pipeline with real data.
Goal
Build a richer, more feature-complete demo/provider that uses vendor tooling where available, both to surface deeper metrics and to serve as worked examples for users writing their own providers/panels.
Possible scope
GPU (vendor tools):
AMD via amd-smi (or rocm-smi): VRAM used/total, GPU + memory clocks, power draw (W), fan RPM, per-engine activity.
CPU/system (lm-sensors): richer thermal/voltage/fan coverage via sensors/libsensors beyond the raw hwmon scan.
Graceful capability detection: detect which tools/sensors are present at runtime; degrade cleanly (provider health Degraded with a message) when a tool is missing — never hard-fail.
Example panels that showcase the richer sensors (VRAM gauge, power readout, fan tiles), demonstrating multi-sensor/customized panels.
Docs: a "writing a provider" example walkthrough using one of these integrations (ties into docs/development/provider-guidelines.md).
Non-goals (for this issue)
Replacing the dependency-free sysfs LinuxProvider — vendor-tool integration should be additive/optional, gated on tool availability.
Windows/macOS provider work (track separately).
Acceptance (rough)
A richer provider (or an extension to LinuxProvider) exposes additional GPU/CPU sensors when amd-smi/nvidia-smi/lm-sensors are present, with clean fallback when they aren't.
At least one example panel + a short provider-authoring doc demonstrating it.
Filed as a follow-up to the sysfs-first Linux sensor work.
Re-scoped: this sits under the provider-system epic #8 as an example / content item — a richer demonstration provider using vendor tools (amd-smi/nvidia-smi/lm-sensors), not additional hardcoded core providers. It should build on whatever loader model #8 lands on (and per #8, native-SDK/vendor-tool integrations are host-side, not inside a WASM sandbox).
Activity
rghamilton3 commentedon Jun 1, 2026
Re-scoped: this sits under the provider-system epic #8 as an example / content item — a richer demonstration provider using vendor tools (
amd-smi/nvidia-smi/lm-sensors), not additional hardcoded core providers. It should build on whatever loader model #8 lands on (and per #8, native-SDK/vendor-tool integrations are host-side, not inside a WASM sandbox).