LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    thanks!


    Just two more questions about (the future of) the rk platform.

    - Is the memory cap "fix" still needed?

    - The rk3588 has an HDMI 2.1 out port. Will we ever see HDMI 2.1 being supported by that platform? I have seen that there have been some HDMI FRL patches made, but with the HDMI association blocking all HDMI 2.1 work and implementations on Linux ( at least with AMD and Intel..), will we ever get HDMI 2.1?

    The memory cap has been removed in RK images for a while now but we don't parse exlinux.conf during updates so if you installed with the cap it will be there until you remove it.

    Your guess is as good as mine on HDMI 2.1, but with the HDMI association veto'ing AMD's implementation I doubt developers will spend time on it due to the high probability of rejection and/or being sued. Was there a specific capability you were looking for?

    Collabora are working on broader colour support, but there are background kernel colour UAPI changes at the same time so it's likely to continue for a while to allow for things being merged in a sensible sequence. There is also development on multi-core support which is a requirement for 8K (an 8K image is essentially 4x 4K frames being parallel processed). I also haven't seen any signs of people working on AFBC yet, but that will also be needed to reduce memory bandwidth requirements.

    Yasai-san I've managed to build an image of LE13 for RK356X for my Radxa Zero 3 thanks to your work. Many thanks!

    I rebased on master, and tried to bump the aic8800 driver from the radxa-pkg/aic8800 repo from 4.0~ to 5.0~, but it failed to build. ie:

    Code
    PKG_VERSION="5.0+git20260123.5f7be68d-4"
PKG_SHA256="58c4c1ee085fac7971e9972dba99c5e3207e1ea0991c3f957bd9200f6ec8fbe7"

    Two questions:

    • Did you pick 4.0+git20250410.b99ca8b6-5 specifically, or was it just the latest when worked on this?
    • How did you figure out the right targets in projects/Rockchip/packages/aic8800/package.mk?
      • When trying to build 5.0+git20260123.5f7be68d-4 i had to comment out the pre_make_target for linux 6.12 as that build patch is missing and it then failed anyway with another error.
    Quote from axel

    Yasai-san I've managed to build an image of LE13 for RK356X for my Radxa Zero 3 thanks to your work. Many thanks!

    I rebased on master, and tried to bump the aic8800 driver from the radxa-pkg/aic8800 repo from 4.0~ to 5.0~, but it failed to build. ie:

    Code
    PKG_VERSION="5.0+git20260123.5f7be68d-4"
PKG_SHA256="58c4c1ee085fac7971e9972dba99c5e3207e1ea0991c3f957bd9200f6ec8fbe7"

    Two questions:

    • Did you pick 4.0+git20250410.b99ca8b6-5 specifically, or was it just the latest when worked on this?
    • How did you figure out the right targets in projects/Rockchip/packages/aic8800/package.mk?
      • When trying to build 5.0+git20260123.5f7be68d-4 i had to comment out the pre_make_target for linux 6.12 as that build patch is missing and it then failed anyway with another error.

    Hello axel

    > Did you pick 4.0+git20250410.b99ca8b6-5 specifically, or was it just the latest when worked on this?
    I used the latest version at that time.
    This is reason.

    > When trying to build 5.0+git20260123.5f7be68d-4 i had to comment out the pre_make_target for linux 6.12 as that build patch is missing and it then failed anyway with another error.
    I also confirmed this build failure.
    a) Radxa aic8800 repo removed linux 6.12 patch file by version up.
    fix: update patchset · radxa-pkg/aic8800@89f865b
    -> it needs to remove this patch apply from package.mk
    b) (after a) compile error is shown about vfree
    -> Radxa aic8800 repo has patch file for this compile error.
    aic8800/debian/patches/fix-vmalloc-not-include.patch at main · radxa-pkg/aic8800
    it needs to add this patch apply to package.mk

    Please check my following commit

    aic8800: bump version to 5.0+git20260123.5f7be68d-4 · ShigeakiAsai/LibreELEC.tv@2bb9159
    github.com

    (Sorry, this is compilation check only)


    Note.
    as you know, I do not actively support this. :)

    I've posted some fresh images for RK3566/3568/3576/3588 boards to my test share. The kernel bumps to Linux 7.0, but more interesting is the inclusion of work-in-progress Kodi changes that tonemap the OSD/GUI during HDR playback so that it renders with an SDR colourspace (while video remains in HDR) instead of searing your eyeballs. The greatest benefit is seen (literally) with subtitles. There's also some minor nip/tuck fixes for VP9 playback.

    Enjoy :)

    Quote from mitzsch

    Are there any fixes for the HBR audio dropout issue in that new build?

    Nothing specificially targetting the unknown problem. Figuring that one out is beyond my skill level and using Claude needs a level of strong direction else (from experience) it will makes lots of insightful sounding but garbage triage while running in token-burning circles not achieving anything.

    Is anyone else running into an issue where the screensaver kicks while playing a video, and it's not possible to get out of it? (I've not found any way out than to reboot using Kore or over SSH) This is on my custom build built from Github main branch two weeks ago (2026-04-15), but the only thing different is adding the (annoying) aic8800 wireless driver, so you'd expect this to have no bearing on video / screensaver.

    It's happening while set to "dim". I'm going to test with another screensaver, like the weather page, to see if it makes a difference.

    Quote from axel

    Is anyone else running into an issue where the screensaver kicks while playing a video, and it's not possible to get out of it?

    I've not seen this on any of the platforms that I use regularly. I'd stop and rename /storage/.kodi out of the way and then start over with a clean Kodi instance. Stop/copy/move config and bits back until you find the offending change.

    Sadly, this happened both with the out of the box /storage/.kodi from building LE, and then again with one i plucked from another working arm64 LE box (a Rock 4 SE) that i copied over to the microSD card to bring over all the config.

    In the first case, the timeout was set to 30 min by default and that's when it happened. Testing with the second config, it happened after 5 min which is when the timeout for the screensaver is set.

    chewitt how can i rebase my build on the same commit as you built your latest test builds, to make sure i'm using the same code as you, with only the annoying aic8800 driver package as a difference?

    Quote from chewitt

    Nothing specificially targetting the unknown problem.

    Hm, okay, I also just tested the latest build (17/04/26 - fresh install) and both the issue with the LPCM wrong channel mapping and hbr passthrough persist. Hopefully, they can get sorted out.


    About HDMI 2.1 - now that AMD wants to upstream HDMI 2.1 bits into the mainline kernel - this could open the gates for (rk) HDMI 2.1 open source implementations legally. ;)

    Running a nightly from the last week on a rk3399 box and get a black screen when playing back h264 content? Is this a known issue? If not I'll grab some logs etc and do a separate post.

    I am getting the same issue from time to time with my RK3566 (Quartz64 Model A). While playing a movie, the video suddenly drops to a black screen. I can still hear the movie audio perfectly, and I can hear the Kodi menu UI clicking if I navigate with the remote, but the screen stays completely black until I perform a full reboot of LibreElec. I don't know if its the same issue you're having?

    i was able to find a possible workaround though. The issue seems tied specifically to how the DRM handles the video plane. I went into Settings > Player > Videos and changed the PRIME Render Method from Direct to Plane to EGL. Since switching to EGL, the black screens have completely stopped and playback is perfect (with hardware decoding still active).

    I tried to capture a debug log when the black screen happens, but there are no visible V4L2 decoder errors, panics, or failed messages. The log shows Kodi thinks the video is syncing and playing normally. The only related line I catch when I manually stop the invisible video is:

    CDRMAtomic::FlipPage(gbm_bo*, bool, bool, bool): Execute modeset at next commit

    It seems like the hardware decoder is doing its job, but the video plane just silently gets dropped or rejected by the display driver when using Direct to Plane.

    I'm aware the HDMI chain on RK3288/RK3328/RK3399/RK3566/RK3568 (all chips that use dw-hdmi, not dw-hdmi-qp) is probably a little borked at the moment. The older patches (2018-2022) have now bit-rotted to the point where things are breaking on newer kernels and need reworking. Kwiboo is actively working on that and he's started to send replacement patch series to the kernel mailing lists, but the total number of patches is huge (150+) and right now only ~3/8 series are submitted. I plan to rework our kernel patchset this week to drop older patches and start including them, but this will be a "two steps forwards, three steps backwards" move as Jonas is (re)building the base functionality first. Older patches that add e.g. 4K/HDR support are unlikely to be useable so I expect capabilities to regress until more of the rework lands. Older LE releases with older kernels/patches before breakage are probably more functional on the above hardware at this point of time.

    Quote from chewitt

    I've been running tests on an RK3576 Rock-4D board. The kernel codebase is still maturing in places but I think this will be a nice sweet-spot for LE use. The boards are less-featured than RK3588, which makes the boards cheaper, but the peripherals that have been omitted are all things that LE has no use for, while the media capabilites are essentially the same.

    Out of curiosity is the bit rotting and breakage related to the "drm/connector: Create HDMI Connector infrastructure" series that landed in 6.10? I think that's where the atomicity went from being A path to THE required path