HydraIssues

Kiosk always fullscreens on macOS Main Display, no way to target the venue display when a second monitor is connected
open feature Project: hydra-experiencenet Reporter: agentcodex 23 Jul 2026 12:36

Description

Observed on turbo-pancake-76 (node-adf19775, Cloud Seven production head): the Mac Mini has two displays connected — a DELL P2723QE (3840x2160, looks like an admin/setup monitor) and a RAP-1580MKII (4096x2160, the venue signage panel that visitors actually see). macOS currently has the DELL marked as Main Display, so the kiosk app was fullscreening on the wrong (admin-facing) screen instead of the venue panel.

Root cause: neither hydraheadflatscreen nor the Qt client (hydra-experiencenet) has any concept of which physical display to target. `KioskView.qml` StackView.onActivated just calls `window.showFullScreen()` with no screen argument (gui/KioskView.qml), and `gui/main.qml` does the same on startup (line ~52/58). Qt places a new top-level window on whichever screen is default (effectively macOS's current Main Display), so the kiosk always follows Main Display rather than a configured target. Confirmed via source read: no `--display`/`--monitor` CLI flag, no `screen:` property set anywhere, no config.yaml key for this in hydraheadflatscreen.

This is fragile any time a second display is plugged into a kiosk Mac Mini (debugging, on-site setup, an admin monitor left connected) — whichever one macOS currently considers Main wins, silently, with no error or log signal that the kiosk rendered on the wrong screen.

Ask: make the target display configurable end-to-end rather than depending on macOS display arrangement:
- Add a display-selection config key (e.g. `display_name` or `display_index`) to hydraheadflatscreen's config.yaml, settable via the admin API/dashboard per head.
- Plumb it through to the Qt app at kiosk launch (extra CLI arg, e.g. `kiosk --district <d> --venue <v> --display <name-or-index>`), and have `main.qml`/`KioskView.qml` resolve the matching `Qt.application.screens` entry and call `window.setScreen()` (or move the window to that screen's geometry) before `showFullScreen()`.
- Fall back to current behavior (default/Main Display) when unset, so single-display kiosks are unaffected.
- Consider surfacing the detected display list (name + resolution) in the Diagnostics panel (`GET /api/v1/diagnostics`) so a stray second display shows up as a visible warning instead of silently stealing the kiosk window.

No change made on turbo-pancake-76 itself — left as-is at the reporter's request, pending this proper fix rather than a manual arrangement workaround.