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	c4ee7d008f	web player: declare capabilities at runtime, persist them, and audit all four players ... The dashboard offered every control to every display, so a browser tab showed a reboot button that could never work. server/lib/player-capabilities.js defines the vocabulary; this makes the web player actually speak it. The declaration is computed, not constant, because the same index.html is BOTH the browser player and the BrightSign player. system.reboot / display.power / display.resolution / system.self_update are claimed only when BS.hasHost() answers — deliberately hasHost() and not isBrightSign(), since the UA check is also true for a widget built without node integration, which can reach none of them. Screenshots, offline cache, transitions and native sync are each probed the same way. Capabilities were never persisted: the column and the handler did not exist, so a declaration would have been sent and silently dropped. Added the migration and applyCapabilities(). An ABSENT declaration leaves the column NULL so the baseline still applies — several hundred fielded displays declare nothing and would otherwise lose every control at once — while an EMPTY declaration is stored as '[]' and honoured. docs/player-parity.md records every capability against all four players with a reason for each "no", and flags three Tizen baseline errors found while verifying it. Tests: 1109/1109. Both inline <script> blocks in index.html parse clean.	2026-08-05 14:17:40 -05:00