Posts by chewitt

    Yes this works (see the post from awiouy in response earlier where he confirms) but as you correctly suppose, you cannot have Kodi active and the other distro active at the same time else both fight over the same hardware resources. This is also the case with the current Chrome addon for x86/64 (X11) where Kodi needs to be stopped while it's active - and it's one of several reasons why we regard the current "solution" as a bit of a hack and that something fully integrated into Kodi is real way forwards. However the exploratory work that's already been done in this area by Kodi developers has also shown that it's not a trivial capability to add, so while you are correct to be non-defeatist (it's not impossible and someone just has to do it) we're also correct to be realistic about the likelihood of it being done anytime soon (in the last 10-year period, nobody didi it).

    Casting would also be nice and a solution for many users, but that also requires Kodi support and the developers are really not fans for proprietary crap (a lesson learned the hard way) so the reality of there being multiple "standards" for casing depending on macOS/Win/Linux/iOS/Android means it's also a reverse-engineering/bad-code and political issue. So native casing isn't likely to be a fruitful way forwards either.

    So on this specific topic "get a chromecast" or dual-boot with Raspbian/Armbian/etc. are "sucky but sensible" options and IMHO chromecast would be the more practical to live with.

    I don't see Rockchip as particularly better than Amlogic when it comes to upstream/mainline development. Both vendors are mainly still focussed on legacy codebases (4.4 for RK and 4.9 for AML) and despite RK having a GitHub presence both vendors work mostly in private repos. And since the focus of all new code is (or should be) the upstream kernel both vendors have similarly sized/active teams of independent kernel maintainers (the kernel prefers non-employees). Both vendor mainline efforts are missing stuff and the only real-world difference is in what the missing bits are. Right now (from a mainline readiness LE oriented viewpoint) Amlogic is actually the more usable one due to RK missing the VPU.

    Most of the missing Amlogic components (10bit output, framebuffer compression methods and audio) either have funded work packages lined up or a known/probable contributor who's expressed interest in working on it. The one item that has no "owner" yet is the hardware deinterlace capability. Support for ge2d exists in the legacy kernel but like many things in the BSP kernel, the existing code is poorly structured and over-complex (a house that has been extended and remodelled over time) and it won't transplant directly to V4L2. So it's necessary to reimplement and not simply forward-port the existing code. Could that be something of interest?

    LE has zero interest in supporting X11 on ARM hardware. In fact we're going to remove X11 from x86/64 hardware in the future too (which kills the current browser support there). So the remaining approach/solution which also works today is to run a browser like Chrome via docker. In essence you're going to run some kind of desktop distro (with X11 and the stuff it depends upon) in a container in the background. That probably doesn't do any favours for performance, but you get a working browser.

    Before you ask, there is no nicely typed up guide on how to run a browser in a container. It's been done before though.

    I normally recommend people search wikidevi for devices using the ath9k_htc driver as it's in-kernel and fully open source and well written, but S805 requires the 3.10 kernel which has prehistoric support for everything so I no guarantees that it would be supported either. Hence the modern kernel comment I made in my first reply. Plan B.. get an old Apple a1rport from eBay and use it as a wireless bridge via Ethernet and eliminate all driver hassles. The last one I acquired was $20.

    In the mid-term the difference between T860 (RK3399) and T820 (S912) should become moot because both will be using panfrost. The current advantage of RK3399 is that the T860 blob is available publicly and it's the more stable option, and we can elect when to make the change vs. S912 which can only use panfrost. Fortunately panfrost is making rapid progress :)

    Your options are:

    a) Wait patiently for 12 months (maybe) until there's viable mainline kernel support for S805 hardware

    b) Swap the S805 device for a Raspberry Pi or Intel NUC device (anything running a modern kernel)

    c) Swap the unsupported USB wireless dongle for something that is supported

    People have compiled Chromium to be used with a GBM back-end and a large number of people have pointed this out to us since we are generally moving towards a V4L2/GBM video pipeline in Kodi. There's no guarantees this will be viable though, and we've maintained Chromium in the past and found it to be a rapidly iterating pain in the rear to keep current. TL/DR; don't hold your breath.