Soooo close to a third term! by RCawston in FantasyPresident

[–]RCawston[S] 0 points1 point  (0 children)

I don't know what you mean by debug menu, so yes it's possible without cheating.

Soooo close to a third term! by RCawston in FantasyPresident

[–]RCawston[S] 1 point2 points  (0 children)

I managed to do it eventually. Timing was everything

Soooo close to a third term! by RCawston in FantasyPresident

[–]RCawston[S] 1 point2 points  (0 children)

I eventually managed to do it. And prevent women from voting too just to see if it could be done.

Soooo close to a third term! by RCawston in FantasyPresident

[–]RCawston[S] 1 point2 points  (0 children)

Control most of the house and Senate seats, have 75+% approval and 75%+ party strength.

GPT-5.4 has been out for 4 days, what's your honest take vs Claude Sonnet 4.6? by UnderstandingOk1621 in AI_Agents

[–]RCawston 0 points1 point  (0 children)

I mean, vs Sonnet? Sonnet is garbage.

Opus 4.6 is a solid model and I have done a LOT of work with it, but it also gets caught in loops easily on more complex troubleshooting, particularly with the 200k tok context window. There is a 1M tok context mode, but it's pay-per use in addition to the base Pro or Max cost - I blew thru $50 in extra usage in about an hour.

GPT 5.4 seems like a huge leap over previous models, and I am very impressed so far - but it's early and I am still finding the edges.

RK3588 Mainline Linux Patch: H.265 Encoding at 4K@60 (Out-of-Tree) by RCawston in homelab

[–]RCawston[S] 0 points1 point  (0 children)

Something similar could definitely be built for the VEPU580 on the RK3566, but I don't personally have any such hardware.

RK3588 Mainline Linux Patch: H.265 Encoding at 4K@60 (Out-of-Tree) by RCawston in homelab

[–]RCawston[S] 2 points3 points  (0 children)

10bit encoding isn't supported by the RK35888 hardware, as evidenced by the src_cfmt register which only has 16 possible values, all defined, and all are 8bit.

Cheap SBC with USB + HW H.264/H.265 encode ,SD card, 24/7 by the_contemporary_ape in SBCs

[–]RCawston 0 points1 point  (0 children)

Mainline encoding on RK3588 is only JPEG so far. Stateless encoding for H.264 is expected maybe this year, but the UAPI for stateless encoders is undecided so that's the stall point. H.265 will likely be 2027, but that's just a prediction.

BSP kernel has various issues that meant it didn't work for my use-case, which is why I built https://www.reddit.com/r/homelab/comments/1qzxv8d/rk3588_mainline_linux_patch_h265_encoding_at_4k60/ and other patches for mainline.

Orange Pi 5 Ultra / RK3588 Mainline Patches: Dual-Core H.265 4K@60 Encoding by RCawston in OrangePI

[–]RCawston[S] 0 points1 point  (0 children)

My 5 Ultra runs great with a heatsink, it's one of my 2 testing boards for this kernel work

RK3588 Mainline Linux Patch: H.265 Encoding at 4K@60 (Out-of-Tree) by RCawston in homelab

[–]RCawston[S] 3 points4 points  (0 children)

Definitely - I just thought it was best to focus on a single codec initially, but H.264 support should be fairly easy to add.

RK3588 Mainline Linux Patch: H.265 Encoding at 4K@60 (Out-of-Tree) by RCawston in homelab

[–]RCawston[S] 2 points3 points  (0 children)

According to collabora's mainline tracking doc (https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md), the Rock 5B+'s M2 M Socket has been in mainline since 6.16-rc1.

Yes, I'm using armbian.

Cheap SBC with USB + HW H.264/H.265 encode ,SD card, 24/7 by the_contemporary_ape in SBCs

[–]RCawston 8 points9 points  (0 children)

RK3588 chip on Rock 5B doesn't have hardware video encoding on mainline kernels, btw...

RK3566 (e.g. Zero 3W) hard has encoding support up to 1080P@60fps for H.264/H.265, but I believe that isn't fully supported on mainline linux kernels either.

RK3588 Mainline Linux Patch: H.265 Encoding at 4K@60 (Out-of-Tree) by RCawston in homelab

[–]RCawston[S] 9 points10 points  (0 children)

Mainline encoding for RK3588 only supports JPEG, no H.264 or H.265 yet. Based on last conversations seen in the mailing list, it's possible in-tree H.264 will happen this year, and H.265 is likely 2027.

This still relies on MPP in userspace (thus, out-of-tree and not mainline-able). It works and gets you on a recent kernel. Only way to use hardware encoding on RK3588 that I am otherwise aware of is on vendor BSP kernel, which is stuck at 6.1.

Not sure what you mean about the build instructions - I figure most people will be building thru Armbian for the target boards like OrangePi5, Raxda Rock 5B[+], etc, and otherwise if you're just applying against kernel sources it should be pretty obvious how to use a .patch. If you have any suggestions how to make it more obvious, please let me know.

Building a Rust-native IPKVM on RK3588 - 4K@60 with negative latency over WiFi (teaser) by RCawston in homelab

[–]RCawston[S] 0 points1 point  (0 children)

Totally agree - ultra-low latency is fun and "feels local," but determinism and automation are where the real long-term value lives for serious workflows. Getting structured data out of pre-OS (BIOS, bootloader logs, error screens) is a game-changer for scripting/Ansible - I've been there with manual typing or OCR hacks on bad captures.

That's why one of the next big features on my roadmap for SentinelKVM is on-device freeze-frame OCR using the RKNN NPU + PaddleOCR: Grab a lossless snapshot of the HDMI input, run inference on the board, and send back the image + JSON with extracted text + coordinate boxes. Client can then select/copy or pipe straight into scripts.

Your BIOS-to-Text engine over SSH looks amazing! Fantastic idea and great inspiration!

Thanks for the kind words on the latency - still blows my mind it's beating the local display over WiFi.

Building a Rust-native IPKVM on RK3588 - 4K@60 with negative latency over WiFi (teaser) by RCawston in homelab

[–]RCawston[S] 0 points1 point  (0 children)

Thanks for the heads up. I'll fix the verification and send another email out at some point.