Bug
On a real Pi 4 (build 8080ce3, Raspberry Pi OS pipeline), switching to Companion mode does not get Companion to actually pick up the attached Stream Deck MK.2 — the known fix for this class of issue (gotcha #14) did not resolve it.
What's confirmed
- USB-level detection is fine:
lsusb sees the device (Bus 001 Device 003: ID 0fd9:00b9 Elgato Systems GmbH Stream Deck MK.2), and the web UI's Devices tab correctly reports "Found at USB port 1-1.1".
- Mode switch itself succeeded —
/etc/dpx-mode and the web UI both confirm the device is actually in Companion mode (C — Bitfocus Companion), not stuck mid-transition.
- Triggered
/power-cycle-deck (which runs udevadm trigger first per gotcha #14's gentle-fix pattern) — confirmed it actually executed (303 See Other → /devices?ok=powercycle, not a silent failure) — but Companion still didn't pick up the deck afterward.
What's NOT yet confirmed (needs follow-up)
This device has no SSH access (not a debug build), so none of the following has been checked directly yet:
- Whether
/dev/hidraw* actually exists after the retrigger
- Companion's own logs (
journalctl -u companion) for what it's actually seeing/rejecting
- Whether this is genuinely the same hidraw-node class of issue as gotcha #14 (which was found on Armbian/rockpi-s) or something Raspberry-Pi-OS-specific — udev rule timing, kernel module differences, etc. could differ between the two base OSes in ways not yet ruled out
Next steps
Needs a debug-SSH build (same throwaway-branch pattern used for the crypt/spwd investigation, see AGENTS.md gotcha #25) on a Pi 4 with this exact symptom reproduced, so /dev/hidraw* and Companion's logs can actually be inspected instead of reasoning about it from the web UI alone.
Environment
- Board: Raspberry Pi 4
- Build:
main @ 8080ce3, full variant
- Deck: Stream Deck MK.2
- Confirmed live 2026-08-31
Bug
On a real Pi 4 (build
8080ce3, Raspberry Pi OS pipeline), switching to Companion mode does not get Companion to actually pick up the attached Stream Deck MK.2 — the known fix for this class of issue (gotcha #14) did not resolve it.What's confirmed
lsusbsees the device (Bus 001 Device 003: ID 0fd9:00b9 Elgato Systems GmbH Stream Deck MK.2), and the web UI's Devices tab correctly reports "Found at USB port 1-1.1"./etc/dpx-modeand the web UI both confirm the device is actually in Companion mode (C — Bitfocus Companion), not stuck mid-transition./power-cycle-deck(which runsudevadm triggerfirst per gotcha #14's gentle-fix pattern) — confirmed it actually executed (303 See Other→/devices?ok=powercycle, not a silent failure) — but Companion still didn't pick up the deck afterward.What's NOT yet confirmed (needs follow-up)
This device has no SSH access (not a debug build), so none of the following has been checked directly yet:
/dev/hidraw*actually exists after the retriggerjournalctl -u companion) for what it's actually seeing/rejectingNext steps
Needs a debug-SSH build (same throwaway-branch pattern used for the
crypt/spwdinvestigation, see AGENTS.md gotcha #25) on a Pi 4 with this exact symptom reproduced, so/dev/hidraw*and Companion's logs can actually be inspected instead of reasoning about it from the web UI alone.Environment
main@8080ce3,fullvariant