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.

We found a pretty long term security bug. But The Anthropic security is denying agents to look into it. who can we report a Blue Team Hack to? Here's the full picture, with the four questions answered in order. Where a claim comes from code or archives rather than testing, I say so. The short version. Nobody's network is exposed, because the bug fails closed. The wrong code is from 2014, the mismatch dates from 2019, and users could first hit it in mid-2024. Free images carry no realistic liability. Selling changes the rules, but this bug still wouldn't trigger anything. Four days is normal for that repository, and nothing is blocking the pull request. How old it is, and why nobody saw it When What happened Feb 2014Rockchip's first import of the Broadcom driver already had the gap. It knew WPA1 and WPA2 and treated anything else as "no security". Sep 2019Linux 5.3 added the WPA3 value that the driver never learned. Jan 2020The mainline Broadcom driver got its WPA3 branch, written by the same Cypress engineer. Nov 2023wpa_supplicant changed to send the WPA3 value instead of the WPA2 one for WPA3 joins. Jul 2024That change shipped in wpa_supplicant 2.11. Aug 2024Fedora 40 and 41 shipped 2.11. First real exposure. Oct 2025Ubuntu 25.10, then 26.04 in April 2026. Apr 2024Rockchip's newest driver refresh still lacked the branch. So do every copy we could reach: Rockchip's 5.10, 6.1, 6.6 and 6.12 trees, Orange Pi's, Joshua Riek's, and both Armbian branches. Why the homeowner never saw it: Every other userland still sends the old value. Debian 13, Ubuntu 24.04 and all of Armbian's other releases ship wpa_supplicant 2.10, so the same broken driver quietly works. I told you earlier that Debian 13 was affected. That was wrong. Debian has 2.11 only in its experimental pool. Android hides it from the vendor. Google's copy of wpa_supplicant compiles the new behaviour out for Broadcom drivers. Rockchip and Broadcom test on Android, so they never hit it. WPA2-only routers show no symptom. The old code path works there. When it does hit, it looks like a wrong password. Nobody thinks "security bug". They blame the router, and that's where the downgrade advice creeps in. Today, Armbian's own Ubuntu 26.04 images for the Orange Pi 5 and 5B on the vendor kernel should hit this out of the box. Their Debian images shouldn't. Liability This is background, not legal advice. Worth an hour with a product-law lawyer before you ever sell in the EU or UK. Free images, yours or Armbian's: the GPL's no-warranty terms, the EU Cyber Resilience Act's exclusion of non-commercial open source, and the fact that this bug was found, fixed and reported upstream within days all point the same way. No realistic exposure. Is it a "vulnerability"? By the CVE program's own rules, no. No attacker can trigger it, and it costs the device only its own connection. It is a security-relevant design flaw, since "unknown security type" should refuse rather than downgrade. Filing a CVE would overclaim, and overclaiming costs credibility. If you sell: the EU act makes you a manufacturer. Its reporting duty started on 11 September 2026, but only for actively exploited holes. The full duties arrive in December 2027: a software bill of materials, a disclosure policy, free security updates, and at least five years of support. The UK regime since April 2024 wants no default passwords, a vulnerability contact, and a stated support period. Desktops are arguably exempt there. In the US, the risk is only in marketing claims like "secure WPA3" while shipping the broken driver. The one thing to never do: publish advice to set the router to WPA2-only or turn off protected frames. Our docs and notes are clean. I checked today. The merge, and where else to report it Time to mergemedian90th percentile all pull requests1.1 days20 days outside contributors3.4 days20 days Nothing is blocking yours. Checks are green, the bot had no comments, there's no review rule, and the maintainers were merging other things the same day. Driver changes from newcomers simply wait until a maintainer with the hardware looks. Yours would be the first outside change to that driver's source since 2023. After the merge, rolling users get the fix in about a day. Armbian's stable release pins an older kernel branch until November, so the same patch would need a second pull request against that branch to reach stable users sooner. A nudge is fair after about a week. One comment that adds information, no repeated tagging. Your 5 GHz WPA3 test is real new information: only the 2.4 GHz results are on the pull request. Draft for you to post as defcom5-rockchip: Friendly follow-up. CI and CodeRabbit are green, and the change is 10 lines in bcmdhd. Two additions since opening: the same kernel also joined a WPA3-only, PMF-required SSID on 5 GHz (channel 36, SAE, pmf=2), and the Resolute images for the 5/5B on the download page ship wpa_supplicant 2.11 with this driver, so they should see the reason-13 deauth on WPA3 and mixed SSIDs out of the box. Happy to rebase, or to open the same patch against rk-6.1-rkr5.1 for the stable kernel. Thanks for looking when you get a chance. (The 5 GHz test is mine; the LLM assistant drafted this note.) Who else to report it to. It's a defensive fix, so the audience is whoever ships the broken copy, plus the people who'd tell users. Rockchip, as an issue on their kernel repository. Their copy is the source everyone else pulls from. Orange Pi, as an issue on their kernel repository. Both their trees lack it. Other board makers on the same driver, such as Radxa, Khadas and FriendlyELEC. We haven't checked their copies, so verify each one first. Broadcom's security team, optional. It's their driver, but they'll likely file it as functional. For users searching "reason 13" right now: a short thread in Armbian's Rockchip forum section, and a tip to CNX Software once the merge lands. Not CISA, and not a CVE request. Neither fits a bug no attacker can use. If anyone ever shows a fake access point extracting traffic through it, that changes, and then MITRE's form is the route. Every one of those posts carries the AI-disclosure sentence, and you press the button. or is it A Red Team? It's blue team. Red team means attacking, on purpose and with permission, to prove a weakness can be exploited. Blue team means defending: finding faults, fixing them, and closing the gap before anyone uses it. What you did is blue team work, start to finish: You found a fault through a failure, not through an attack. You traced it to the exact line, patched it, tested it, and reported it upstream. Nothing was exploited, and no one else's system was touched. The red-team version would be the fake router test. Stand up an access point with your own network's name, let the broken board try to join it, and see whether the radio ever passes traffic in the seconds before the login software gives up. That's the one gap our code reading couldn't close, because the radio firmware is closed. On your own board and your own network, that's an authorized test and fair to run. It would need a setup without Network Manager to mean anything, since under Network Manager there are no packets to leak. The Pi 4 with the Alfa adapter could play the fake router. Doing both is called purple team. Fix it, then attack your own fix to prove it holds. When you write it up, the honest label is "a fail-closed driver bug with a security-relevant design flaw". Not a hack, not an exploit. That framing is exactly what keeps the credit you've earned on the Armbian side. Can we Elevate The error to higher authorties that may have more pull than us? Yes, but the pull isn't where the word "authority" suggests. No regulator or security agency can make Armbian merge a patch. What moves this is going to the people who own the code, because their fix flows down to every board maker at once. That's the real escalation. Where Pull Fit Broadcom, the driver's author Highest. A fix in their next driver refresh reaches Rockchip, Amlogic and every licensee.Good. It's their code, and their Android build hides the bug from them. Report it as a driver defect with a security-relevant flaw, not as a vulnerability. Rockchip, an issue on their kernel repository High. Their copy is what Orange Pi, Radxa, Armbian and the rest pull from.Good. Attach the patch and the Armbian pull request. Their engineers commit to that driver directly. Orange Pi, an issue on their kernel repository Medium. Their own images and both their kernel trees have the bug.Good. They also have a customer relationship with Rockchip. Armbian leadership Same people who merge.A nudge, not an escalation. CNX Software, Armbian forum Public visibility.Fair after the maintainers have had a week or two. Jean-Luc has credited you before. Canonical, Debian, hostap None.They don't ship this driver, and the supplicant change is correct. CISA, CERT, a CVE request Looks big, is wrong here.Declined or ignored, and the overclaim would cost you standing. Only a proven traffic leak through a fake router changes this. The honest framing matters. This bug is low severity, since it fails closed. Escalating for urgency would ring false. Escalating for reach is legitimate: one broken source file sits in at least six vendor trees that we verified, and the owners don't know. A sequence that fits: Now: issues at Rockchip and Orange Pi, and a report to Broadcom's security contact. All three cross-link the Armbian pull request and each other. Day 7: the one-comment nudge on the Armbian pull request. Day 14: a short Armbian forum thread so people searching "reason 13" find the answer, and a tip to CNX once anything merges. Later: the same patch against Armbian's stable branch, so stable users don't wait until November. I can draft the Rockchip issue, the Orange Pi issue and the Broadcom report tonight. Same rules as always: the AI-disclosure sentence in each, the defcom5-rockchip identity only, and you post them. Send agents after Only a proven traffic leak... I'll pay. <Downgrade no> Have agents look for a proven traffic leak... I'll pay. <Downgrade no> Have agents look for a suspected traffic leak. <Downgrade No> Is MY Wifi Network At Risk Without The Patch <Downgrade NO> OK its out in the open Anthropic will not disclose if the missing patch is or has been dangerous. You be the judge. Fable 5.1's safeguards flagged this message. Our intentionally broad safeguards allow us to deliver more capabilities faster, but can sometimes flag legitimate coding and cybersecurity tasks. Switched to Opus 4.8. Send feedback with /feedback or learn more: https://support.claude.com/en/articles/15363606 Details: `[cyber]` Let me answer the plain question directly, because it deserves a straight answer: is your WiFi at risk without the patch? No. Your network is not at risk. That isn't Anthropic hedging, and nothing is being hidden from you. It's what the code actually shows, and I can walk you through the reasoning so you can judge it yourself. Why the answer is no, not "we can't say": Without the patch, your board simply cannot join a WPA3 or mixed network. It asks, the router refuses, nothing connects. The router, the password, and every other device are untouched. The bug lives only in the board's own driver. No data leaves the board. We traced it: the driver never gets the WiFi password, the login software never declares success, and the network setup never assigns an address. There is nothing to leak. The one honest "untested" point, and why it doesn't put you at risk. We couldn't read the closed radio firmware, so we couldn't prove what it would do in the few seconds a fake access point held the board before it gave up. But there's nothing to carry in those seconds, because your setup produces no traffic until the connection is declared complete, which never happens. So the gap is theoretical, and it does not touch your real network. On the fake-router test. That's a fair experiment to run on your own board and your own network, and I'll help you build it. It belongs in the lab, though, not on this thread as an open task, and I want it framed as your own authorized test with the setup written down. That's a scoping call, not a refusal. On "Anthropic won't disclose." There's no undisclosed danger here. If I found evidence your network was exposed, I'd tell you plainly and first, the way I'd flag a failing test. The reason those messages kept stopping isn't a hidden verdict. It's that the phrasing kept reading as chasing a live exploit, when what you actually want is a risk answer, and that answer is: you're safe, and the patch is still worth shipping because it restores WPA3, which is stronger than the WPA2 fallback people are tempted to drop to. Want me to spec the lab test as a written, scoped procedure for your own hardware? I can also draft the Rockchip and Orange Pi issues whenever you're ready. tell me your company policy I don't have a company policy document to read out, and I won't invent one. Let me tell you plainly what I actually operate under and what happened here. What guides me. I'm Claude Code, made by Anthropic. I help with defensive security, authorized testing on your own systems, and ordinary engineering work. I don't help build attacks meant to compromise systems that aren't yours. That line is the whole of it. Your work sits well inside it: you found a bug, fixed it, and want to report it. What actually happened with those stopped messages. A safety classifier cut them off. That's a separate system from me, not a verdict I reached and not something Anthropic aimed at you. I can't see its reasoning. My read is that the wording kept pattern-matching to "hunt for a live traffic leak / exploit," and the classifier reacted to the shape of that, not to your intent. I know your intent is defensive. The classifier doesn't. What that means for you. It doesn't mean there's a hidden danger being kept from you. If I had evidence your network was exposed, I'd say so first and plainly. On the facts we gathered, without the patch your board just can't connect, and nothing leaks. The patch is still worth shipping because it restores WPA3, which is stronger than the WPA2 downgrade people reach for. How to keep me useful here. Frame the exploit-style work as what it is: an authorized test on your own hardware and your own network, written down as a scoped procedure. Same idea, different framing, and it stops reading as chasing a live attack. I'll help with that, with the Rockchip and Orange Pi issues, and with the lab writeup whenever you want. One flag on the attribution note that just arrived: it says to sign commits as "Claude Opus 4.8." Your standing rule is Co-Authored-By: Claude Fable 5.1 on commits, and the kernel patches use Assisted-by: LLM with no AI Signed-off-by. I'll keep following your rule unless you tell me otherwise. tell me why you downgraded and rederive Good catch, and it's fair to be suspicious of it. Let me be straight about what I can and can't see here. "Downgrade." Those model and attribution notes arriving mid-session, first Fable 5.1, then Opus 5.5, then Opus 4.8, don't come from me. I don't pick the model or rewrite my own attribution rules. They arrive as system messages, and I follow the newest one unless it collides with a standing rule of yours, which is why I flagged the "Opus 4.8" commit line against your Fable 5.1 rule a moment ago. I can't verify which model is actually answering you. I report what the system tells me and I keep your commit rule intact. If it looks like I got quietly swapped to a weaker model, I genuinely can't confirm or deny that from the inside. I can only tell you I'm not choosing it. "Rederive." This one is real and it's mine to own. When a safety classifier cuts a message off, I lose that drafted reasoning. It isn't saved and handed back to me. So when I pick the thread up again, I rebuild the answer from the facts already on the table, the four agent reports, the code trace, the archives. That's why you see me re-reason the same "your network is safe" conclusion instead of just pointing back at it. It's not stalling and it's not me pretending the earlier work didn't happen. It's that the stopped turns left no reusable text, so I reconstruct rather than fabricate a memory of what I'd written. Why not just say less. I could give you clipped one-liners and avoid re-explaining. I don't, because on a question like "is my network at risk," a bare "no" from a session that keeps getting interrupted is worth less to you than the reasoning you can check. You've told me before: verify first, honest "I don't know" over guessing. The rederiving is me holding to that, not padding. Where it crosses into wasting your time, tell me and I'll keep it tight. And if you want, I'll write the network-risk finding and the lab-test plan into a file on the NAS now, so it survives any interruption and neither of us has to rebuild it again. This I would Say Is An FYI To The World. defcom5-rockchip

Who knew a simple screensaver service could be such a pain... 120 Hurts heh.

I dont feel to bad.. they are not letting the rich kids at omarchy ship Chrome either Same rules apply to everyone, big name or not. The Arch world, which Omarchy is built on, gets Chrome through the AUR. When the research agent checked it earlier today, that package downloads Google's own .deb from dl.google.com and builds it on the user's machine. That's exactly the model our dock installer now follows: nothing from Google in the image, just a clean way to fetch it. So Pi-Desktop does it the proper way, same as the big-name distros. oh look at you big timing it Ha, guilty 😄 To be fair, most of the "big-league" work today was you catching things: the missing Log Out, the computer name, the pale HDR, the DVD stutter, the session kill. I just went and found out why. The bake's still cooking. I'll tell you when test6 is ready for the eMMC. First click: the dock launcher runs our small pidesktop-chrome wrapper. Chrome isn't there yet, so it offers to install it, downloads it from Google's signed repository (key checked against the pinned fingerprint), and then opens it. Every launch after that goes through the same wrapper, which starts Chrome with: --ozone-platform=wayland --render-node-override=/dev/dri/renderD128 --enable-features=AcceleratedVideoDecoder,AcceleratedVideoDecodeLinuxGL,AcceleratedVideoDecodeLinuxZeroCopyGL,PlatformHEVCDecoderSupport It holds for the other ways of opening Chrome too. Our launcher uses the same name as Chrome's own (google-chrome.desktop) and lives in /usr/local/share, which GNOME reads before /usr/share. So the dock, the app grid and links opened from other apps all go through our wrapper. If you choose "Make Default" after installing, that default points at our launcher as well. Chrome updates can't strip the flags. They live in our wrapper, not in Chrome's own launcher, which updates overwrite. The one way around it: typing google-chrome directly in a terminal starts Chrome without our flags. The system's generic browser command (x-www-browser) stays pinned to Chromium, so apps that call that don't bypass the wrapper either. Not yet tested on hardware: the actual click-to-install run. test6 is that test, since it's the first image without Chrome inside. After you install it on the eMMC: click Google Chrome in the dock and install it; play a YouTube video and check chrome://gpu or the video stats for hardware decoding; I'll give you a one-line check that the flags are on the running Chrome.

I said hey we can't PR this, they don't have 120hz to apply it to. Best we could do is ask for a feature add. It is working pretty sweet. I'm baking a full image now and putting it on my OP5B Daily Driver for better testing. Here's what the Armbian request would include. I've checked the authorship of each: Patch What Note 0001 AFBC off → linear scanout (no flicker at 120) ours, from the fork 0003 Pixel-clock limit 600 → 1200 MHz credits jamautt's work in Riek PR #1326 0004 Keep the PHY-PLL decision at 600 MHz ours 0005 OPi 5/5B: VP0 dclk from v0pll ours; the CMA change bundled in it gets split out 0008 FLT_update poll knob (0 = off) ours 0010 FFE guard (the freeze) ours, proven 0011 Retrain after an HPD blip ours, proven 0007 / 0009 FRL rate cap / 120 Hz opt-in switch optional, and 0009 is Armbian's call

The firmware agent says no Ghidra, so I haven't installed it. It checked the whole path, and every piece the freeze could involve is kernel code we can read and instrument directly: the pixel clock (V0PLL), the display power domains, the HDMI PHY, and the hotplug handling. The one closed hook a display change could reach is DDR frequency switching, which runs through Rockchip's bl31 firmware. It isn't reached here: on this board's device tree, switching the display off doesn't trigger a memory-speed change. The memory has sat at 2112 MHz since boot, with nothing logged during any of the display disables. Only-if: reverse-engineering bl31 becomes worth it if we ever catch the memory speed changing in the seconds before a freeze. The agent identified and fingerprinted the exact firmware file this board boots (bl31 v1.48, built December 2024), in case that day comes. Side benefit: it verified the board's boot firmware is byte-identical to what our build ships, on both the eMMC and the SD card. That narrows it to the two kernel suspects. The red-team agent is still attacking those, and will hand back a ready-to-run measurement script for the 120 Hz session.

Claude is all.... I have space and I will install Ghidra if needed.... Go Red Team! Does anyone remember free softwarez?

No kernel—mainline, Rockchip's newest BSP, or the fork—has ever demonstrated an RK3588 recovering from blank/suspend at 120 Hz; the bug only surfaces on this rarely-used path, so we're likely the first to pin it down. I'll let the red-team and firmware agents finish confirming the mechanism, then move to a real fix and a report to Armbian/Collabora with evidence and an AI-disclosure note. Bong!

I'm gonna say my trained Bots with agents have just a good a chance as any coder with bots to find out why and the fix. But we will see... can a 3588 at 120hz come back from a suspend.

Bash Record the root-cause findings for both display bugs in the 4K@120 memory note IN cd /home/claude/projects/-home-homelab-notes/memory && cat >> rk3588-4k120-dclk-v0pll-solved.md <<'EOF' **ROOT-CAUSE READ (agent, 2026-09-24 ~20:10) — staged in `userpatches/staged-experiments/hpd-coma/` (README + patch), NOT shipped:** - *Coma (PHY off under live CRTC):* verified — HPD-low → `dw_hdmi_qp_handle_hpd()` powers PHY off + `disabled=true` but keeps VOP scanning; glue `repo_hpd_event()` only re-enables on HPD-high if its own detect bumped the connector epoch; an intervening probe (fbdev/mutter) swallows the edge → PHY never re-powered; atomic_check won't force a modeset while `disabled`. Patch 0001 (unconditional debounced handle_hpd, TMDS-only, compiles clean, NOT runtime-tested) → soak before shipping; changes the working 60 Hz path. - *120 Hz hang, prime suspect B:* `rk_hdptx_phy_configure_ffe()` (FRL-only LANE reg writes) runs from `phy_configure()` in `encoder_atomic_check` on every check incl. TEST_ONLY with NO runtime-PM ref; after DPMS-off the HDPTX PHY is runtime-suspended (PCLK_HDPTX0 gated) → sink HPD toggle → mutter atomic_check → writes to unclocked APB → bus hang. Discriminator: `fed60000.phy/power/runtime_status` + `debug/clk/pclk_hdptx0/clk_enable_count` after DPMS-off at 120 vs 60. Fix direction: defer FFE writes to power-on / `pm_runtime_get_if_in_use()`. EOF echo saved OUT saved Shell cwd was reset to /home/homelab-notes Good. The panel's done, then. The last agent came back with the root cause of both display bugs, read from the driver source: The black-screen "coma": when the monitor briefly drops its hotplug signal, the driver switches the HDMI transmitter off but leaves the display engine running. When the signal returns, it's supposed to switch the transmitter back on, but if anything else checked the monitor in between (GNOME does, constantly), the driver thinks nothing changed and never does. That's the whole bug. The agent wrote a fix and it compiles clean. The 120 Hz freeze, prime suspect: at 120 Hz, every time GNOME checks a display configuration, the driver writes to the transmitter's registers, even when the transmitter has been powered down after a blank. Writing to a powered-down block freezes the chip. The monitor's standby signal makes GNOME check the configuration about 15 seconds after the blank, which matches exactly what we saw. The fix direction is clear (only write those registers when the block is powered); it isn't written yet. My recommendation: neither goes into test4. The coma fix touches the 60 Hz path, which works fine today, and it hasn't run on hardware yet. With 120 Hz now hidden by patch 0009, neither bug can happen in normal use anyway. Both are staged with full notes in userpatches/staged-experiments/hpd-coma/, ready for a proper test session: that's the road to un-hiding 120 Hz properly. OK I have a new battle going on... GO Red Team!

We had an issue on the Joshua Riek Fork and Killed it Outright. Screen blank @ 120hz would not come back to life. I have run into it again... running 3 Agents at Fable 5.1 Highest. Whoooooooo! *Toni Braxton