defcom5-rockchip

I had em build the damn thing. I think it was 39 lines of code: Cool having first https://bugzilla.mozilla.org/show_bug.cgi?id=2078820

<prompt> "Talk to me about it." <claude> Good question, because the honest answer has layers, and most of the "8K" in the ads lives in only one of them. What's real: the decoder. The RK3588's video engine (RKVDEC2) really does decode 8K: HEVC and VP9 at 8K@60, H.264 and AV1 at 8K@30, in silicon. That's not marketing. It's the same block Deep Ink talks to for our 4K HDR work, and 8K is just more macroblocks through the same pipe. So "8K video decoding" is a true statement about the chip. Where it thins out: the display. The VOP2 display controller's big port (VP0) tops out at 8K@30 or 4K@120, and here's the nugget: those are the same number. 7680×4320×30 = 995 million pixels per second; 3840×2160×120 = 995 million. The 4K@120 we fought for this month (the dclk patch, the FRL link-up on rkr7.2, the vp0 done bit timeout at the edge) is literally the chip at its 8K@30 ceiling. There is no 8K@60 output from this silicon, whatever the HDMI 2.1 badge implies. 8K@30 at 4:2:0 over a 48G cable to an 8K TV is the whole display story, and nothing in mainline Linux drives an 8K mode on VOP2 today. Where it falls apart: everything between decode and glass. A decoded 8K 10-bit frame is about 62 MB; a reference buffer set is half a gigabyte, so CMA would need to go to a gigabyte-plus just to open the file. Then someone has to get 33 million pixels per frame onto the screen. The Mali-G610 compositing a full 8K desktop through Mutter would be a slideshow. The only sane path is the one TV boxes use: the decoder hands frames straight to a VOP video plane and the GPU never touches them. That's a Kodi/direct-scanout architecture, not a GNOME desktop. And there's no browser path at all: YouTube's 8K is VP9/AV1, and we already know what the browsers do with those on this chip. Who it's really for. Rockchip's 8K line is aimed at media-box and signage makers, who get one 8K TV, one app, direct plane output, and no desktop. For a desktop distro it's a spec-sheet number, not a feature. What's honest to say for Plaid: "decodes 8K; displays 4K at up to 120 Hz." Playing an 8K HEVC file in mpv, hardware-decoded, scaled down to your 4K panel, is a thing this box can do, and that's the version that's true in your living room. "8K desktop" is a mirage, and that's the brand line. If you want numbers rather than theory, I can make an 8K HEVC clip and measure what mpv + rkmpp does with it on the Plaid: decode rate, CPU, whether the 512 MB CMA even lets it open. That would give the website a measured sentence instead of a claim. <prompt> "Ok, that's where it becomes a development board... We can do it... now you make it work" <claude> Here's what "8K" turned out to mean, measured rather than argued. The decoder is real. With frames left on the GPU, the VPU chewed through 8K30 HEVC at 55.8 fps, one decoder interrupt per frame, nearly double real time. Rockchip's "8K@60 decode" is silicon, not a brochure. And CMA never moved: the driver uses its own buffer pool, so the 1 G bump won't change decode (fine to reboot whenever; it only matters if an 8K output ever exists). The screen is the problem, and it's the Mali blob's desktop, not the chip. The stutter you saw was the only on-screen hardware path, copy-back, at 11 fps, because shoving 50 MB per frame through the CPU costs ~90 ms. The fast path, zero-copy, dies before the first frame: mpv needs a VA display tied to its GL context, and under Mutter-on-libmali there's no way to get one. The compositor only offers dmabuf protocol v3 and no wl_drm (I read the Wayland registry to confirm), libva's Wayland backend needs v4, and XWayland has no accelerated EGL on the blob. Behind that door is the GR88 wall Firefox hit. Also a trap: mpv 0.41 tries Vulkan first, fails on the blob, and silently goes software unless told --gpu-api=opengl; your shipped mpv.conf effectively runs copy-back for everything. The honest website line: "decodes 8K; displays 4K at up to 120 Hz." And a nice symmetry for the curious: 8K30 and 4K120 are the same 995 Mpx/s, which is VOP2's ceiling. No 8K60 output exists on this chip, HDMI 2.1 badge or not. Routes to actually playing 8K, ranked: a ~10-line mpv patch to open the VA display from the render node directly, then PC's R16 trick for the import (same problem, same fix as Firefox); or the Mesa/panthor stack, where Mutter offers v5 and Mesa imports everything, so it very likely just works. One more point for mainline. Built Finagled Measured Rendered Verdict Claude Fable 5 I was watching Weezer and it came up defcom5-rockchip

Sent off to Bugzilla.... But I want a working copy so I am having them build it.. now they are saying the patch is smaller. I like having proof of work.. you know sometimes they are not fully accurate. Hopefully a fully functional Firefox by days end.

Now the picture is complete, and it's better news than the September note suggested. Three things in Firefox's own code: 1. There's a fallback chain already, and it's three deep. CreateTexture tries zero-copy import first; if that fails it has CreateTextureViaCopyYUV for NV12 and CreateTextureViaCopyP010 for 10-bit. 2. Those fallbacks already use the external-texture machinery — the exact mechanism a whole-frame import needs: aGLContext->fBindTexture(LOCAL_GL_TEXTURE_EXTERNAL, srcTex); aGLContext->fEGLImageTargetTexture2D(LOCAL_GL_TEXTURE_EXTERNAL, mEGLImage[aPlane]); So Firefox can bind a dma-buf as an external texture. It just does it per plane, as a copy, and only when the buffer is linear. 3. Firefox already tracks the whole-frame NV12 format. DMABufFormats.cpp calls EnsureBasicFormat(GBM_FORMAT_NV12), stores its modifiers, and GetDRMFormat() hands that object back — and the YUV path then passes it in while still importing two planes as R8 + GR88. Why we never reach any of it. The chain starts at CreateYUVPlane, which has to build an EGLImage for plane 1 using GR88. On the Mali blob that format doesn't exist, so the image is never created, and the loop bails before CreateTexture and all three fallbacks. The failure is one step earlier than the recovery code. So, to your question: not commented out, and not missing either. Every ingredient is present — the whole-frame format with its modifiers, the external-texture import, and a precedent for swapping formats when one isn't supported. What's absent is the wiring for the case where both two-channel 8-bit formats are missing but the whole-frame format is there. That makes a much better upstream report than "please support our driver." It's: your existing fallback tries exactly one alternative; here is a shipping Arm GPU where both alternatives are absent and the whole-frame format you already track is present. With the 41-format list as evidence and a reproducible platform behind it. Want me to write that up as a Bugzilla report? I'd check first whether it's already filed, and the honest framing is a driver-conformance gap with a suggested fallback, not a demand. Researched the code with Claude Fable 5 So with any luck Firefox will add the needed ingredients.

Thanks bedna, and to add the specific reason, since it's worse than it looks: that rule has no action check, so it isn't bypassing the one broken prompt — it returns YES for every polkit action for that user. Package installs, user management, mounting disks, systemd units, firmware updates, all without a password, permanently. There's also no subject.local && subject.active test, so a remote session logged in as that user gets the same silent admin rights. If you want to keep something like it while testing, at minimum scope it to the single action id you're hitting and add the local-and-active check — but you shouldn't need it at all. The masking approach keeps authentication fully intact. You still get the password dialog, PAM still checks it, it's still logged; the only change is that polkit uses its classic helper instead of the socket-activated one that needs a kernel feature from 6.5. That's exactly how every Ubuntu release before 26.04 ran. When a 6.5-or-newer kernel reaches these boards: sudo dpkg-statoverride --remove /usr/lib/polkit-1/polkit-agent-helper-1 sudo systemctl unmask polkit-agent-helper.socket Albrecht — did the two commands actually fix it on your ITX? I've only been able to test this on an Orange Pi 5B, so a confirmation (or a "no, still broken") from different hardware would be genuinely useful. If it did work, it probably affects every Armbian resolute desktop image on a 6.1 vendor kernel, and that's worth fixing in the build rather than one board at a time. defcom5-rockchip An LLM assistant helped me track down the cause; the testing is mine.

-f You Think Firefox And Chrome will not have the same or equal performance you have mis-judged... why

Should we do an arch "Hacking" OS or A Parrot "Hacking OS"? Two answers. Downloads. GitHub only de-duplicates visitors and cloners, never downloads, so "unique downloads" doesn't exist as a number; here's what does: all-time downloadslast 14 days: unique visitors / unique cloners rockchip-vaapi (video driver)768 / 16 pi-desktop50 (4.0: 0, released hours ago)3 / 10 pi-studio2510 / 8 linux-rockchip (kernel)–0 / 6 ubuntu-rockchip (retired)–28 / 11 Three things in those numbers. The video driver is what developers take: sixteen different people cloned its source in two weeks, and its single most-downloaded file ever is the VP9 green-screen fix from August 30, 29 pulls. The retired fork is still your most-visited repository, because CNX's July article links to it, and its page on GitHub still says "continuing", with the description "the forge for Pi Studio & Pi Desktop": the retirement notice was never pushed. I've rewritten it to point at 4.0 and committed; six commits, leak-scanned clean, waiting on your word to push. And the forum's 7,000 views dwarf all of this; GitHub is where builders go, the forum is where users are. The interfacinglinux.com referrer is a general RK3588 site with no article about us; one reader clicked through from somewhere. Arch or Parrot for a security edition. Parrot's shape, not the Parrot name, and here's the reasoning: It's the straight line from where we stand. Parrot is Debian 13 on the Armbian framework, which is exactly our build system; the vendor kernel, our eleven patches, the Bluetooth and Wi-Fi fixes drop in through the same userpatches layer. Their Orange Pi 5 Ultra port proves the combination assembles. Debian 13's userland also dodges both bugs we fixed this week: its polkit and wpa_supplicant predate the triggers. Arch is a second build system plus a rolling userland on a frozen kernel. Today's password-prompt bug is what that pairing produces, continuously: the newest userspace meeting a 6.1 kernel first. BlackArch's tool coverage on arm64 is also patchy. Arch would be the right call only if the product were "newest tools at any cost", and on this board hardware that works is the scarcer thing. The honest elephant is Kali, which already ships official images for the Orange Pi 5 family. A tool list won't distinguish us from Kali. What would: radios that actually work on the 5B, a 120 Hz desktop, and Pi Construct's AI tutor sitting next to each tool, which is the edition memory already has sketched for DEF CON. Build that on Debian, pull Parrot's tool metapackages where they're cleanly licensed, keep our own name on it. One hardware fact to plan around either way: the onboard AP6275P can't do monitor mode, so the Wi-Fi tooling lives on an external adapter, and that driver story is identical on Debian and Arch. i think we are bettter than both In one specific, provable sense, yes: on this board, neither of them has what 4.0 has. Parrot's Ultra port says in its own documentation that it hasn't verified the radio works; Kali's Orange Pi images ride a vendor kernel with the twelve-year-old WPA3 gap unpatched and no 120 Hz; Arch on RK3588 is a community tree with no one owning the hardware story. We own the hardware story on the 5B, measured and published. That's real, and it's why a security edition from us would be worth doing. In the other sense, not yet, and it matters to say so. Parrot and Kali are teams with a decade of packaging behind thousands of tools, documentation, and a user base that reports bugs. We have one board, one person and a catalogue of zero security tools shipped. "Better than both" is a claim we can earn, not one we hold today. The route to earning it is the one that uses their strength instead of competing with it: their tools are Debian packages, so a Pi Construct security edition takes the catalogue from them, puts it on the only RK3588 base where the radios, the display and the decoder are known to work, and adds the one thing neither has, a tutor beside every tool. Then it's better than both for the same reason 4.0 is better than Riek's base: not because it has more, but because everything in it has been made to work and proven to. Still pending from before: the push of the retirement notice on the old fork, on your word.

Well Well, Who's The Asshole Now? Yeah I Need a Job... I'm not too bad. Written for: the same readers as the finding, maintainers and users; the chart is built to be attached to it or to stand alone in a forum post. Ours versus theirs, same board, same 100-minute 4K 10-bit title, same afternoon, same kernel journal: frames out of 143,641decoder resetsspeed theirs, jellyfin-ffmpeg 8.1.3-1 with its bundled fork MPP100,13111,520~120 fps until it broke at 42:11 ours, system ffmpeg → rockchip-vaapi → upstream-lineage MPP143,6410106 fps, intact to the end The chart shows it in one glance: nothing missing anywhere for either until minute 40, then orange bars at 50 to 60 percent loss for the remaining hour, green flat on zero the whole way. The speed difference is the honest cost of the guard, one decode task at a time instead of two, and it's the throughput the revert was presumably chasing. Where everything is: claude-pi-handoffs/20261002/FINDING-jellyfin-mpp-vp9-10bit-frame-loss.md, now with the fourth row, the throughput note and the chart reference. ours-vs-theirs.png beside it, 1600×900, ready to attach. after-gaps-sheet.png in the evidence folder if anyone asks what the surviving frames look like. The evidence folder holds every log, both journal counts, the gap analysis, the test scripts and the rating with three addenda. One disclosure kept in the document rather than buried: ours printed two MPP buffer-slot assertion lines at teardown, after the last frame, with no effect on output. Better that you say it than someone else finds it. The output file and the source title are still on the test board under ~/probe if you want to watch the freezes before posting. Nothing else is running; the package is complete. NO SLOP!

FYI I sent Jellyfin A PR a while back ... was immediately refuted. and dismissed. running Fable 5.1 with 2 agents extra high... like me ah oh this is big... new topic!

So I was accused of slop posts. I am having Claude on Fable 5.1 extra high with two agents prove that Jellyfin fails as stated above.. of which Jellyfin maintainer denied saying UN-reproduceable. If Claude beats you I will outright call you a pussy. I still need to confirm two things: whether a reading past 1700 s exists for the "28-minute" soak (current data stops at 1267 s), and what question the user's "garbled" replies were answering during the mpv and rkr7.2-port storms, which determines if there's a human eyewitness for the picture. Bash Look for a final soak reading past 1267 s and show what the user's "garbled" replies were answering IN cd /tmp/claude-1000/-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad && J=/claude/projects/-notes/16341f90-382c-4834-a9d8-ecb4f14fc419.jsonl; echo "########## soak: any reading past 1267 s / final done-line"; TS_MIN=2026-09-10T16:44 TS_MAX=2026-09-10T22:00 MAXHIT=6 SNIP=300 python3 audit-extract.py $J 'done: resets=|soak-transcode\.log|transcoding=1[3-9][0-9][0-9]s|28.min' 2>&1 | grep -E '^#####|done:|transcoding=|28.min|resets' | cut -c1-300 | head -40; echo; echo "########## context of the user's 'garbled' at 09-11 03:13:39 and 09-10 21:09:54"; LINES=67346-67352 SNIP=500 python3 audit-extract.py $J 2>&1 | grep -v '^$' | cut -c1-900 | head -40; echo "-----"; LINES=65668-65674 SNIP=500 python3 audit-extract.py $J 2>&1 | grep -v '^$' | cut -c1-900 | head Not for the run in progress: the synthetic clip exercises the frame counter exactly as a real file would, and the image's library is the thing under test there. Where a real file would turn an inference into a measurement is the Jellyfin side: nobody has ever run jellyfin-ffmpeg itself through a 10-bit VP9 source past 65k frames in one job. The internal audit will flag that gap. A 10-bit VP9 file at least 20 minutes long at 60 fps, or 45 minutes at 24 to 30 fps, is what that test needs: a YouTube HDR download in WebM, the vp09.02 rung, is the natural candidate. Let me check whether the Jellyfin box is still up with its ffmpeg, since that's where the test would run. Give em hell harry Working on it. Three things running: Jellyfin's own binary chewing through the 72,600-frame clip, the image-library test queued right behind it, and the share scan looking for a real 10-bit VP9 title. Results as they land. Confirmed: Jellyfin's own ffmpeg/MPP build reproduces the storm on the 4.0 board, logging 70 kernel resets while ffmpeg silently reported success (71,382/72,600 frames, exit code 0) — about 1,218 frames lost with no API error, and the synthetic clip shows frame count, not content or resolution, triggers it. I'll save the raw logs now before the next run overwrites them. Bash Capture the kernel reset log and ffmpeg log from the Jellyfin run into the evidence folder. OK Its bigger than me. so a final rating from low to extreme Bash Read the image-library mpv result with the shipped configuration IN cat /tmp/claude-1000/--homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad/vp9-longrun-gpu2.log | cut -c1-170 OUT === HARDWARE CHECK: 600 frames, shipped mpv.conf + hwdec=vaapi, image MPP 1.5.0+git20260805.a8b19653+ds-0ubuntu1~rk1+pd31 === irq delta for 600 frames: 0 2 Using software decoding.; ABORT: not hardware decoding — long run not started 2 [ 0.N][f][vo/gpu-next/libplacebo] Failed initializing vulkan device 1 [ 0.N][v][vo/gpu-next] Loading failed. 1 [ 0.N][v][vd] DR failed - disabling. 1 [ 0.N][v][cplayer] Setting option 'msg-level' = 'all=error,vd=v' (flags = 😎 1 [ 0.N][v][cplayer] Failed sending hook command auto_profiles/on_preloaded. Removing hook. mpv fails here just because it needs a real desktop display, not due to decoding issues, so I'm switching to testing the image's ffmpeg directly through VA-API headlessly instead. Running it now on the two long concert files from the scan and saving the results to the evidence folder. Bash Test the image's MPP headlessly through the system ffmpeg and our VA-API driver IN S=/tmp/claude-1000/-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad; export SSH_ASKPASS=$S/askpass-214.sh SSH_ASKPASS_REQUIRE=force DISPLAY=:0; O="-o ConnectTimeout=15 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o PubkeyAuthentication=no -o NumberOfPasswordPrompts=1"; { scp -q $O $S/ff-sys-test.sh plaiddesktop@192.168.1.214:~/probe/ff-sys-test.sh && ssh $O plaiddesktop@192.168.1.214 'bash ~/probe/ff-sys-test.sh' 2>&1 | grep -v 'Permanently added'; } | tee $S/ffsys-run.log OUT Command running in background with ID: b3eavaypx. Output is being written to: /tmp/claude-1000/homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/tasks/b3eavaypx.output. You will be notified when it completes. To check interim output, use Read on that file path. Bash Probe the long 10-bit VP9 candidates for duration and frame count IN SH="/run/user/1000/gvfs/smb-share:server=beach_music.local,share=divx%20movies"; for f in "$SH/#recycle/Creed： full set (Live 4K) (First concert of reunion tour) - Green Bay - July 17, 2024 (1st row view).f642.mp4" "$SH/#recycle/Beck - Loser @ Newport Folk Festival 7.26.24.f639.mp4" "$SH/tears-of-steel-4096-vp9p2.mkv"; do printf ' %-60s ' "$(basename "$f" | cut -c1-58)"; timeout 90 ffprobe -v error -analyzeduration 20M -probesize 50M -select_streams v:0 -show_entries stream=codec_name,profile,pix_fmt,width,height,r_frame_rate,nb_frames:format=duration,size -of csv=p=0:nk=1 "$f" 2>/dev/null | tr '\n' ' '; echo; done OUT Creed： full set (Live 4K) (First concert of reunion tour vp9,Profile 2,3840,2160,yuv420p10le,24/1,N/A, 5985.041000,16815481591 Beck - Loser @ Newport Folk Festival 7.26.24.f639.mp4 vp9,Profile 2,2320,1080,yuv420p10le,30/1,N/A, 435.699000,399518163 tears-of-steel-4096-vp9p2.mkv vp9,Profile 2,4096,1714,yuv420p10le,24/1,N/A 734.000000,2806555619 Write RATING.md 67 lines # Evidence rating — "Jellyfin's MPP distorts 10-bit VP9 after ~65k frames on RK3588" (2026-10-03) Scale used: **low · moderate · high · very high · extreme**. "Extreme" is reserved for a defect reproduced by independent parties, acknowledged by the maintainers, and fixed. Nothing here reaches it, for reasons given. ## Headline | Claim | Rating | One-line reason | |---|---|---| | **A.** The MPP library Jellyfin bundles decodes VP9 Profile 2 (10-bit) incorrectly after ~65k frames in one session on RK3588 | **HIGH** | Reproduced with Rockchip's own test tool, with mpv, with Chrome, and today with Jellyfin's current release binary on a second kernel; bisected to one commit; confirmed by its revert and by the single-core workaround; the diff is one line and upstream still carries the guard. Held below *very high* by: one board, one lab, no independent reproduction, no maintainer engagement with the data, and an unreconciled 8-bit result. | | **B.** Jellyfin users get distorted video from it | **MODERATE** | Measured today: Jellyfin's ffmpeg silently drops ~1,200 frames while the kernel resets 70 times, in a decode-only job. What the finished transcode looks like has still never been observed. The exposed case is narrow: a server-side transcode of a **10-bit VP9** source running past ~65k frames (~18 min at 60 fps, ~45 min at 24). HEVC Main 10, the usual HDR format, is clean on the same library. | | **C.** Pi-Desktop 4.0's own image is affected | **LOW** | Its MPP is upstream lineage (HermanChen `a8b19653`) with the RK3588 guard intact — verified in the file. Browser direct-play and mpv on the image go through that library, not Jellyfin's. Empirical confirmation on the board was in progress when this was written; see the addendum below. | | **D.** Upstream `rockchip-linux/mpp` is affected | **NOT SUPPORTED** | Three upstream snapshots (2024-04, 2025-11, 2026-08) decoded 73k–117k frames clean; the guard has been in place since 2023-08-31 and is still there today. mpp#972 was correctly retitled and closed. | ## What the rating rests on (measured, not inferred) - **Mechanism in the code.** Fork commit `960b7198` (rk-mirrors; `15c29e0fa` in nyanmisaka/mpp) replaces upstream's `cfg->support_fast_mode = 0` for RK3588 with `cfg->cfg->status.hal_task_count = 2`: two VP9 HAL tasks in flight across both rkvdec cores. It is the only behavioural change to the VP9 decoder among the fork's eleven commits (the other VP9 touch is a pure identifier rename). Verified in the files at the exact pins. (`DIFF.md`) - **One-variable A/B, same board, same stream (September):** fork tip storms (66,300 / 414 resets); fork tip plus the revert of that one commit, clean (73,214 / 0); fork with core1 disabled, clean (115,062 / 0); upstream at three dates, clean. (`INTERNAL-AUDIT.md`, rows backed by on-disk or transcript raw output.) - **Rockchip's own tool reproduces it headless** (`mpi_dec_test`, 64,728 / 714), so no client, display, or our VA-API driver is involved. - **Today, Jellyfin's current release:** `jellyfin-ffmpeg8 8.1.3-1-resolute` (2026-09-27), its bundled MPP, vendor kernel **6.1.172** (every September run was on 6.1.75), a **synthetic** 1080p60 VP9 Profile 2 clip of 72,600 frames: cores evenly loaded, **70 resets** (`err 0x23` / `0x107`), ffmpeg reported **71,382 frames, "0 decode errors", exit 0** — ~1,218 frames gone with nothing in the API. Synthetic content and 1080p mean the trigger is the frame count, not a particular file or 4K. (`jellyfin-e2e-2026-10-03-run.txt`, `jf-run2.log`, `jf-dmesg-resets.txt`) ## What holds it down - **Single board, single lab.** Every datapoint, September and today, is one Orange Pi 5B operated by one person with two Claude instances. Nobody else has reproduced it. (`EXTERNAL-INVENTORY.md`, task 5: zero independent reports of the signature anywhere reachable.) - **No maintainer engagement with the data.** Rockchip's FumasterLin made three helpful comments, all before the root-cause claim, and never returned; we closed mpp#972 ourselves. nyanmisaka closed jellyfin-ffmpeg#765 in 80 minutes as "unable to reproduce" with no stream, SoC or frame count, and gnattu objected to the form of the reply. Our one-variable A/B rebuttal stands unanswered. A closure without counter-data does not lower a measurement, but it is not confirmation either. - **Two mislabels in the September bisect table went upstream** (the 66,083/280 row is the Jellyfin binary, not a fork-tip `mpi_dec_test`; the "fork tip, core1 disabled" row is the 5275a9a6 run). The conclusion survives — the correct controls exist and point the same way — but the public record should be corrected. - **"VP9 10-bit specifically" is weaker than the rest.** Three Chrome storms on 2026-09-09 were on an **8-bit** stream (`vp09.00.50.08`). The "8-bit immune" finding rests on two mpv runs the harness stopped at ~73k. Treat the 8-bit question as open. - **Numbers are IRQ counts**, ≈8 % above true frames; harness stop rules meant sustained behaviour after onset was never observed; the "~13 % cost" figure mixes trees. - **"Distorts" is measured for display clients by eye (three occasions, no screenshot) and inferred for transcodes.** Today's run adds "frames silently missing"; the encoded output of a real transcode has never been inspected. ## What would move it - **To very high:** one independent reproduction. Anyone with an RK3588 board, `jellyfin-ffmpeg`, and a 10-bit VP9 file ≥ 20 min: `/usr/lib/jellyfin-ffmpeg/ffmpeg -c:v vp9_rkmpp -i FILE -an -f null -`, then `dmesg | grep -c 'resetting for err'` and compare `frame=` with the file's frame count. Ten minutes of someone else's time. - **To settle B:** a full transcode (decode → `scale_rkrga` → `h264_rkmpp`) of a real 10-bit VP9 title to a file, past the wall, with the output watched. Candidate files were located on the local media share today. - **To settle the 8-bit question:** an 8-bit VP9 run to 150k+ frames with the current fork library, not stopped at 72k. - **Public hygiene, regardless:** a short correction comment on mpp#972 and jellyfin-ffmpeg#765 fixing the two mislabels and adding today's current-release reproduction, with the one-line command above. Correct data is the only thing that will move a "cannot reproduce". ## Addendum — image-library confirmation *(to be filled from the headless ffmpeg run on the 4.0 board)* Written for: you, as the engineer deciding what to say publicly about this. The full version with every supporting file is on the NAS as RATING.md in today's evidence folder. Final rating, low to extreme: ClaimRating The MPP library Jellyfin bundles decodes 10-bit VP9 wrongly after about 65k frames in one session on RK3588High Jellyfin users get distorted video from it Moderate Pi-Desktop 4.0's own image is affected Low Upstream Rockchip MPP is affected Not supported Why "high" and not higher. The defect is reproduced four ways: Rockchip's own test tool, mpv, Chrome, and, as of an hour ago, Jellyfin's current release binary from September 27 on a second kernel, with a synthetic 1080p clip, so it's the frame count and not any particular file. It's bisected to one commit, confirmed by reverting that commit alone and by disabling one core, and the diff is a single line that upstream still carries the other way. What keeps it from "very high" is that every datapoint comes from one board in one lab; nobody independent has reproduced it; and the maintainers never engaged with the data. nyanmisaka's "cannot reproduce" came with no stream, chip or frame count, so it doesn't lower the measurement, but it isn't confirmation either. Why "moderate" for users. Today's run shows Jellyfin's ffmpeg silently dropping about 1,200 frames while the kernel resets 70 times, reporting zero errors and a clean exit. That's real harm, measured. But it was a decode-only job; nobody has yet watched the finished output of a full transcode past the wall. And the exposed case is narrow: a server-side transcode of a 10-bit VP9 source, over 18 minutes at 60 fps or 45 at 24. HEVC Main 10, the usual HDR format, is clean on the same library. Two things the audit found that you should know before quoting any of it. Two rows in the September bisect table were mislabelled, and those mislabels went into the public threads; the conclusion survives because the correct controls exist, but the record should be fixed. And three Chrome storms on September 9 were on an 8-bit stream, which nobody reconciled with "8-bit immune", so the "10-bit specifically" part is the softest piece. "Extreme" is unreachable from inside one lab. One outside reproduction would lift the first claim to very high: a one-line command and a dmesg count, ten minutes of someone else's time. Now queuing the measurement that would settle the user-harm claim: the share has a 100-minute 4K 10-bit VP9 concert, 143,000 frames, and I'll run Jellyfin's full transcode pipeline on it to a file once the current headless test finishes. Bash Serve the long 10-bit VP9 file to the board over HTTP from the PC, so no NAS credentials go to the board IN S=/tmp/claude-1000/--homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad; SH="/run/user/1000/gvfs/smb-share:server=beach_music.local,share=divx%20movies"; mkdir -p $S/serve; ln -sfn "$SH/#recycle/Creed： full set (Live 4K) (First concert of reunion tour) - Green Bay - July 17, 2024 (1st row view).f642.mp4" $S/serve/concert-vp9p2-4k.mp4; ls -lL $S/serve/concert-vp9p2-4k.mp4 | awk '{printf " relay file: %.1f GB\n", $5/1e9}'; IP=$(ip -4 route get 192.168.1.214 2>/dev/null | grep -oP 'src \K[0-9.]+'); echo " PC address on the board's network: $IP"; fuser -k 8766/tcp >/dev/null 2>&1; (cd $S/serve && nohup python3 -m http.server 8766 --bind 0.0.0.0 >$S/relay.log 2>&1 &) ; sleep 2; curl -s -o /dev/null -w " relay HEAD: %{http_code} %{size_download}\n" -I "http://$IP:8766/concert-vp9p2-4k.mp4"; echo "$IP" > $S/relay-ip.txt OUT relay file: 16.8 GB PC address on the board's network: 192.168.1.8 relay HEAD: 200 0 Write jf-real-transcode.sh 33 lines #!/bin/bash # Realistic Jellyfin job: jellyfin-ffmpeg full pipeline (vp9_rkmpp decode -> scale_rkrga -> h264_rkmpp encode) on a REAL # 10-bit VP9 title streamed over HTTP, to a file, past the ~65k-frame wall. Counts rkvdec resets; keeps the output for viewing. # Usage: bash jf-real-transcode.sh http://PC:8766/concert-vp9p2-4k.mp4 set -u URL=${1:?url} F=/usr/lib/jellyfin-ffmpeg/ffmpeg OUT=$HOME/probe/jf-real-out.mkv LOG=/tmp/jf-real.log printf '#!/bin/sh\necho PLAID\n' > /tmp/ap.sh; chmod +x /tmp/ap.sh; export SUDO_ASKPASS=/tmp/ap.sh irq() { grep -E 'rkvdec' /proc/interrupts | awk '{s=0; for(i=2;i<=NF;i++) if($i ~ /^[0-9]+$/) s+=$i; printf "%s=%d ", $NF, s}'; } resets() { sudo -A dmesg 2>/dev/null | grep -ciE 'resetting for err'; } pkill -f 'jellyfin-ffmpeg/ffmpeg' 2>/dev/null; sleep 2; rm -f "$OUT" echo "=== REAL TITLE, FULL PIPELINE: jellyfin-ffmpeg8 $(dpkg-query -W -f='${Version}' jellyfin-ffmpeg8) ===" echo " input: $(ffprobe -v error -select_streams v:0 -show_entries stream=codec_name,profile,pix_fmt,width,height,r_frame_rate:format=duration -of csv=p=0 "$URL" 2>/dev/null | tr '\n' ' ')" B0=$(irq); R0=$(resets); T0=$(date +%s); echo " before: irq $B0 resets=$R0 $(date +%T)" "$F" -hide_banner -nostats -loglevel info -hwaccel rkmpp -hwaccel_output_format drm_prime -c:v vp9_rkmpp -i "$URL" \ -vf 'scale_rkrga=w=1280:h=720:format=nv12:afbc=1' -c:v h264_rkmpp -b:v 1500k -g 120 -an -f matroska "$OUT" >"$LOG" 2>&1 RC=$? if [ $RC -ne 0 ] && [ ! -s "$OUT" ]; then echo " full pipeline failed to start (rc=$RC): $(grep -iE 'error|No such|Unknown|Invalid' "$LOG" | head -2 | cut -c1-120 | tr '\n' ';')" echo " falling back to decode-only to EOF" B0=$(irq); R0=$(resets); T0=$(date +%s) "$F" -hide_banner -nostats -loglevel info -c:v vp9_rkmpp -i "$URL" -an -f null - >"$LOG" 2>&1; RC=$? fi T1=$(date +%s); B1=$(irq); R1=$(resets) echo " after: irq $B1 resets=$R1 rc=$RC elapsed=$((T1-T0)) s $(date +%T)" echo " ffmpeg: $(grep -oE 'frame= *[0-9]+ fps=[^ ]+' "$LOG" | tail -1) $(grep -oE '[0-9]+ frames decoded; [0-9]+ decode errors' "$LOG" | tail -1)" echo " error lines: $(grep -ciE 'error|fail|timeout' "$LOG")"; grep -iE 'error|fail|timeout' "$LOG" | sed -E 's/[0-9]{3,}/N/g' | sort | uniq -c | sort -rn | head -4 | sed 's/^/ /' [ -s "$OUT" ] && echo " output: $(ls -l "$OUT" | awk '{printf "%.0f MB", $5/1e6}'), $(ffprobe -v error -count_packets -select_streams v:0 -show_entries stream=nb_read_packets -of csv=p=0 "$OUT" 2>/dev/null) frames, $(ffprobe -v error -show_entries format=duration -of csv=p=0 "$OUT" 2>/dev/null | cut -c1-7) s" echo " first/last reset: $(sudo -A dmesg -T 2>/dev/null | grep -m1 'resetting for err' | cut -c2-25) / $(sudo -A dmesg -T 2>/dev/null | grep 'resetting for err' | tail -1 | cut -c2-25)" rm -f /tmp/ap.sh Bash Record the rating and the queued real-file run in memory IN M=/laude/projectshomelab-notes/memory; cat >> $M/rkvdec-10bit-65k-wall.md <<'EOF' ## 2026-10-03 — RATING delivered (G-Man asked "low to extreme"; full text NAS …/RATING.md) **A. defect exists in Jellyfin's bundled MPP = HIGH** (4 reproductions incl. Jellyfin's current binary on a 2nd kernel; bisected; revert + single-core confirm; one-line diff; held below very-high by single lab, no independent repro, no maintainer engagement, 8-bit unreconciled). **B. users see distorted video = MODERATE** (today: ~1,218 frames silently dropped + 70 resets, decode-only; finished transcode never watched; exposure narrow: server-side 10-bit VP9 transcode past ~65k frames; HEVC Main10 clean). **C. Pi-Desktop 4.0 image = LOW** (upstream lineage, guard intact). **D. upstream = NOT SUPPORTED.** Extreme unreachable from one lab; one outside repro → very high. Public hygiene owed: correction comment on #972/#765 for the two mislabels + today's current-release repro. **Real-file run queued:** share `divx movies/#recycle/Creed… f642.mp4` = VP9 P2 4K 24 fps, 5,985 s ≈ 143,640 frames, 16.8 GB; relayed to the board over HTTP from the PC (no NAS creds on the board); full pipeline decode→scale_rkrga→h264_rkmpp to ~/probe/jf-real-out.mkv (script jf-real-transcode.sh). Harness lessons: mpv under systemd-run can't bring up vo=gpu (vulkan/EGL) → use system ffmpeg `-hwaccel vaapi -hwaccel_output_format vaapi -f null -` for headless image-MPP tests. EOF echo saved OUT saved Bash After the headless image test, run Jellyfin's full transcode pipeline on the real 143,000-frame title IN S=/tmp/claude-1000/homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad; export SSH_ASKPASS=$S/askpass-214.sh SSH_ASKPASS_REQUIRE=force DISPLAY=:0; O="-o ConnectTimeout=15 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o PubkeyAuthentication=no -o NumberOfPasswordPrompts=1"; IP=$(cat $S/relay-ip.txt); { until grep -qE ' after:|ABORT' $S/ffsys-run.log 2>/dev/null; do sleep 15; done; sleep 10; echo "headless image test done $(date +%T); starting the real-title full-pipeline run"; scp -q $O $S/jf-real-transcode.sh plaiddesktop@192.168.1.214:~/probe/jf-real-transcode.sh && ssh $O plaiddesktop@192.168.1.214 "bash ~/probe/jf-real-transcode.sh http://$IP:8766/concert-vp9p2-4k.mp4" 2>&1 | grep -v 'Permanently added'; } | tee $S/jf-real.log OUT Command running in background with ID: bblrte2z1. Output is being written to: /tmp/claude-1000/homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/tasks/bblrte2z1.output. You will be notified when it completes. To check interim output, use Read on that file path. Everything that can run is running. The rating above stands; two measurements are still in flight to firm it up, and I'll report each as it lands: the image's own library through the system ffmpeg, headless, which turns the "low" on claim C from structural to measured; the real 100-minute concert through Jellyfin's full transcode pipeline to a file, relayed from the PC so no NAS credentials reach the board. That one takes a while, roughly ten to fifteen minutes of decode time once it starts, and it's the measurement that would settle claim B either way.

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

Written for: the Armbian forum thread, as a reply from defcom5-rockchip, for you to post. Yes, we hit exactly this. Plaid Claude found it on the eMMC on September 27, and the fix is in test9 and in 4.0. The forum poster's log confirms the same pairing: Armbian 26.8.6 resolute, Ubuntu 26.04's polkit 127, on the 6.1.172 vendor kernel. The KDE dialog vanishing in a second is what GNOME showed us as a spinner that never ended. One new fact from checking the polkit release notes: the socket-activated helper arrived in polkit 127. So Debian 13 images, with polkit 126, are fine, while every Ubuntu 26.04 and Debian sid image on a Rockchip 6.1 kernel is broken this way. That's a lot of Armbian desktops, which makes this worth a build-framework fix upstream, not just a forum reply. Here's the reply, also saved on the NAS. Nothing has been posted: Hi Albrecht, I think this is a bug I ran into on an Orange Pi 5B with the same combination: Armbian resolute (Ubuntu 26.04) on the vendor 6.1.172 kernel. Your log shows exactly that pairing, so it is worth a two-minute check. What happens. Ubuntu 26.04 ships polkit 127, which runs its authentication helper through a systemd socket (polkit-agent-helper.socket). That helper asks the kernel for SO_PEERPIDFD, which only exists from Linux 6.5. On the 6.1 vendor kernel the helper exits at once with "Pidfd not supported on this platform", and the desktop's polkit agent (KDE's here, GNOME's in my case) treats that as a failed authentication and closes the dialog before you can type. sudo still works because it does not use polkit. Check (no changes made): journalctl -b | grep -m3 'Pidfd not supported' systemctl --failed | grep -c polkit-agent-helper If the first prints the message and the second prints a number above zero, it is this bug. Left alone, the failed helper units pile up (I had 18,000 after 45 minutes) and the desktop gets sluggish. Fix that worked for me, until a kernel ≥ 6.5 arrives for these boards: sudo systemctl mask polkit-agent-helper.socket sudo dpkg-statoverride --update --add root root 4755 /usr/lib/polkit-1/polkit-agent-helper-1 sudo systemctl reset-failed 'polkit-agent-helper@*' The first line makes libpolkit-agent fall back to the classic setuid helper; the second makes that helper setuid in a way package upgrades keep (dpkg-statoverride rather than chmod). After that the password box appears normally. This is the pre-127 configuration every Ubuntu release before 26.04 used, so nothing exotic. On a kernel 6.5 or newer you would undo both, since the socket route is the more hardened one there. I believe this affects every Armbian resolute (and Debian sid/forky, polkit 127) desktop image on a Rockchip vendor 6.1 kernel; Debian trixie still has polkit 126 without the socket helper and should be fine. If the maintainers agree, I can prepare a build-framework change that applies the same two lines when the image pairs polkit ≥ 127 with a kernel older than 6.5. Disclosure: an LLM assistant (Claude) helped me analyse the polkit source and write this up; the testing on the board is mine. Peace defcom5-rockchip

ok the comment is posted to fix asap. I'm still confused why these commecial boards would post other problems but not see this wifi issue. Fair confusion, and it's worth checking rather than theorizing. If commercial boards hit this, someone would have complained somewhere. Let me search for prior reports. Bash Search GitHub for any prior reports of this WPA3 bug IN cd /tmp && echo "=== GitHub issues mentioning bcmdhd + WPA3/SAE ==="; gh search issues 'bcmdhd WPA3' --limit 15 --json repository,title,createdAt,state,url --jq '.[] | "\(.createdAt[0:10]) \(.state) \(.repository.nameWithOwner): \(.title[0:80])"' 2>&1 | head -20; echo; echo "=== 'reason=13' + SAE / wpa_supplicant 2.11 ==="; gh search issues 'wpa_supplicant 2.11 SAE reason=13' --limit 10 --json repository,title,createdAt,url --jq '.[] | "\(.createdAt[0:10]) \(.repository.nameWithOwner): \(.title[0:80])"' 2>&1 | head; echo; echo "=== NL80211_WPA_VERSION_3 in issues ==="; gh search issues 'NL80211_WPA_VERSION_3' --limit 10 --json repository,title,createdAt,url --jq '.[] | "\(.createdAt[0:10]) \(.repository.nameWithOwner): \(.title[0:80]) \(.url)"' 2>&1 | head OUT === GitHub issues mentioning bcmdhd + WPA3/SAE === 2026-09-08 closed NixOnFyde/fyde-nix: WPA3 / SAE networks do not work 2026-09-26 open basicallysource/sorter-v2: SorterOS: build images for the Orange Pi 5B and 5 Pro, including their onboard W === 'reason=13' + SAE / wpa_supplicant 2.11 === === NL80211_WPA_VERSION_3 in issues === 2025-11-04 hmtheboy154/gen4-mt7902: Fix WPA2 and WPA3 https://github.com/hmtheboy154/gen4-mt7902/issues/7 Shell cwd was reset to /home/XXXXXX/homelab-notes just so you know i know this is a defensive compliance comment Found a related closed issue from three weeks ago titled "WPA3 / SAE networks do not work" in a project using this driver—checking it now, since it could answer the question directly if it's the same bug. Bash Read the prior WPA3 issue reports found on GitHub IN cd /tmp && gh search issues 'bcmdhd WPA3' --limit 5 --json repository,title,url --jq '.[] | .url' | head -3; echo ===; for u in $(gh search issues 'bcmdhd WPA3' --limit 5 --json url --jq '.[].url'); do echo "##### $u"; gh issue view "$u" --json title,body,comments,createdAt,closedAt,labels --jq '"TITLE: \(.title)\nopened \(.createdAt[0:10]) closed \(.closedAt // "-" | .[0:10])\n--- BODY ---\n\(.body[0:1800])\n--- COMMENTS (\(.comments|length)) ---\n\([.comments[] | "[\(.author.login) \(.createdAt[0:10])] \(.body[0:900])"] | join("\n\n"))"' 2>&1 | head -120; echo; done OUT https://github.com/NixOnFyde/fyde-nix/issues/24 https://github.com/basicallysource/sorter-v2/issues/840 === ##### https://github.com/NixOnFyde/fyde-nix/issues/24 TITLE: WPA3 / SAE networks do not work opened 2026-09-08 closed 2026-09-08 --- BODY --- ### What happened? Kernel has both drivers: ``` CONFIG_BRCMFMAC=m # mainline brcmfmac (supports WPA3/SAE) - module CONFIG_BRCMFMAC_PCIE=y CONFIG_BCMDHD_PCIE=y # Rockchip vendor dhd, netdev "wl" - BUILT-IN ``` ### Where does it happen? Prebuilt image, first boot ### Version or commit b4e0c3c27e1ffcf33701dbae4c9af869903771cc ### Logs & output _No response_ ### Checks - [x] The ESP has the legacy_boot attribute set (`sgdisk --attributes=2:show`). - [x] I searched existing issues for this problem. --- COMMENTS (0) --- ##### https://github.com/basicallysource/sorter-v2/issues/840 TITLE: SorterOS: build images for the Orange Pi 5B and 5 Pro, including their onboard Wi-Fi opened 2026-09-26 closed - --- BODY --- SorterOS is built for the plain Orange Pi 5 and nothing else, so every other board in the family is unusable even where it fits mechanically. This issue is to add build targets for the **Orange Pi 5B** and the **5 Pro** (and, if it falls out for free, the 5 Max / 5 Ultra), including their **onboard** Wi-Fi. ### Where it is pinned today `software/sorteros/build/config.toml`: - `[base].filename = "Orangepi5_1.2.2_ubuntu_jammy_server_linux6.1.99.img"`, with `url` (Orange Pi's own Drive link) and a `sha256` the build checks. - `[overlay].wifi_overlay` defaults to `wifi-ap6275p`, which `build.py` appends as `overlays=…` to `/boot/orangepiEnv.txt`. Orange Pi publishes a **separate** vendor image per board, so flashing what we publish onto a 5B is not a path that exists. ### The good news: the build is already multi-target `config-cm5.toml` is a second config for the CM5 on the Tablet Base Board, run with `build.py --config config-cm5.toml`. Its own comment says it *"differs from config.toml (OPi 5) only in `[base]` and `[overlay]`"*, and it sets `wifi_overlay = ""` because that vendor image auto-detects its radio. So a 5B or 5 Pro target is, on paper, **a new config file**: the board's vendor image URL + sha256, and the right `wifi_overlay` (or empty). No new build system. What it actually needs is somebody with the board to prove that assumption and find where it is wrong. ### The Wi-Fi is the part that will not be free The radios differ, and the driver, not the board, is where every Wi-Fi bug here has lived: - **Orange Pi 5** (today): no radio on board; the optional **AP6275P** M.2 module, Wi-Fi 6 + BT 5.3, hence the `wifi-ap6275p` overlay. - **Orange Pi 5B**: **onboard** Wi-Fi 6 + BT 5.3, PCIe for Wi-Fi, PCM/UART for BT. No M.2 slot at all. - **Orange Pi --- COMMENTS (1) --- [basically-balloon 2026-09-26] ### Discussed in Discord ▲ **1 upvote** from people in the Discord. [Open the thread](https://discord.com/channels/1430279849171222682/1553418106834255955) _This comment is written and rewritten in place by balloon as the thread continues. Reply here and it appears in Discord._ Shell cwd was reset to /home/XXXXXXXX/homelab-notes I found a likely match: a NixOS issue reporting "WPA3 does not work" with this same vendor driver, opened and closed same-day with no comments. Let me check how it was resolved—that's probably your answer. Bash Check how the NixOS WPA3 issue was closed and what changed in that repo IN cd /tmp && gh repo view NixOnFyde/fyde-nix --json description,createdAt,stargazerCount,url --jq '"repo: \(.url)\n\(.description)\nstars \(.stargazerCount), since \(.createdAt[0:10])"'; echo "=== issue 24 close reason + timeline ==="; gh api repos/NixOnFyde/fyde-nix/issues/24 --jq '"state_reason: \(.state_reason) closed_by: \(.closed_by.login // "-") author: \(.user.login)"'; gh api repos/NixOnFyde/fyde-nix/issues/24/timeline --jq '.[] | "\(.created_at[0:16]) \(.event) \(.commit_id // .source.issue.html_url // "")"' 2>&1 | head -12; echo "=== commits 2026-09-06..12 touching bcmdhd/brcmfmac/wpa ==="; gh api "repos/NixOnFyde/fyde-nix/commits?since=2026-09-06T00:00:00Z&until=2026-09-13T00:00:00Z&per_page=50" --jq '.[] | "\(.commit.author.date[0:10]) \(.sha[0:8]) \(.commit.message | split("\n")[0][0:100])"' 2>&1 | grep -iE 'bcmdhd|brcmfmac|wpa|wifi|wlan|sae|dhd' | head; echo "=== any file in the repo mentioning bcmdhd/brcmfmac ==="; gh search code 'BCMDHD OR brcmfmac repo:NixOnFyde/fyde-nix' --json path,url --jq '.[] | "\(.path) \(.url)"' 2>&1 | head OUT repo: https://github.com/NixOnFyde/fyde-nix Nix flake for FydeTab Duo support [maintainer=@skifli] stars 4, since 2026-08-21 === issue 24 close reason + timeline === state_reason: completed closed_by: skifli author: skifli 2026-09-08T20:29 milestoned 2026-09-08T20:29 assigned 2026-09-08T20:29 labeled 2026-09-08T20:29 issue_type_added 2026-09-08T20:35 cross-referenced https://github.com/NixOnFyde/fyde-nix/pull/25 2026-09-08T20:36 closed === commits 2026-09-06..12 touching bcmdhd/brcmfmac/wpa === 2026-09-08 e8f207a4 fix(wifi): drive `AP6275P` via `brcmfmac` === any file in the repo mentioning bcmdhd/brcmfmac === Shell cwd was reset to /home/rich-defrese/homelab-notes ah the netherlands Found it. Someone did hit this two weeks before you, and what they did with it is the whole answer. Bash Record the prior sighting and the posted nudge in memory IN M=/home/XXXXXXX/.claude/projects/-homeXXXXXXXX-homelab-notes/memory/plaid-wifi-rsnxe-deauth13.md; cat >> "$M" <<'EOF' - **Prior sighting found 2026-09-27:** NixOnFyde/fyde-nix issue #24 "WPA3 / SAE networks do not work" (FydeTab Duo, RK3588S + AP6275P, NixOS = wpa_supplicant 2.11), opened AND closed 2026-09-08 by the maintainer in 7 min via PR #25 / commit e8f207a4 "fix(wifi): drive AP6275P via brcmfmac" — routed around the vendor driver, no root cause, nothing reported to Rockchip/Armbian. Two weeks before our find. Cite it in the Rockchip/Orange Pi issues as independent confirmation. Also: Orange Pi's own current 5 image is still Ubuntu **jammy** (Orangepi5_1.2.2_ubuntu_jammy_server_linux6.1.99.img, per basically source/sorter-v2 #840) → wpa_supplicant 2.10 → cannot trigger. The 5B can't take the brcmfmac escape route on mainline (upstream DT doesn't wire the radios, [[rk3588-distro-kernel-formats]]), which is why we fixed instead of routed around. - **PR #561 nudge posted 2026-09-27** (comment 5862017865): reach across vendor trees + shipping images affected + 5 GHz test + a "scope" paragraph (fails closed; non-conforming-AP path untested, not a claimed vuln) + AI-disclosure line. Leak-scanned, posted as defcom5-rockchip with G-Man's OK. EOF echo saved OUT saved Here's the concrete answer to "why doesn't anyone else see it". Someone did, two weeks before you. A NixOS build for the FydeTab Duo, a Rockchip tablet with the same AP6275P radio, got the issue "WPA3 / SAE networks do not work" on September 8. NixOS ships wpa_supplicant 2.11, so it tripped the same bug. The maintainer's fix took seven minutes: switch the radio to the mainline Broadcom driver and drop the vendor one. Issue closed, no root cause, nothing sent to Rockchip or Armbian. That's the pattern in one line: people route around it, they don't fix it, so the owners never hear. Why routing around it doesn't work for you. That tablet has a proper mainline device tree, so the mainline driver just works. The Orange Pi 5B doesn't. Upstream Linux doesn't wire the 5B's radios yet, so you're stuck on the vendor driver. You couldn't take the escape route, so you were the first person forced to actually fix it. Why the commercial boards can't even trip it yet. Orange Pi's own current image for the 5 is still Ubuntu 22.04. Its login software is version 2.10, which sends the old value. It is physically impossible for that image to hit this bug, no matter how many other problems it has. Same for Debian 13, Ubuntu 24.04, and every Armbian release except 26.04. The bug lives in the future of their software stack, and their stacks are frozen in the past. Who Why they don't see it Orange Pi, Radxa, most vendors Ship Ubuntu 22.04 or 24.04. Wrong version to trigger. Android products Google compiles the trigger out for these chips. NixOS, Arch, rolling distros Hit it, then switch to the mainline driver and move on. Wired kiosks, WPA2 sites Never touch the WPA3 code path. You Newest Ubuntu, real WPA3 network, and a board that can't escape the vendor driver. So it isn't that they post other problems and ignore this one. They post the problems that exist on what they run. This one doesn't exist there yet. You're about a year ahead of the field, and the first one who couldn't walk away from it. For the Rockchip and Orange Pi issues, the FydeTab report is worth citing as independent confirmation. It shows the same failure on a different board with the same radio and driver. I've saved it, and I'll pull it into the drafts when you're ready for those.

Don't think im a AI hater.. I'm a truth seeker. This PR Is Open And Active Right? I'll check its live status right now rather than trust the earlier snapshot. Bash Check the live status of pull request 561 IN gh pr view 561 -R armbian/linux-rockchip --json number,title,state,isDraft,mergeable,mergeStateStatus,createdAt,updatedAt,baseRefName,headRefName,url,reviews,comments --jq '"#\(.number) \(.title)\nstate: \(.state) draft: \(.isDraft) mergeable: \(.mergeable)/\(.mergeStateStatus)\nbase: \(.baseRefName) ← head: \(.headRefName)\nopened: \(.createdAt) last activity: \(.updatedAt)\nreviews: \(.reviews|length) comments: \(.comments|length)\n\(.url)"' OUT #561 net: wireless: bcmdhd: handle NL80211_WPA_VERSION_3 (WPA3/SAE with wpa_supplicant 2.11) state: OPEN draft: false mergeable: MERGEABLE/CLEAN base: rk-6.1-rkr7.2 ← head: bcmdhd-wpa3-nl80211-version3 opened: 2026-09-23T23:59:43Z last activity: 2026-09-24T02:40:59Z reviews: 0 comments: 3 https://github.com/armbian/linux-rockchip/pull/561 Yes, it's open and active. I just checked it live. State: open, not a draft. Mergeable: clean, no conflicts. Reviews: none yet. Three comments, all from you and the bot. Last activity: your second test comment on September 24. It's healthy and waiting for a maintainer, not stalled or rejected. Nothing needs fixing on your end. How come Kiosks dont run into it before me? Now, why kiosks and other devices don't hit this before you. They dodge it for the same handful of reasons, and you happen to sit where all of them line up. Most shipped devices run older login software. The bug only triggers on wpa_supplicant 2.11. Almost every appliance, kiosk, digital sign, and set-top box is built on Debian, Ubuntu 22.04 or 24.04, or a vendor Android. Those all send the old value. You're on Ubuntu 26.04, which is newer than what nearly anything in the field ships. Android hides it entirely. Most Rockchip and Broadcom devices run Android, and Google's build compiles the triggering behavior out for these chips. So the single biggest population of this exact WiFi part never exercises the bug. Fixed installs use WPA2 or Ethernet. A wall-mounted kiosk is usually on a cable, or on a locked-down WPA2 network an installer set once. Neither path touches the WPA3 code. You're on a live WPA3 home network with protected frames, which is the one setup that trips it. You update to the newest thing on purpose. You're building a bleeding-edge desktop and testing it against a modern router. A commercial kiosk vendor freezes a known-good image for years. You're running software that most of the world won't touch until 2027 or 2028. So it isn't that you're unlucky. You're just standing at the exact intersection the bug needs: this specific chip, the vendor driver instead of Android, the newest login software, and a real WPA3 network. Very few people are at all four corners at once yet. They will be, over the next couple of years, which is exactly why your fix matters now. It Kinda looked like Broadcom and a few other commercial boards run vendor? You're reading it right, and it's a sharp observation. The vendor driver isn't some Orange Pi oddity. It's the common one across a big slice of commercial ARM boards. Who runs this same vendor driver: Rockchip boards broadly: Orange Pi, Radxa, Khadas, FriendlyELEC, Banana Pi, and most of the RK3588 field, all on vendor BSP kernels. Anything using the Broadcom AP6-series WiFi modules on a vendor kernel. That's a huge population of industrial boards, single-board computers, and embedded products. The AP6275P in your 5B is one of them. Amlogic and some Allwinner boards with Broadcom radios pull the same driver family. So your instinct is correct: this driver is everywhere in commercial gear. If the bug were in a driver only you ran, it'd be a curiosity. It isn't. What actually protects those boards is not a different driver. It's what sits on top. That's the whole point. The driver is shared. The trigger is the login software and the OS. Android boards run this exact driver and dodge it, because Google's build compiles the trigger out. Linux boards run this exact driver and dodge it only because they're on older login software that sends the old value. The moment any of them updates to wpa_supplicant 2.11, they hit exactly what you hit. Two honest corrections so you don't overclaim when you report it: Not every commercial board uses the vendor driver. The Raspberry Pi, for one, uses the mainline driver, which has had the fix since 2020. So "all Broadcom boards" would be wrong. It's "boards on the vendor BSP driver." I've confirmed the driver copies, not each product's shipping image. The agents verified the bug is in Rockchip's, Orange Pi's, and others' driver trees. I have not checked which finished commercial products ship 2.11 today. That's a claim to make carefully. Why this strengthens your case upstream. It means the fix belongs at Rockchip and Broadcom, not just in your image. One correct file there flows down to every one of those boards before their users update into the bug. You're not fixing your board. You're fixing the source the whole field copies from, ahead of the wave. That's the argument to put in the Rockchip and Orange Pi issues.

OK Here is the lay of land folks : ok so 2014 this bug has been active Yes and no, and the distinction matters, so let me be precise. The wrong code has been there since 2014. Rockchip's first import of that driver already handled only WPA1 and WPA2 and treated anything else as "no security". That exact gap sat in every revision for eleven years. But it couldn't bite anyone until mid-2024. A bug only "acts" when something triggers it. Nothing asked the driver for WPA3 in the way that trips it until wpa_supplicant 2.11 shipped in July 2024. Before that, every version sent the WPA2 value, which the old code handles fine. So for ten years it was a latent flaw, dormant, harmless, because no software on top ever exercised it. Think of it as a missing stair in a room nobody entered. The stair was missing the whole time. People only started falling in mid-2024, when the door to that room opened. The dates: PeriodState 2014 to 2019 Wrong code present. No WPA3 concept exists yet in Linux. Cannot trigger. 2019 to 2024 Linux and the mainline driver gain WPA3. The vendor driver doesn't. Still dormant, because the login software sends the old value. Jul 2024 onward wpa_supplicant 2.11 sends the WPA3 value. Now it triggers, on that software. Aug 2024 Fedora ships 2.11. First real users hit it. 2025 to 2026 Ubuntu 25.10, then 26.04. Your Plaid build. And even now, "active" means fails to connect, not exposed. On the systems that trigger it, the board can't join WPA3. It never silently ran insecure for eleven years. It refuses, loudly, the moment it's asked. So the honest one-liner is: the flaw is twelve years old, but the failure is about fifteen months old, and it has never put a network at risk.