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

FeFiFoFum · January 5, 2020 at 2:44 AM

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)

**chewitt** · January 5, 2020 at 4:10 AM Official Post

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.

FeFiFoFum · January 5, 2020 at 9:06 AM

So it's probably best to hold off a few months before testing?

Is there advanced builds on the 9.2 train?

**chewitt** · January 5, 2020 at 12:29 PM Official Post

We continue to fiddle with the firmware and such in the 9.2 branch as this can be tested independently of Kodi version, but this is mostly done via team internal or private testing so there are no public nightlies.

FeFiFoFum · January 7, 2020 at 3:24 AM

Is there anywhere I should look in a few months for "Pi4 testing, but kinda stable" builds?

**chewitt** · January 7, 2020 at 3:55 AM Official Post

You can always use Milhouse testing images .. released via the Kodi forums.

FeFiFoFum · January 18, 2020 at 4:49 AM

Ok thank you! (is it ever supported in stock version?)

**chewitt** · January 24, 2020 at 7:53 AM Official Post

Nope. Milhouse images are always bleeding edge code. I'm not sure he's releasing for RPi4 at the current time though (having looked).

**MikeKL** · January 24, 2020 at 5:56 PM

19 - LibreELEC Testbuilds for RaspberryPi (Kodi 19.0) is the current ongoing thread for download of latest millhouse nightly builds for RPi1, 2 & 3

millhouse has thoughtfully provided a note in 1st post for rpi4 users, explaining No nightly LibreELEC 10/Kodi 19/mainline (5.y) kernels ready for testing on RPi4 yet. (with a when they become available note will be updated etc)

FeFiFoFum · January 26, 2020 at 5:27 AM

That answers that Mike - I'll try to be more patient with other projects, thanks guys,.

donbrew · January 29, 2020 at 10:48 PM

On Jan 27,2020 they released Linux 5.5 which specifically supports RPi 4.

Does that mean good things for us?

**chewitt** · January 30, 2020 at 4:29 AM Official Post

"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

FeFiFoFum · January 30, 2020 at 10:00 AM

Chewitt, this means support under Linux right but this is different to the GPU driver giving us HDR right?

**chewitt** · January 30, 2020 at 1:17 PM Official Post

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

FeFiFoFum · March 11, 2020 at 11:38 PM

Do you think there will be performance improvements in general for the UI, before the LibreElec10 build? (Specifically Pi4)

**chewitt** · March 12, 2020 at 2:18 AM Official Post

Minor increments maybe, but I'm not expecting any .. but then I don't experience general performance issues with the GUI as-is. What is the issue?

SirhC · June 18, 2020 at 11:42 PM

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. ??

**chewitt** · June 21, 2020 at 1:55 PM 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