TV Media box systemd target

[zhovner]

We need to test tupical TV media box scenarios and prepare target for this

Systemd target name: tv-media-box.target

• Autorun Kodi at boot
• Both video out active: HDMI + USB DP
• HDMI CEC input should forwards to Kodi
• Default sound output should switch to HDMI when connected

Kodi plugins

• Browser (Chrome?) — we need any basic browser for Wi-Fi captive portal auth

Flipper Buttons Input forwarding

We need some solution that temporary switch input from FlipCTL's seat1 to seat0 to control Kodi from D-pad.

[alchark]

@zhovner Regarding input: we discussed internally that to make it reliable we'll need to avoid switching the hardware input away from FlipCTL, but rather make FlipCTL generate UInput events that will feed into the rest of the system. Then it can also send hardware keypresses from the on-screen keyboard or soft buttons.

[zhovner]

Lets merge current branch? @Yury-MonZon

[Yury-MonZon]

Let's go #75

[zhovner]

HDMI audio missing on some TV's

• Board: one-rev-f0b0c1 · Build: build-1253-tv-media-box-target · Kernel: 7.1.0-rc6
• Stack: PipeWire + WirePlumber 1.4.2 · cage 0.2.0 / wlroots 0.18 · Kodi 21.2 · TV: LG (4K)

Two independent bugs.

Bug 1 — HDMI not in Kodi's audio output list

Cause: the HDMI card is a bare I2S/SAI PCM (27d50000.sai-i2s-hifi, hw:2,0) with no mixer path and no hdmi: alias, so PipeWire ACP only builds off/pro-audio (no output:hdmi-stereo). WirePlumber leaves it off → no sink → nothing to list. (DisplayPort works only via ACP's IEC958 fallback.)

Diagnose:

wpctl status                                 # HDMI device present, no HDMI sink
pw-dump <hdmi-device-id>                      # EnumProfile = off + pro-audio only
aplay -D hw:2,0 --dump-hw-params /dev/zero     # CHANNELS: 2 only

Fix — /etc/wireplumber/wireplumber.conf.d/60-hdmi-acp-off.conf (disable ACP so a PCM sink is created; pin stereo because the SAI advertises a huge TDM count, so the raw node otherwise comes up 64ch and can't open the 2ch PCM):

monitor.alsa.rules = [
  { matches = [ { api.alsa.card.longname = "HDMI", media.class = "Audio/Device" } ]
    actions = { update-props = { api.alsa.use-acp = false } } }
  { matches = [ { node.name = "alsa_output.platform-hdmi-sound.playback.0.0" } ]
    actions = { update-props = { audio.channels = 2, audio.position = [ FL, FR ] } } }
]

systemctl --user restart wireplumber → an "HDMI Audio" sink appears.

Bug 2 — sink works, PCM runs, but TV is silent

Cause: cage auto-selects the largest advertised mode = 4096x2160@30 (DCI-4K; the link is capped at 297 MHz, so there is no 4K@60 / HDMI-2.1 FRL). The LG displays this mode but mutes its HDMI audio on it.

• Tone at 4096x2160@30 → silent; forced 1920x1080@60 → audible.
• MacBook → same TV (3840x2160@60) and FlipperOne → a different TV both work.
• (hdmi-audio-codec ... Unknown ELD version 0 in dmesg is codec .14 = DP path, not the HDMI card .15 — red herring.)

Does NOT work: cage has no resolution flag and ignores the kernel video= cmdline (it creates a USERDEF mode, not preferred, so wlroots still picks the biggest). Also do not use a kodi.service ExecStartPost hook — it inherits PAMName=login, opens a 2nd logind session that races cage's XDG_RUNTIME_DIR and crashes cage on cold boot (a warm systemctl restart won't reproduce it).

Works: cage supports wlroots output-management, so force the mode with wlr-randr from a separate service.

apt install wlr-randr

/home/user/.kodi/hdmi-force-mode.sh (chmod +x):

#!/bin/sh
CONNECTOR="HDMI-A-1"; MODE="1920x1080@60"
export XDG_RUNTIME_DIR="/run/user/$(id -u)"
for s in "$XDG_RUNTIME_DIR"/wayland-*; do
    case "$s" in *.lock) continue ;; esac
    [ -S "$s" ] && WAYLAND_DISPLAY="${s##*/}" && break
done
export WAYLAND_DISPLAY="${WAYLAND_DISPLAY:-wayland-0}"
i=0; while [ "$i" -lt 100 ]; do /usr/bin/wlr-randr >/dev/null 2>&1 && break; i=$((i+1)); sleep 0.2; done
/usr/bin/wlr-randr --output "$CONNECTOR" --mode "$MODE" || true
exit 0

/etc/systemd/system/hdmi-force-mode.service (then systemctl enable hdmi-force-mode.service):

[Unit]
Description=Force HDMI to 1080p60 (TV mutes audio on cage's default 4K/30 DCI mode)
After=kodi.service

[Service]
Type=oneshot
User=user
Group=user
Environment=XDG_RUNTIME_DIR=/run/user/1000
ExecStart=/home/user/.kodi/hdmi-force-mode.sh

[Install]
WantedBy=kodi.service

Separate unit + weak Wants coupling + no PAMName → cannot affect cage's boot. Verified across a cold reboot: Kodi starts clean, mode → 1080p60, audio works.

Build/image changes

• Ship 60-hdmi-acp-off.conf in overlays/configs/wireplumber/wireplumber.conf.d/.
• Add wlr-randr to debian-rk3576-ospack.yaml.
• Ship hdmi-force-mode.sh + hdmi-force-mode.service (enabled) alongside kodi-display-gate / kodi.service.

Notes

• Pins output to 1080p60 (4K content downscales); mode is hardcoded in the hook.
• Proper long-term fix: enable 4K@60 (594 MHz TMDS / HDMI-2.1 FRL) on the RK3576 HDMI PHY — keeps native 4K and the TV un-mutes audio. The 297 MHz cap is the real limitation.

[VoidChecksum]

The dtbo from the [TV MEDIA BOX] boot entry gets us a /dev/cec0 (DRM_DW_HDMI_QP_CEC=y is already in configs/minconfig-mainline), but nothing consumes it yet. Two ways to get TV-remote keys into Kodi; I'd test both, they fail differently across TVs.

Option A — Kodi's built-in libCEC. Debian builds libcec with the kernel CEC API since 6.0.2-3 (changelog), and trixie's kodi links it. /dev/cec* is root:video 0660 by systemd's 50-udev-default.rules and user is already in video, so this needs zero new units — Kodi should detect the adapter on its own once the dtbo is loaded. Gives one-touch-play, TV volume control, standby integration for free. Two caveats:

• Kodi defaults to "send standby on exit". Combined with handoff.conf's ExecStop=kodi-send --action=Quit, isolating to KDE would turn the TV off. Ship peripheral_data defaults with "make inactive source" instead.
• libCEC takes the adapter as exclusive follower — don't also run a cec-ctl config unit alongside it.

Option B — kernel RC passthrough. Session-agnostic: works for the chromium kiosk and any future non-Kodi session, and shares the evdev input path with the FlipCTL uinput forwarding @alchark described. The CEC core registers an rc-core input device that translates remote keys via the rc-cec keymap (KEY_UP/KEY_OK/KEY_BACK…), cage feeds it to Kodi like any seat0 keyboard (docs). Needs a config delta — both currently absent from minconfig-mainline:

CONFIG_RC_CORE=y
CONFIG_MEDIA_CEC_RC=y

The adapter still needs a logical address claimed once. Tying it to the device means it only ever starts when the dtbo is loaded, no target coupling needed (cec-utils is already in the ospack):

# overlays/configs/udev/rules.d/71-cec.rules
SUBSYSTEM=="cec", KERNEL=="cec0", TAG+="systemd", ENV{SYSTEMD_WANTS}+="cec-setup.service"

# overlays/configs/systemd/system/cec-setup.service
[Unit]
Description=Claim CEC logical address (playback device)
ConditionPathExists=/dev/cec0

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/cec-ctl -d /dev/cec0 --playback --osd-name Flipper
# optional one-touch-play on boot:
ExecStart=-/usr/bin/cec-ctl -d /dev/cec0 --image-view-on --to 0

(Auto-switching the TV input additionally wants an Active Source broadcast with the physical address read back from cec-ctl -s; 3-line wrapper script if we want it.) Downside vs A: no standby/volume integration unless scripted, and a couple of rc-cec keys (KEY_OK, KEY_EXIT) may need a small Kodi keymap entry.

My take: try A first since it's free, but land the two kernel options regardless — they cost nothing and B is the only path that works outside Kodi. The CEC quirk zoo across LG/Samsung/Sony makes hardware testing the real gate either way.

Audio default-switch: the OP's "default sound to HDMI when connected" should fall out of @zhovner's 60-hdmi-acp-off.conf with one more property — WirePlumber picks the highest priority.session among present sinks, so:

{ matches = [ { node.name = "alsa_output.platform-hdmi-sound.playback.0.0" } ]
  actions = { update-props = { priority.session = 1500 } } }

HDMI wins while connected, falls back to DP/speakers on unplug. (Only applies when the user hasn't manually pinned a default — WirePlumber persists explicit choices.)

Constraint worth stating in the target's docs: until FFmpeg's v4l2-request path lands (kernel-side VDPU383 H.264/HEVC is already in flipper-devel, see #13), Kodi is software-decode only, so ~1080p is the realistic playback ceiling — the 1080p60 pin from the audio workaround costs nothing today. 4K@60 is gated on the 594 MHz TMDS/FRL PHY work @zhovner mentioned; 4K@120 is HDMI 2.1 FRL territory, out of scope until that exists.