My system is a Radxa Rock 5 ITX (without +), 32 GB RAM, but this topic probably applies to many other RK3588 boards, so please feel free to comment even if you don’t have Rock 5 ITX.
So, is there anyone here using latest kernel (v7.0) on rk3588? I’ve got some problmes and I’m not sure if this is how it’s expected to work right now, or it’s just something wrong I’m doing.
I have the mainline kernel v7.0 with rockchip video-output driver, panthor 3D driver, hantro video accelerator driver, video bridge, etc., Mesa v25.3.6 with panfrost driver, Xorg server v21.1.21 with modesetting driver, no desktop environment, just IceWM window manager. X server runs as root, so there should be no permissions problems.
The main problem I have is that the video stutters constantly and it completely freezes when I move the mouse outside the window. This happens with video playback, with glxgears, vkgears, vkcube, even when dragging windows on the screen.
I tried “mpv -vo gpu -hwdec=vaapi”, “mpv -vo gpu -hwdec=drm” and “-hwdec=vulkan” from kernel console (virtual terminal, with no X running) and the playback is very smooth.
I know the panthor driver is new and the Mesa panfrost driver only recently added support for panthor, but is this how it’s expected to work right now? Or is there something wrong with my system?
I remember this from around the time when kernel 6.8-rc (armbian rk3588 build). Earlier X11 worked good enough, although felt more brute-force framebuffer operation, NanoPi-R6C (=rk3588s) and only 1080p60. Was with some 2017-09 based U-Boot in eMMC.
Now with EDK2-UEFIv1.1 in eMMC KDE6 Wayland works fine with Debian sid kernel 7.0.3+deb14-arm64-16k. Userspace is Armbian Trixie based, so at least Mesa is older. I have only used FireFox for some internal webpage and not really looked at HW acceleration. I know this setup can play 1080p50 HEVC fine, but that is SW decoding. Also via HW but was with latest LibreElec booted dedicated from SD-card half a year a go or so. I can check later this week if the mentioned mpv commands somehow use HW decoding, I will only check the CPU load I think. And maybe when running as multi-user.target and even maybe console only via serial, so the HDMI may only show blinking cursor initially. I think the ‘whole video HW’ needs to be free, else mpv cannot claim ‘full-screen DRM’, but I am quite guessing, based on how other ARM SoC’s behave(d).
To achieve this, I build my mainline kernel with a bunch of WIP and in-flight patch sets.
For MPV support, I am rebuilding the FFMPEG and MPV distribution packages with applied pull request patch sets, since the support has not yet landed in mainline releases.
Everything else is provided out-of-the-box by the standard packages of the distribution of my choice.
The OS resides on an NVME that is located in a USB adapter case. In this way, I can use it with all my various devices.
The system is started on each device with device-specific firmware that uses mainline U-Boot as a payload.
@Dbenton 2560x2880@30Hz - not a mistake, it’s a weird monitor.
@usual-user Could you test vanilla kernel? I’m interested to know if it’s the kernel or something else. If it’s the kernel, then I would really appreciate the list of patches you used.
‘-v’ added to mpv arguments shows that it does only software decoding on the setup I listed earlier (for HEVC at least), have not used any other codec.
I do not understand what purpose it is supposed to serve. Without the patches applied, of course, the functionalities that they implement are not available.
There is no fixed list of patches, each kernel build applies the patch set corresponding to the kernel source.
Development is a moving target and @Dbenton has already posted the reference where the available patches are tracked.
For mpv with v4l2-request support, you must have at least configured ‘hwdec=v4l2request-copy’ and ‘hwdec-codecs=all’.
