Nightly images for A64, H3, H5, H6 and R40 boards

    Gigabit ethernet was always broken on Beelink GS1, at least on my box. Could never hold more than a few minutes of sustained load, dying with transmit queue watchdog timeout.

    Spent some time investigating, it seems this marvel of Shenzhen AZW Technology Co. engineering requires some additional tx delay.

    I have absolutely no idea on how to tune the actual tx-delay-ps value properly.
    200 seems to work, box survived overnight iperf3 test with 5 TiB transferred and no link drops or errors in eth0 stats.

    Beelink GS1 latest nightly, on fresh boot vp9 hardware decoder doesn't work.

    Code
    kernel: hantro_watchdog:127: frame processing timed out!

    Workaround is playing at least one h264 or hevc video, it somehow unblocks vp9, probably initialization issue.

    Did some tests, a few modesets on GS1 with 1440p monitor.

    Monitor EDID

    TL;DR
    1) Broken [email protected] and semi-broken [email protected]
    2) Limited RGB in some but not all of 1080p modes
    3) Way too conservative downgrade to 8-bit and YUV422. Theoretically, assuming HDMI 2.0, for this monitor everything up to 1440p@120 can be 10bpc+RGB, 4K@60 can be 8bpc+RGB

    Quote from jernej

    Test following image

    VP9 is now working straight after reboot :thumbup:

    As for 1440p modes:
    1) Every 1440p mode from EDID is now 8bpc+YUV422 :( But non-EDID ones supplied in cmdline like video=HDMI-A-1:2560x1440@61 are still 10bpc+RGBfull!
    2) [email protected] modeswitch now works. No stripes in video playback.
    3) 2560x1440@120 is fine on boot, in Kodi UI and in videos up to 1080p, but playback breaks to horizontal stripes on 4K videos.
    4) [email protected] works in console, stripes in Kodi UI on first boot until some video played. Video playback is fine upto 720p, 1080p and 4K video playback breaks to stripes.


    Also, in 8bpc+YUV422 modes there is a green vertical line on the left, probably first 1px wide column.

    Edited once, last by offbeat (November 4, 2026 at 11:09 AM).

    Thanks for testing!

    1. That's how format selection worked so far. Your monitor declares 300 MHz as its max TMDS clock for non-scrambled signals, so at [email protected] (241.5 MHz) 10-bit RGB doesn't fit anymore (301.9 MHz), while at 120 and 144 Hz 10-bit RGB is over the 594 MHz limit. In all those cases the driver fell back to 10-bit YUV 4:2:2 (monitors usually show 4:2:2 as 8 bpc, but it carries 10 bits). Your custom 61 Hz mode has different timings, so 10-bit RGB still fits there.

    That said, 4:2:2 makes sense only for HDR content, so I changed the policy: YUV 4:2:2 is now used only when HDR metadata is set (HDR video playback), otherwise RGB 8-bit is preferred if it fits. This also applies to 4K@60 modes, which used YUV 4:2:0 for SDR on HDMI 2.0 sinks before. Output format is switched automatically when HDR playback starts and stops.

    The green line: I couldn't reproduce it on my monitor, but YUV 4:2:2 conversion used a long filter, which can produce garbage at the line start. It now drops chroma samples without filtering, the same as the vendor driver does. Since SDR is now RGB, you'll only see 4:2:2 with HDR videos - please check if the line is still there.

    3. This one is a hardware limit. Downscaling 4K video to 1440p at 120 Hz needs about 75 % more display engine bandwidth than it has, and with compressed frames (HEVC and VP9 decoders output them on H6) the display engine can't skip lines to compensate. The vendor driver has the same limitation. Please enable "Adjust display refresh rate" in Kodi, so 4K videos are played at 24/25/30/50/60 Hz instead. Which codec are those 4K videos?
    4. The stripes in the UI at 144 Hz were with YUV 4:2:2 at 592.5 MHz, while the console (RGB 8-bit) worked fine. Since UI and SDR videos are now RGB, that should be gone. Bandwidth shouldn't be an issue for 1080p video at that mode, so please report how it behaves now.

    Test image: https://jernej.libreelec.tv/images/h6/Libr…241-0dafbf3.tar

    Thank you, tested HDR video, mode switched to 4:2:2, no green line anymore.

    So according to strict interpretation of EDID this particular monitor isn't allowed to use pixel clocks between between 300MHz and 340MHz over HDMI? I could try connecting it over HDMI to amdgpu PC some time next week, test how it behaves. Over displayport this monitor has different EDID with max pixel clock 690MHz, allowing 1440@175 mode.

    As for 1440@120, this is an unfortunate limitation of Allwinner, being multiple of 24/30/60 is such a good refresh rate for typical video content, it's also kind of OK for 25/50 videos. Whitelists and refresh adjust options in Kodi are nice, but monitors/TV's are typically slow to adjust rates, which is annoying.

    Anyway, messed around a bit with EDID editor, 1440p modes can only be described in DTD blocks, and only four of these fit in EDID. Defined 60/50/48/47.95Hz modes with CVT-RBv2 timings, created edid override in LE, all four modes run in 10bpc RGB.

    1440@144 issue still persists. I mean 144Hz itself isn't really usable for video playback purposes because of display engine limitations, etc. But this bug is bad for usability reasons. On new installation, Kodi boots to 1080p60 because of default cmdline, user then tries to change resolution to monitors native 1440p, Kodi automatically chooses highest refresh rate for that particular resolution and UI goes brrr. Workaround is playing single video in some other resolution, then UI doesn't corrupt at 1440@144 anymore (until next reboot).