Is there an active Pi4 'testing' build? (Sorry, I had a peek, can't see one?)

  • I am curious to do some testing of Pi4 builds for the future, is there anything out there? I have 9.2.0 but I want to see improvements available for the Pi4 in newer non final builds?

    (Example UI performance)

  • You can download images built from the LE master branch from Index of / but the development focus in master is about moving from MMAL to GBM/V4L2 which is still general work in progress. You'll probably find the images are overall less usable than current 9.2 images.

  • "Support" in that context means you can boot the board. There's a ton more code required to get a functional media device!

    Overall I am very happy to see a mix of the Pi Foundation staff, several core subcontractors they hired, and numerous names from the Pi ecosystem (including some of our own contributors) writing and upstreaming code to the kernel right now. The previous Pi architecture ended up being largely "out of tree" because when the first Pi launched in 2012 the folks who wrote the code were (in their own words) pretty ignorant about kernel things and the business priority was on shipping a working product. Over time their upstream awareness grew but the success of the Pi meant the task had become exponentially larger and still being a charity with a small staff the priority remained on shipping a working product. RPi0/1/2/3 are now super stable because the codebase has been iterated continuously and attentively over a period of seven years. RPi4 is being treated very differently. The benefits of being and business need to be "upstream" are very clearly understood now, and to continue the stratoshpheric success of Pi hardware the new shiny needs to mature a tad quicker than seven years. Lessons have been learned. Fortunately the success of the Pi means they're somewhat better funded this time around, so they aren't being shy about spending on good resources to get things done.

    So .. to end my ramble. In the last few days some of the GBM/V4L2 work reached the point where we can package a "working" system on Linux 5.4 and we'll bump to Linux 5.5 soon. Proper public testing is still some way off as the transition from MMAL to GBM/V4L2 decoding means "one step forwards and two steps backwards" in the user experience due to the amount of new code involved. We'd like things to be closer to parity before we invite the masses to bug hunt. The greatest compliment will be a bunch of users whining about updating and not noticing any difference :)

  • Once the KMS driver supports 10-bit output (almost there) HDR comes within reach; although most HDR media is HEVC and under GBM/V4L2 the HEVC support is still at a fairly experimental stage. RPi4 is an unusual SoC becuase H264 (the same IP from previous Pi generations which we've had working for a while) follows the stateful API while HEVC (new IP from another Broadcom chip, with all new code) follows the stateless API. Making it all work together (including the FFMpeg side) is uncharted territory. The first step is making something work. Then we have to make it work reliably. Then we have to get the code upstream (Royal 'we' .. the Pi Foundation folks). TL/DR; don't hold your breath just yet :)

  • Chewitt, it`s now 6 months down the line so any update as to the future of the 5.x kernal since usb booting is now w.i.p & the previous road blocks must be advancing. ??

    • Official Post

    RPi4: switch to KMS driver and enable v4l2 HEVC decoding by HiassofT · Pull Request #4288 · LibreELEC/LibreELEC.tv · GitHub <= LE master branch has been on Linux 5.4 for a while now, but the main GBM/V4L2 changes were merged only yesterday. Right now anyone using an LE10 test image will find a few functional regressions over the LE9.2 codebase, but hey it's still a pre-Alpha state branch so we provide zero promises about that, and there's nothing like a spot of breakage to focus people's attention on fixing the outstanding problem stuff :)