Posts by chall88

    The kernel is something that moves forwards continuously and relentlessly so the adage "If you stand still, you're actually moving backwards" applies in a big way and because (for good reasons) people became inactive for a while a whole heap of WIP changes got parked for a while. I don't think there's a single series, it's more a case of "a little bit of everything" as the kernel evolved.

    Im picking up what you're putting down. As opposed to the windows way of doing things where operating systems are just stacked on top of one another forever. Where your windows 2000 program will still run through 7 shims, and if you dive too many layers deep in the menus you'll end up in a program with an unresizable tiny window from when monitors were 480p, because why would anyone ever need to resize a window 😂.


    I was just curious, I know there was an effort or push to overhaul and standardize the requirements for manipulating graphics around kms and drm to help make things less of a wild wild west. Probably pretty helpful in the long run for projects supporting wide range of devices, although painful in the short term. Especially with manufacturers of sbcs that like to play the hype release abandon cycle on repeat.

    I was helping Moonlight-qt project who lost thier HDR support because setting 1 property on 1 connector instead of atomically, the kernel just said no after a certain version. I think those changes started around 3.19 but ran parallel and weren't enforced until well into the 6.x versions. I was just curious if the rock chip HDMI was a casualty of that same standardization effort with kernel graphics coming to completion.

    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

    LE13 now has support for flatpak add-ons with the Chrome add-on experience where Kodi is stopped, the flatpak app runs, and when you exit the app Kodi is restarted. We already added the SteamLink flatpak. We'd prefer to see a Moonlight flatpak add-on (assuming it works) as this would have less maintenance and faster compile than dealing with Qt6 from source.

    You could also investigate the LEIoT distro which coexists in the buildsystem as the base for a more minimal image. LEIoT drops all the background plumbing for Kodi (which you're probably not using) with a base image around 85MB in size (including Docker). You could drop docker and add moonlight-qt to ADDITIONAL_PACKAGES+= and see what happens or leave it and package the Qt6 things you need into a container (or be lazy and pull someone else's) .. there's lots of options.

    NB: I'd suggest creating your own $DEVICE in the buildsystem else future changes we push will trample on yours in a rebase. I plan to drop current Rockchip devices after LE13 and reconfigure the buildsystem to have two new ones; a single 'arm' image (RK3288) and single 'aarch64' image (RK3328 thru RK3588) using a common kernel/patchset.

    The Flathub moonlight-qt manifest already had V4L2 Request hwaccel in FFmpeg and DRM renderer enabled for aarch64. Three changes were needed for embedded KMS-only hardware:

    1. SDL3: KMSDRM=ON for aarch64
    2. moonlight-qt: CONFIG+=embedded for aarch64
    3. finish-args: QT_QPA_PLATFORM=eglfs, QT_QPA_EGLFS_INTEGRATION=eglfs_kms, QT_QPA_EGLFS_KMS_ATOMIC=1

    The KDE Platform 6.10 runtime ships EGLFS with KMS/GBM platform plugins for aarch64, no need to bundle Qt6. Hardware decode via V4L2 Request (rkvdec) confirmed working. With Kodi stopped, the Flatpak acquired DRM master cleanly and the Qt EGLFS UI displayed correctly. SDL shared the DRM master fd with Qt EGLFS as expected.


    DRM bridge issue:

    LE 13 kernel logs show:

    Code
    [drm] DRM bridge corrupted or not allocated by devm_drm_bridge_alloc()

    Linux 6.12+ changed the DRM bridge allocation API, bridges must now use devm_drm_bridge_alloc(). The RockPro64 HDMI bridge driver (dw_hdmi_rockchip) hasn't been updated yet. The HDMI bridge initializes incorrectly, causing all HDMI connector-level DRM property writes to fail with EACCES (-13). This is also why Kodi has no display on LE 13 RockPro64, Kodi uses KMS atomic commits too and hits the same broken bridge.


    Moonlight errors, what they mean:

    At startup:

    • drmModeObjectSetProperty(max bpc) failed: 13, SDL3 trying to set HDR bits-per-channel on the HDMI connector, EACCES due to broken bridge
    • drmModeObjectSetProperty(HDR_OUTPUT_METADATA) failed: 13, same cause

    During streaming:

    • Failed to commit atomic request (code=-13), video overlay plane commit failing at 60fps because any atomic commit touching the HDMI connector is blocked by the broken bridge

    The EGLFS UI plane works because it doesn't touch HDMI connector properties. The video overlay fails because SDL's atomic commit path does.

    dw_hdmi_rockchip has to use devm_drm_bridge_alloc(). Once that lands in LE 13, the three-change Flatpak manifest should work well

    If you would look around you would find already working package ;)

    Has someone already done this for qt6? I found qt5, but it had all the display capabilities stripped out, so I left it alone and went for qt6 because moonlight-qt prefferentially wants it

    no-opengl
    no-egl
    no-eglfs
    no-kms
    no-gbm
    no-xcb
    no-linuxfb

    I started on flatpak for it, im having to rebuild because the existing one out there is build for a desktop environment and needs x11 or wayland


    SDL3 with kmsdrm=ON

    moonlight-qt with embedded config flag

    env vars to tell moonlight-qt what video stuffs to use

    Hopefully the kde platform runtime's qt6 has the eglfs/kms plugin or it's back to compiling qt6

    >We already added the SteamLink flatpak. We'd prefer to see a Moonlight flatpak add-on (assuming it works) as this would have less maintenance and faster compile than dealing with Qt6 from source.


    This is probably the way, it's still container-ish like docker but less overhead, and moonlight-qt already releases a flatpak so the rest would just be addon work. I'll start digging around on 13 and see how it goes. You're right about qt from source, it's a hefty one. As long as the ffmpeg-v4l2-drmprime path is still useable from flatpak and kodi is stopped it should be equivalent performance wise


    I was exploring options for game streaming on a RK3399 SBC and LibreELEC was a clear starting point — the V4L2 Request + DRM PRIME hwaccel pipeline is already working and well-tested there. The options I found were script.luna (originally from CoreELEC, using moonlight-embedded, potentially adaptable) and a solution that ran moonlight-qt inside Docker on LibreELEC. The CoreELEC path was decent but moonlight-embedded lacked the DRM PRIME backend that moonlight-qt has — moonlight-qt integrates FFmpeg decode and direct DRM output in a way that moonlight-embedded doesn't. (I was able to add it, but ran into KMS DRM master conflicts with Kodi in the way that can probably be sorted out.) Wanting to squeeze every bit of performance out of decade-old hardware, and not have kodi+docker overhead, I set out to splice LibreELEC and moonlight-qt together: strip Kodi, build Qt6 for the target, and have the box boot straight into moonlight-qt with full rkvdec hardware decode and zero overhead.

    It worked. 1080p60 HEVC @ 20 Mbps, 2.7ms average decode time, 0% frame drops. Working audio and controller. No stutter.

    Due to the nature of SoCs this should be portable across all RK3399 boards with only the U-Boot target needing to change.

    All credit goes to the LibreELEC project and the moonlight-qt project:

    GitHub - LibreELEC/LibreELEC.tv: Just enough OS for KODI
    Just enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.
    github.com
    GitHub - moonlight-stream/moonlight-qt: GameStream client for PCs (Windows, Mac, Linux, and Steam Link)
    GameStream client for PCs (Windows, Mac, Linux, and Steam Link) - moonlight-stream/moonlight-qt
    github.com

    Most of the heavy lifting was done with Claude Code, working through ~25 build failures, mostly around Qt6 host vs. target cross-compilation. I merely gave it the goal and guided it through the problem space with documentation to kept it from going down rabbit holes, and tested the builds.

    I've uploaded the build for my board (RockPro64) along with the build tools and a readme if anyone wants to try it on their own rockpro64 or build it for another rk3399 board The Rock Pi 4 is going for around $60 now, not a bad price for a dedicated game streaming box. There's also an interesting future direction here: Qt6 and moonlight-qt could potentially be integrated into mainline LibreELEC, or the hwaccel backend from this project could be used with the Kodi interface instead of Qt, which is essentially what script.luna did with moonlight-embedded on CoreELEC. Could be a meaningful contribution to the project.

    I have helped moonlight-qt project in the past by helping supply examples of getting HDR going kmsdrm with atomic commits, and will submit what I did with adding the ffmpeg v4l2 drmprime pathway as a backend option to moonlight-embedded before pivoting to moonlight-qt, so moonlight embedded may have that down the road instad of having to bring QT along as an interface.

    Build comes in at 142MB

    Readme
    Fork

    My bluetooth controller isnt working with libreelec on the rockpro64 rk3399. I have tried 3 different chipsets rtl8761bu rtl8821cu and the broadcom BCM20702A0 I'm getting the same behavior across all 3 chipsets. Im starting to think it's not the bluetooth or the controller, but something to do with inputs to the menus in kodi itself.

    The controller does the same things, pairs connects and identifies in all 4 modes. I can see the hci traffic with btmon just fine. The only one that looks to be having issues is the sony profile on the controller. Sometimes however, when I pair the controller, the session crashes to tty until I reboot. That particular crash has persisted across mutliple SD cards and EMMC cards, does not happen with anything else. Its something specific to libreelec and not kodi. It does not happen with kodi on coreelec. Controller tested working with all chipsets in all modes on my arch desktop.


    [ 73.655927] input: 8BitDo Pro 2 as /devices/platform/usb@fe900000/http://fe900000.usb/xhci-hcd.4.aut…05/input/input5

    [ 73.656675] microsoft 0005:045E:02E0.0005: input,hidraw4: BLUETOOTH HID v9.03 Gamepad [8BitDo Pro 2] on e8:48:b8:c8:20:00


    [ 289.569259] input: 8BitDo Pro 2 as /devices/platform/usb@fe900000/http://fe900000.usb/xhci-hcd.4.aut…06/input/input7

    [ 289.569593] hid-generic 0005:2DC8:6006.0006: input,hidraw4: BLUETOOTH HID v1.00 Gamepad [8BitDo Pro 2] on e8:48:b8:c8:20:00


    [ 289.569259] input: 8BitDo Pro 2 as /devices/platform/usb@fe900000/http://fe900000.usb/xhci-hcd.4.aut…06/input/input7

    [ 289.569593] hid-generic 0005:2DC8:6006.0006: input,hidraw4: BLUETOOTH HID v1.00 Gamepad [8BitDo Pro 2] on e8:48:b8:c8:20:00

    [ 440.539721] sony 0005:054C:05C4.0007: unknown main item tag 0x0

    [ 440.550101] sony 0005:054C:05C4.0007: Failed to get calibration data from Dualshock 4

    [ 440.552171] sony 0005:054C:05C4.0007: hidraw4: BLUETOOTH HID v81.00 Gamepad [Wireless Controller] on e8:48:b8:c8:20:00

    [ 440.552180] sony 0005:054C:05C4.0007: failed to claim input

    [ 461.016274] Bluetooth: hci0: Opcode 0x 401 failed: -16


    [ 593.685836] nintendo 0005:057E:2009.0008: hidraw4: BLUETOOTH HID v80.01 Gamepad [Pro Controller] on e8:48:b8:c8:20:00

    [ 595.726409] nintendo 0005:057E:2009.0008: using factory cal for left stick

    [ 595.764407] nintendo 0005:057E:2009.0008: using factory cal for right stick

    [ 595.855313] nintendo 0005:057E:2009.0008: using factory cal for IMU

    [ 596.012268] nintendo 0005:057E:2009.0008: controller MAC = E4:17:D8:3A:84:A2

    [ 596.583591] nintendo 0005:057E:2009.0008: Failed to set home LED default, unregistering home LED

    [ 597.116902] leds 0005:057E:2009.0008:blue:player-5: Setting an LED's brightness failed (-110)

    [ 597.117242] input: Nintendo Switch Pro Controller as /devices/platform/usb@fe900000/http://fe900000.usb/xhci-hcd.4.aut…8/input/input10

    [ 597.117897] input: Nintendo Switch Pro Controller IMU as /devices/platform/usb@fe900000/http://fe900000.usb/xhci-hcd.4.aut…8/input/input11


    I also tested with a bluetooth mouse, and a bluetooth speaker, which seem to work, so this is controller input related and specifically on libreelec

    I ran into this as well

    Its the same behavior on two different bt modules

    One has an issue in taht its a 8821cu, which loads the 8821c firmware which half works. The wifi may or may not work, but the bluetooth seems semi-stable with the wrong firmware. I've seen this issue on at least half a dozen distros though.

    The other is an 8761bu.

    It both cases the bluetooth pairs and correctly identifies the controller in dmesg.
    btmon shows the controller inputs are making it across, but I cant actually control anything iwth the controller, its like the inputs are beind disregarded.

    I have 4 different modes on the controller and they all pair and identify correctly, but I cant actually control anything