Commit graph

1 commit

Author SHA1 Message Date
ScreenTinker 5fe55307ba brightsign: declare capabilities from real hardware state
The dashboard offered every control to every display. This makes the
BrightSign player answer for itself, at runtime, rather than from a
per-platform table.

The table cannot work here: the same XT245 supports remote screenshots
with an SSD fitted and not without, because the DWS snapshot endpoint
writes the full-size capture to disk before returning a thumbnail and
answers "No primary storage found" on a flash-booted unit. So the bridge
asks the host.

- autorun.brs gains StorageProbe()/SendProbeResult(): walks SSD:, SD:,
  USB1: via roStorageHotplug.GetStorageStatus().mounted and reads real
  capacity through roStorageInfo. FLASH: is excluded deliberately — it is
  where the player boots from, not a volume the DWS accepts. Neither API
  has a JS equivalent, which is why this has to cross the bridge.

- st-bridge.js posts the probe during boot and folds the answer into the
  existing readiness gate, with its own 3s timeout so a widget built
  without nodejs_enabled still becomes ready. computeCapabilities() then
  gates remote.screenshot/remote.stream/system.self_update on a mounted
  volume, the lifecycle and display commands on a live host, sync.native
  on the module AND OS >= 8.2.10, and display.power on CEC module
  presence.

  Unknown is treated as NO throughout: an unanswered probe declares
  nothing storage-gated. A control that appears once a disk is fitted is
  a smaller problem than one that silently fails.

  Never declared: kiosk, brightness, screen_timeout, install_apk, shell
  (no BrightSign equivalent) and time (BrightScript can, this host does
  not implement it — the same lie in the other direction).

- Telemetry now reports the real drive from the probe instead of the
  widget's storage_quota, which it had been presenting as if it were the
  disk.

Two declarations are knowingly optimistic and documented as such:
transitions/pip composite DOM over a hardware plane and may be invisible
over video (the roVideoMode.SetGraphicsZOrder("front") fix wants a
hardware experiment, not a guess), and display.power rides module
presence on a unit whose kernel logs "failed to get cec clock". Neither
is load-bearing — transitions degrade to a hard cut, blanking works by
tearing the media down.

Tests cover the storage split, the hostless case, the sync floor, the
never-declared set, and that every declared string is in the server's
vocabulary — a typo there would silently disable a control fleet-wide.
2026-08-05 14:12:44 -05:00