2 commits

Author	SHA1	Message	Date
ScreenTinker	c1270599c3	Make the parity matrix true, and stop three controls that do nothing ... The parity doc and the capability model had drifted from the players in both directions, and nothing failed when they did. Auditing all four players against their shipped sources turned up three controls a customer can press today that change nothing, and a set of baselines that were partly too generous and partly too stingy. The three dead controls: - The volume slider works on Android only. The dashboard sends set_volume as { level: 0..1 }; the web player reads payload.value and Tizen reads payload.value ?? payload.volume, so on both the number is undefined and the handler quietly declines. Three complete, working volume implementations that cannot be driven. The fix is one line in each player and belongs to those files; audio.volume is out of the web and brightsign baselines until it lands, held there by a biconditional test that fails the moment a player starts reading `level`. - Every #161 Tier-2 command was refused for the entire fleet. lock_now, power_menu, status_bar, block_uninstall and unblock_uninstall were gated on system.device_owner, which no player declares and no baseline grants, so supports() was false everywhere -- including on the device-owner panels the feature was built for. The dashboard still drew the buttons because it also gates on device.tier === 2. Fixed here: those five now accept system.device_owner OR system.kiosk, which PlayerCapabilities.kt declares under `if (isOwner)` and nothing else, and which no non-Android player declares. Android should declare system.device_owner and retire the stand-in. - enable_system_capture required the capability it creates. It raises the MediaProjection consent dialog -- the way a panel GAINS capture -- and was gated on remote.screenshot, so the only panel that needs it was the one panel that could not be sent it. Now ungated. The dashboard still hides the button behind the same check; that half is a frontend change. The baselines describe what an un-updated fielded display can do, and since v1.9.29 is the first build in which any player declares anything, that means v1.9.28. Every entry is now justified against `git show v1.9.28:<source>`: - android loses display.power (v1.9.28 answers screen_on with a logged no-op, so the ON half is dead on every fielded panel and one capability renders both buttons) and system.reboot (owner-only; off-owner it paints an accessibility power dialog over the signage). Scheduled reboots now skip undeclared Android panels rather than logging a reboot that never happened, which is the reason that gate exists. - tizen gains display.power: v1.9.28 implements both halves with no signing and no panel API, so withholding it hid a working control. - brightsign loses audio.volume, display.power, system.reboot, system.restart_player and offline.cache. All need a host bridge the unit is not known to have, and restart_player without one is the page reload that darkened a panel on 2026-07-28. Also found, not fixed here because the files belong to others: st-bridge.js computeCapabilities() is dead code -- nothing calls BS.capabilities() -- and its 199 lines of passing tests constrain nothing a BrightSign actually declares; the two disagree on six capabilities and the bridge is right about most of them. BrightSign's "Force update" button is dead. PlayerCapabilities.kt under-declares display.brightness. The new test reads the player sources rather than the table: a dead-button rule (every gated command has a branch somewhere), an unreachable-capability rule (which would have caught system.device_owner), and biconditionals so a fix in a player fails the test until the baseline follows. Claims that need hardware -- CEC reaching a display, a widget being allowed a service worker, SyncManager holding frame lock -- are marked unverifiable in the document instead of asserted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL	2026-08-06 10:24:10 -05:00
ScreenTinker	0082191f9b	Show only the controls a display can actually honour ... Every device control was offered to every display. A browser tab was shown "Reboot device", a Tizen TV was shown screen power, a player with no framebuffer read was shown a live view that stayed black. They all looked like working buttons and did nothing — the "reports success and changes nothing" shape that keeps costing people days. Players now declare what they can do at registration, because only the player knows at runtime: an Android panel gains real screenshots when accessibility is switched on and loses Tier-2 when device owner is revoked. The dashboard hides what is not supported rather than disabling it, and the Info tab lists the capability set so a missing control is explainable. The declaration is three-state and the middle state is load bearing: NULL means "has never told us anything" and falls back to a per-platform baseline, because several hundred displays in the field will not update before this deploys and blanking their controls would be a far worse bug. An empty array means "I genuinely can do nothing" and is honoured. Hiding a button is not enforcement, so unsupported commands are also refused server-side — the socket is reachable directly and a stale tab still renders the old controls. Group sends report skipped devices separately from sent ones; counting an unreachable member as "sent" is how an operator walks away believing the whole group rebooted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL	2026-08-05 14:24:52 -05:00