S905X can't output 10bit video to tvs?
GXBB/GXL can read 10-bit and output 10-bit, but there's an intermediate stage that converts to 8-bit for processing. GXM is fully 10-bit.
S905X can't output 10bit video to tvs?
GXBB/GXL can read 10-bit and output 10-bit, but there's an intermediate stage that converts to 8-bit for processing. GXM is fully 10-bit.
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?
buzzmarshall autoscript.sh runs very early in the boot process and the network stack is almost certainly not up/ready at that point.
cpumac: add cpumac package · chewitt/LibreELEC.tv@e011b00 · GitHub is how I solve this in my test images.
It means right now we are focussed on core video/audio support more than figuring out some of the packaging mess required for WiFi/BT firmware and nvram files. It's something we need to align for Allwinner, Amlogic and Rockchip.
RockPro64 is a popular RK3399 board among a variety of RK developers.
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.
RK has a native 10-bit pipeline, same as S912.
Kodi supports Wayland as the long-term successor to X11 (a successful Kodi GSOC project from 2017) and there are several desktop oriented distro's that support Wayland and people who actively tinker with that combo. LE has no need or plan to use Wayland though. Maybe the lack of browser in Kodi (e.g. via CEF) will be resolved.. nobody knows.
u-boot stores the MAC in efuse and the kernel reads the values back from efuse
Have you looked at the Bluetooth Audio Switcher add-on in our repo? .. this auto-switches Kodi to pulseaudio when BT audio device is paired to the HTPC and reverts to alsa (e.g. HDMI output) when the device un-pairs.
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.
Probably not. Android will support whatever WIFI card is in the box and not much else.
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.
^ that video shows update of an old/existing OpenELEC install being updated to LibreELEC. It does not show first-time install of LibreELEC using an S905 image. If you had some random community image installed before you need to clean install.
If you want to pirate movies you're in the wrong forum.