Marvin Rösch

@maximumsettings I have personally been interested in getting Moonlight running on the Orange Pi 5 myself and have invested a lot of time in it already. So, depending on the feature set you want to have supported by the streaming client, the work involved varies significantly. Getting a working build of moonlight-qt is very straightforward if you have the ffmpeg version from ppa:liujianfeng1994/rockchip-multimedia installed, as it can use that for decoding through Rockchip MPP. However, neither HDR nor surround sound will work out of the box. For surround sound, configuration of the ALSA sound system (and potentially PulseAudio for channel mapping) is required. Even after that, it was still not working properly with moonlight-qt. HDR I have not been able to get working at all with moonlight-qt, as the Rockchip kernel uses a non-standard name for the required 10 bit color format and doesn't create DRM overlay planes for Moonlight to use. I have had more success with getting moonlight-embedded working on my Orange Pi 5, but that also required small modifications. Surround sound worked out of the box, while HDR support still remains elusive even with some custom modifications to support the non-standard pixel format. I was able to get my display to switch to HDR mode and to at least get a picture out of Moonlight, but the colors were completely off. The embedded version obviously lacks a GUI, though, and you'd probably want that for your customers. Performance-wise, moonlight-embedded has been working very well for me, but I still have encountered some issues where occasionally the stream would just stop and everything froze on the last frame, such that I had to manually kill the process. In order for my wireless Xbox controller to be supported, I also had to manually install the xone DKMS module, which was problematic because the kernel header package for the Rockchip kernel doesn't work correctly out of the box. So as a user, the experience with moonlight on the Orange Pi 5 has been lackluster at best so far and a lot of effort has to be put in in order to get it user-friendly.

Ah great, that is exactly what I did as well, so I guess I had misconfigured Kodi in some way that I didn't get any audio at all on my soundbar when using passthrough. I've got at least a little further with my HDR DRM woes as well, the "support-multi-area" property in the device tree for vop was indeed what was required to make overlay planes show up. Unfortunately, all I get when trying to use these overlay planes from an application (e.g. moonlight-qt for game streaming with some adjustments to use a different pixel format) is a fully black or green screen. The HDR logo on my TV does show up, though, so it's a start! I haven't had too much time to look into it further the last few days, but I might investigate some more today.

Ahhh, thanks a bunch, @royk, I was missing this particular setting, now my TV switches to HDR when I play the right content. I also looked into why that setting is required at all, and it looks like the Rockchip DRM driver does not create any overlay planes that could be used as targets for intermediate HDR rendering. I'm looking into why that might be, because as far as I can tell, the VOP2 driver that gets loaded for the RK3588 should set up at least a few overlay planes (see https://github.com/radxa/kernel/blob/linux-5.10-gen-rkr3.4/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c and the actual implementation in drm_vop2.c). Maybe there's some option in the device tree that still needs to be enabled. There is something about multi area support in the driver source, possibly that is it. I'm still looking into audio passthrough as well. I got the option enabled in Kodi and have enabled passthrough for various formats, but my soundbar still displays that it receives regular stereo LPCM, where it displays e.g. Dolby Digital if I pay something directly from my TV.

@royk You say you got HDR working with your instructions, but I seem to not be able to reproduce your result. I built the image from the latest master and renamed the overlay files from rock-5b-* to rk3588-*, but Kodi would still not trigger my TV's HDR mode. I've also renamed them to rockchip-rk3588-* and explicitly added them to overlays in armbianEnv.txt (as my overlay_prefix is rockchip-rk3588, that should work, right?), but that didn't help either. Oddly enough, Kodi doesn't even display that my test files are HDR in its menu, so maybe something is wrong there (I have verified that they are HDR content). Do you know of another way of verifying the HDR support? I'm also currently investigating HDMI audio passthrough and will report back later if I get it working. I'm hoping Efe's latest changes help here. I've also noticed that the kernel headers produced by the buildscripts does not seem to work for module builds out of the box when cross-compiling because it lacks the scripts/module.lds file for me. That appears to be caused by the cleaning here in packages/armbian/builddeb: if is_native; then # echo "Skip scripts folder cleaning" >&2 # echo "Skip creating postinst prerm scripts for headers" >&2 deploy_kernel_headers $kernel_headers_dir create_package $kernel_headers_packagename $kernel_headers_dir else # Clean up the executables that are left over from # cross-compilation for a different host architecture. ( cd $srctree make M=scripts clean ) deploy_kernel_headers $kernel_headers_dir create_package $kernel_headers_packagename $kernel_headers_dir "headers" fi This used to be prevented by https://github.com/armbian/build/blob/master/patch/misc/general-packaging-5.10.y.patch#L239, I think, but that patch's no longer applied, and instead the custom builddeb is used. @Igor Since this seems to be a regression or an inconsistency between native and cross compilation as far as I can tell, would a PR that adds something similar to that ldstemp mechanism to the new builddeb script be accepted?