defcom5-rockchip

RELEASED

Pi-Desktop 4.0 "Plaid" — a GNOME desktop image for the Orange Pi 5B, built on Armbian.

 
Pi-Desktop 4.0 is out. It is an Orange Pi 5B desktop image built with the Armbian build framework on Armbian's Rockchip vendor kernel 6.1.172, with eleven patches of my own applied through userpatches. Armbian owns the boot chain, U-Boot, partitions, kernel branch, device trees, firmware, board support and the first-boot resize, and everything I add is a userspace layer applied through the late image hook. Posting it here because several of the fixes are Armbian-wide and may save someone a day.
 
Fixed, with the cause if you want it:
WPA3 and WPA2/WPA3 networks were refused on the vendor Wi-Fi driver with wpa_supplicant 2.11 (deauth reason 13). The driver handles only the older WPA version signal; 2.11 signals WPA3 a new way, so the driver fell through to "no WPA" and the firmware attempted an open association carrying a WPA3 security tag. Ten lines, sent upstream as armbian/linux-rockchip#561. The same gap is in bcmdhd-dkms for mainline-kernel images.
 
Every GUI password prompt hung on Ubuntu 26.04 with any 6.1 kernel. polkit 127 runs its helper through a socket that needs a kernel feature from 6.5. Mask the socket, make the classic helper setuid, done. Affects Debian sid and forky too, not trixie.
Bluetooth audio stuttered whenever Wi-Fi was busy. The AP6275P shares one antenna path between the two radios, and the vendor NVRAM leaves the coexistence timing at its defaults. Three values in /lib/firmware/ap6275p/nvram_AP6275P.txt give Bluetooth long enough slots to keep an A2DP stream intact: btc_params8=0x4e20, btc_params1=0x7530, btc_params50=0x972c. The file is diverted so an armbian-firmware upgrade cannot quietly drop them. Note the driver here is bcmdhd, so the file that matters is the ap6275p NVRAM, not brcm/brcmfmac43752-pcie.txt, which never gets loaded.
4K at 120 Hz, three separate faults: black screens after minutes to hours, a hard hang on screen-off and wake, and a black screen after a monitor power-cycle.
A big file copy could kill the whole desktop session, through the system's out-of-memory handling and a misplaced cgroup.
Bluetooth speakers muted for ten seconds at every YouTube ad.
The 3.5 mm jack was silent: the vendor codec driver keeps its headphone switch off by default.
Added: a screensaver service instead of screen blanking, first-click installers for seven apps with pinned keys, a computer-name prompt at first login, Open in Terminator in Files, Log Out back in the power menu, Rhythmbox 3.5.1, Brasero, and mpv profiles that stop DVDs stuttering at 120 Hz.
Everything is published: the full recipe as an Armbian userpatches layer you can drop into your own build tree, the kernel source as a tag with the eleven patches applied, the complete corresponding-source table, and a known-issues file that says what is still rough. Images, notes and the recipe: https://defcom5-rockchip.github.io/pi-desktop/
An LLM assistant (Claude) worked on this with me throughout, including the driver analysis behind the fixes above; the hardware testing (and Pissed off Wifi Slop) is mine.

I asked Claude to rate the severity of the WPA3 bug.
Medium. Here's the reasoning across the two axes that matter.
As a security issue: low. It fails closed. The board can't join, the router is untouched, nothing leaks. We traced that through the driver, the kernel, the login software and the network manager. It isn't CVE-grade and claiming otherwise would cost credibility.
As a defect: high. On an affected system the board cannot join a modern home network at all. Wi-Fi is not a feature you can route around, the symptom looks like a wrong password, and nothing in the logs points at the driver. Every user on that combination is blocked.
Net: medium, trending up.

 
For the Jellyfin people. The video driver on this image is my own: rockchip-vaapi 2.2.0, built on Rockchip's MPP, published at defcom5-rockchip/rockchip-vaapi. I measured it on the release image rather than trusting what browsers claim about themselves, with a 4K HEVC Main 10 file played full-screen for 20 seconds.
Chromium, which ships in the image, decoded it on the video engine: 595 frames, zero dropped, about 10% of the CPU. The board stays cool and idle-quiet doing 4K 10-bit. That means Jellyfin's web client direct-plays 4K Main 10 here, no server transcode, and you do not have to install anything first. Chrome is the same engine with the same flags once you install it. 8-bit HEVC, H.264 and VP9 ride the same path.
Two honest caveats, because they will bite you otherwise:
Firefox is the wrong browser for video on this image. Same file, same machine: 26 dropped frames and 350% CPU across its processes. Its own decoder log says IsHardwareAccelerated=false, and no Firefox process loads libva at all, so it never even attempts the hardware path. Not Armbian's build, not the sandbox, not dmabuf detection, all tested and ruled out. Firefox hardware decode is the headline feature I am aiming at for the next release.
HDR files play but look pale in either browser, because neither does HDR tone mapping on Linux. mpv is the right player for those, and it goes through the same driver.
AV1 is software everywhere; this chip's AV1 block has no browser path yet.
If you run Jellyfin on an Orange Pi 5B, the short version is: use Chromium or Chrome, point it at your server, and your 10-bit library direct-plays on a board that costs less than the transcode licence you were about to avoid.

(We had firefox playing 10 bit but not 8 bit) due to my unhinged wifi rant and the Firefox licensing it got yanked.) see you on Plaid 4.5


"Union Of Plaid Penguins For A Slop Free Environment"
 
defcom5-rockchip