Harleyyyu Posted 12 hours ago Posted 12 hours ago (edited) Inspired by the incredible work @jock and @ilmich have done to make the RK322x platform stable on mainline Linux, I decided to tackle the application side of things. My goal was to turn these "e-waste" TV boxes into fully functional, low-latency Android Auto head units for our cars. This fork of OpenAuto is built as one of my "Is it possible to turn this into that?" projects. It turned out to be one heck of a nightmare to pull off, but at the same time a lot of fun because I can see the potential of these TV Boxes as something you can actually put in your car and turn into a usable head unit! System Requirements Target Device: RK322x TV Box (e.g., MXQ Pro 4K). OS: Armbian Bookworm or Trixie (Kernel 6.1+ recommended). RAM: 1GB recommended. CMA Limit: You MUST set cma=256M in /boot/armbianEnv.txt to prevent VPU crashes at 1080p. FFMPEG Installed: This build requires a specific build of ffmpeg that can be found here. Release: v2.0.0-alpha This release represents a major architectural overhaul. I have removed heavy dependencies (PulseAudio, QtAudio, GStreamer) in favor of a lean, direct-to-hardware pipeline using RtAudio (ALSA) and FFmpeg v4l2_request. Download: https://github.com/Harleythetech/openauto-rk3229-armbian/releases Technical Details Video Engine: Switched from GStreamer to a custom FFmpeg + V4L2-Request backend. Leverages the v4l2drmprime patch set for Zero-Copy rendering. Enables full hardware H.264 decoding on Rockchip stateless decoders. Result: Stable 1080p 60fps stream on a 1GB RAM device. Audio Overhaul: Replaced PulseAudio and QtAudio with RtAudio. This creates a direct, low-latency path to the ALSA hardware driver. Display: Targets linuxfb (Framebuffer) by default instead (eglfs and ffmpeg have issues when you run them together due to DRM master lock) Configuration This release requires a specific ALSA configuration to allow audio mixing (dmix) without PulseAudio. Create/Edit /etc/asound.conf: pcm.!default { type asym playback.pcm "dmix_hdmi" capture.pcm "plug_null" } ctl.!default { type hw card 0 } pcm.plug_null { type plug slave.pcm "null" } pcm.dmix_hdmi { type dmix ipc_key 1024 ipc_perm 0666 slave { pcm { type hw card 0 device 0 } format S16_LE rate 48000 channels 2 period_size 512 buffer_size 4096 } bindings { 0 0 1 1 } } Known Issues Invisible Cursor: The mouse cursor works but is currently invisible when the FFmpeg video backend is active (rendering layer order issue). Backend Fallback: In rare edge cases where DRM initialization fails, the app may incorrectly default to Qt software output. Probably more, i haven't tested it that much Development Status: Active & Seeking Contributors Currently, I am the sole maintainer focusing on the RK322x platform (specifically the RK3229). I am actively looking for developers interested in expanding support to other devices (such as RK3328, RK3399, or Allwinner H3/H6). If you have experience with C++, Qt, or V4L2/DRM and want to help turn these TV boxes into capable head units, contributions are highly welcome! Repository: https://github.com/Harleythetech/openauto-rk3229-armbian Credits: @jock and @ilmich for ffmpeg patches and the csc-armbian-for-rk322x-tv-box-boards opencardev for openauto and aasdk Edited 12 hours ago by Harleyyyu 1 Quote
jock Posted 4 hours ago Posted 4 hours ago Nice, congratulations! I wonder why cursor does not show when video is playing by the way: there has always been a patch in the armbian code to support hardware cursor, in fact in X11/Wayland the cursor is handled in hardware and it is perfectly visible and usable when a hardware accelerated video is playing. Also I wonder why you need CMA=256M; normally rk322x VPU has its own MMU that is capable to handle direct to memory access without the need of CMA. 1 Quote
Harleyyyu Posted 1 hour ago Author Posted 1 hour ago (edited) @jock I figured out why the cursor doesn't show and it's not an armbian issue, the issue is more on how i implemented ffmpeg (previously Kmssink) on openauto and also the same reason why i can't use eglfs for the gui is that i had set ffmpeg to use plane 31 (primary plane, zpos 0) when streaming Android Auto. Since I am forcing the video stream directly onto the Primary Plane (Plane 31) via DRM, the hardware VOP (Video Output Processor) stops scanning out the Linux Framebuffer (/dev/fb0). This means that while Qt is still technically "running" and drawing the mouse cursor to the framebuffer in software, that buffer is simply never sent to the screen. The video stream completely overrides the UI layer. I did manage to fix it tho, since the RK322x SOCs support Tri-Plane, I had to patch ffmpeg to utilize the Cursor Plane (plane 41). Now when AA starts ffmpeg initializes the video on the Primary plane as usual, but simultaneously commits the ARGB cursor buffer to Plane 41 using the shared DRM file descriptor. This allows the VOP to hardware-composite the mouse cursor directly on top of the video stream, finally making it visible without breaking the zero-copy pipeline. As per CMA=256M, ffmpeg was throwing buffer allocation warnings. Interestingly, these warnings persist even with CMA set to 256MB—so the larger CMA didn't actually silence the logs as I initially thought. ffmpeg benchmarks actually run successfully on both 16MB and 256MB despite the warnings. However, I decided to keep the requirement at 256MB purely as a precaution. Given that a 1080p NV12 pipeline with multiple buffers can eat up memory quickly, leaving it at the default 16MB felt risky for long-term stability in a car environment, even if it 'technically' runs. PS: i haven't posted the build with the cursor patch Edited 1 hour ago by Harleyyyu 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.