Skip to content

Pi Desktop v1.0 — "Vanilla Sky"

Choose a tag to compare

View all tags
@defcom5-rockchip defcom5-rockchip released this 01 Aug 21:49
· 16 commits to main since this release
v1.0
0003929

Pi Desktop v1.0 — "Vanilla Sky"

The first stable release, and it lands with the thing that has been the hardest unsolved problem on this board: Chromium hardware-decodes 4K video. YouTube at 2160p60 now runs on the RK3588's video engine instead of brute-forcing it on the CPU — smooth and cool where it used to be choppy and hot.

Supersedes v1.0-beta.

What's new

🎬 Hardware-accelerated 4K browser video

A current Chromium (132), hardware-decoding 4K60 VP9, on the Panfrost graphics stack.

Measured on a pristine image, cold-booted:

software (before) hardware (this release)
CPU on 4K60 VP9 600–731% 117–119%
/dev/mpp_service never opened held by chromium
rkvdec0_core idle clocked 594 MHz
chrome://gpu Software only Video Decode: Hardware accelerated

🔌 USB boot fix

The board no longer hangs at boot with a bus-powered USB audio interface attached. U-Boot probed the USB bus before storage on every boot; a class-compliant interface drawing more than U-Boot's 500 mA budget could stall enumeration and the board would never reach the kernel. Boot targets are now ordered storage-first. Verified across two cold boots with an RME Babyface Pro attached — and as a bonus, it comes up class-compliant as the default PipeWire sink and source.

Why this was hard

Getting a current Chromium to hardware-decode on the RK3588 has been a genuinely unsolved problem across the ecosystem. Distributions either ship a two-year-old Chromium — from before the browser dropped its old decode path — or fall back to software. Chromium's own upstream tracker still lists the clean path as broken on this hardware, and mainline Linux only recently gained the RK3588 H.264/HEVC decoders, not VP9/AV1, and not wired into a browser. "Browser hardware video" on this SoC has mostly meant wait for mainline or run an old browser.

We took the other road. Building on the rkmpp and Rockchip media work — JeffyCN's rkmpp/libv4l work and the jjriek packages, we stand on their shoulders — we tracked down why a clean Chromium 132 silently falls back to software, and bottled the fix into the image.

The cause turned out to be a packaging accident, not a hardware limit: upstream Mesa 25.x split its gallium drivers into a new binary package that the panfork Mesa build doesn't publish. Nothing could shadow a package that doesn't exist, so a routine apt upgrade quietly replaced the panfork graphics stack with stock Mesa — and that chimera is what broke decode. The image now pins the panfork stack, and a hard build gate fails the bake if the wrong Mesa ever ships again.

It decodes on Panfrost — the mainline-lineage, crash-safe path — not the vendor Mali blob. That distinction matters: it means hardware video costs you no stability tradeoff.

How it was verified

Pristine image, flashed clean, checksum verified, cold-booted — not a tuned bench machine. Decode confirmed in chrome://gpu with mpp_service held and rkvdec clocked. USB boot fix confirmed on two separate cold boots. We reversed our own conclusions twice during this investigation before the third one held, so this release was proven from a clean flash rather than from a machine we'd been poking at.

Known issues

  • First boot is busy for 2–3 minutes. tracker-miner-fs-3, packagekitd and unattended-upgrades all index at once and video playback can stutter while they do. Decode holds through it. Give it a few minutes to settle. Throttling this is queued for v1.0.1.
  • Window-resize flicker in Chromium 132 on some ultrawide setups. Fullscreen (F11) is always clean, Vivaldi is unaffected, and Chromium 114 remains available.
  • Two benign systemd units fail at boot — casper-md5check.service and oem-config.service, leftovers from the Ubuntu live/OEM installer. Harmless; masking them is queued for v1.0.1.
  • AV1 is software-only. The rkmpp plugin implements H.264, HEVC, VP8 and VP9 — there is no AV1 in the hardware path on this stack. YouTube increasingly serves AV1, so an extension that forces H.264/VP9 will keep more streams on the hardware decoder.

Honest scope

This is the vendor/BSP road, and it works today. The eventual clean road is mainline — Panthor plus a current Mesa — and we'll move to it when it carries VP9/AV1 and 4K@120. Local video (mpv/VLC) was always hardware-decoded and is unaffected by any of this.

Install

Flash to eMMC, NVMe, or SD (16 GB minimum). See EMMC-INSTALL.md — read the stale-bootloader note before flashing eMMC.

Verify your download first:

sha256sum -c pidesktop-v1.0-vanilla-sky-orangepi-5b.img.xz.sha256

6eea85a4b44ea33263287c25cf896c759d997f21bbe8f0aa58289350103248f9

Built from defcom5-rockchip/ubuntu-rockchip.

Assets 4
Loading