Posts by chewitt

It's unusual for a USB dock to be seen as non-removable but it's all down to the dock firmware and how it presents to the host OS. Preventing writes to non-removable devices is a well proven method for stopping n00b users from overwriting their host OS - it's not going to be changed.

Not been done, and even if it's possible (which is unlikely due to our weird packaging) we have no interest in supporting the approach.

The CE script should work on the equivalent LE image.

Quote from dipswitch

It is beyond my comprehension how one would be able to develop an opensource linux gpu driver. Is this all done without cooperation from ARM? As i try to imagine, one should need some tech docs, documentation to start "writing" the code? I keep being amazed how much hardcore programmers are still out there trying to achieve great things.

Am i right to conclude that the current available LE images for s912 are all based on the android driver on lybhybris?

And finally, if im not overwelcoming my stay , it's great to hear that s912 development on opensource gpu driver is on its way. I also read that rockchip LE , what years back was unimaginable, now is fully supported on rk3399 and rk3328. If i might ask chewitt , at this point in time, would you go the s912 route or choose the more powerfull rk3399 rock64pro solution?

Panfrost is based on a combination of observational reverse engineering and mathematical theory. As I understand the story.. someone noticed that patents ARM filed for their midgard and bifrost designs resembled an earlier maths research paper and a hunch the two are connected has proven true; allowing code to be written against the concepts in the public and detailed paper instead of an obtuse patent filing (which can technically be struck-down or invalidated now the connection to independent prior-art is proven). It's all down to a little amount of luck and a huge amount of hard (brain and code) graft. Panfrost is quite an achievement

99% of current S912 images from community developers are 3.14 + libhrybris. The lone developer blazing a trail on mainline S912 images with LE and Armbian is balbes150 .. but those are not ready for anything beyond a curious look at this stage. Panfrost is undergoing substantial code packaging changes at the moment and i'm not expecting progress on memleaks and other issues until the dust settles.

At the moment I think S912 is the "least worst" option due to availability of current 3.14 images which still have some fugly bits but are functional. RK development is promising (and probably better technical chips in some areas) but the codebase still has some way to go before it stabilises on a mainline kernel while the Amlogic mainline codebase is already quite mature (aside from the critical GPU component). Amlogic also has a team of commercial developers working on related code for funded projects which I think will check items on the to-do list faster.

wrxtasy There is no multi-channel or HD audio support in RK images at the moment. We know what needs to be done but developers keep finding new and exciting video problems to work on so multi-channel audio work (which is shared with Allwinner and Amlogic which use the same designware IP) is still pending. At some point they'll run out of video stuff to fix and it'll get done

4K HDR is in the same limbo state as all current RK development .. waiting on the bump to mainline and an all-new V4L2 decoder. We have MPEG2 and H.264 functional under the new regime along with a new FFMpeg V4L2 stateless hwaccell. There's a lot of uncharted plumbing to be done to handle all the colour bits needed for HDR and while this work has started it's ultimately pending on the Intel HDR patches which are under review (and taking time due to the number of chefs in the kitchen - there's a long list of GPU/SoC's that will reuse the same kernel framework).

RK3399 has no HDR > SDR on-chip but something should be possible via other means ^ pending the colour stuff being more generally nailed down.

The Kodi patch linked will be in 9.0.0 and the continuing RK alpha releases .. once 9.0.0 releases.

cmb are you deliberately hijacking the original thread from kevtuning or trying to be helpful replicating someone else's problem while using a non-standard Kodi configuration? (e.g. modified cache settings which are almost never required).

Read post #6 .. the link you keep posting is not our wiki.

8.95.3 is stable, and 9.0.0 will be along imminently..

SD card image and burning tool images are different formats.

LE uses syslinux for 64-bit systems and GRUB for 32-bit .. specifically for dealing with these Atom devices. They can run a 64-bit OS, but they require a 32-bit bootloader.

Go read the instructions in the LE wiki that do not require LIRC - it's really not required for 99% of the remotes out there.

As long as you're using the current LE 9.0 release the version of the add-on in our repo will be the latest one available. If there's an issue with the add-on running on K18 then it should be reported to the add-on creator via the Kodi forum support thread.

H.264 is an 8-bit video standard and RPi has full support for hardware decoding it. Your video is 10-bit, which is not in-spec for the standard, so your RPi can only software decode it (even at 720p resolution) and as you've discovered that's beyond the CPU capabilities of an RPi device. You'll need to upgrade to something with more CPU grunt (Intel CPU, not ARM) or re-encode the video to 8-bit.

Put the eMMC module in the USB adaptor and write the image direct to eMMC same as an SD card.

I found the VU+ git repo with some OpenEmbedded recipes. I stopped looking when I saw "3.14.28" kernel being used. It's probably possible to make an LE image for that hardware but "backwards" is never a good technical direction.

So, definitely not supported.

S912 is now working on mainline linux kernels using the "panfrost" open-source alternative to the non-existent ARM mali blob and balbes150 has a testing image available via his K18 release thread for the curious to look at. Panfrost is still under fluid development and it's not stable enough for real-world use yet; there are memory leaks so you can play video but navigating around in the GUI eventually triggers OOM crashes. It's making rapid progress though, and is attracting lots of known names from the Linux graphics community who are helping to move things forwards (even ARM's open-source group are engaged) so in the next couple of months we should reach a point where issues are resolved or reduced enough for proper public testing to start.

Fusion repo = piracy = The only push you will get, is a push out of this forum.

NB: Our Kodi add-on repo will not work on other distros.

No, because Kodi has no HDMI video input capabilities.