Module feed 

The dashboard feed seam: the minimal contract the hardware device-dashboard renderer + the display-nudge loop need from the Home-dashboards capability, inverted so this kernel crate has ZERO compile-time dependency on ryu_dashboards.

Why this exists

A hardware device (TRMNL model) renders a Home dashboard onto its e-ink / LCD panel: the device polls Core, Core renders the device’s bound dashboard to a panel image. That render reads dashboard widgets + rasterizes them — a dashboards concern that had been welded into ryu_hardware::api as a direct ryu_dashboards::DashboardEngine field. Dashboards is now a swappable, out-of-process app; a kernel crate cannot hard-link it.

DashboardFeed is the inversion. It exposes ONLY what the renderer + nudge loop need (render a device’s dashboard, read/write its config + binding, subscribe to change events), in terms of plain owned types — never a ryu_dashboards type. Core provides the impl:

• in-process (InProcDashboardFeed) — wraps the in-process engine;
• out-of-process (dashboards_client::DashboardsClient) — proxies to the ryu-dashboards sidecar over loopback (+ its SSE stream for change events).

The device auth (per-device Bearer verification against the registry) stays Core-side; only the render + data cross this seam.

Structs

DeviceBinding

A device → dashboard binding (the nudge loop’s work list).

DeviceManifest

The display-manifest facts for a device: the content revision (so the device can skip an unchanged re-download), its poll interval, and its panel geometry.

RenderedImage

A rendered device image plus the metadata the display endpoint returns.

ScreenProfile

A device’s panel geometry echoed in the display manifest + config screen object. Computed by the feed impl from the device class + prefs (so the panel constants live with the renderer, not here), and carried back as plain data.

SetDeviceResult

The outcome of a device-dashboard write.

Traits

DashboardFeed

The dashboards capability, seen through the narrow hole the hardware surface needs. Implemented by Core (in-process or sidecar-backed).