It's worth pointing out that the Linux kernel currently has no HDR support. It is active "work in progress" from Intel, albeit rather slow progress due to the large number of other drivers (and companies with commercial interests) that will consume the same changes once merged (so lots of cooks in the kitchen sharing their opinions). One of the component patch series' is now on it's 17th iteration so things are hopefully nearing a conclusion.
Posts by chewitt
-
-
Yes, we will support the Odroid N2, but using a mainline kernel image not Amlogic legacy kernels. Coming soon
-
Run "dmesg | paste" a couple of mins after clean boot and share the URL here
-
Kodi GBM/V4L2 support is still in a fluid state as the underlying changes to Linux kernel things aren't cast in stone yet, but at some point they will become a more static target, and from that point forwards change becomes much easier to manage. Support on the Kodi side really comes down to GBM/V4L2 providing a single code-path into FFmpeg which handles a small number of different code-paths (stateless, statefull, vaapi) depending on which SOC or GPU hardware is being used. There are 5-6 developers actively working on that area of code; roughly representing RK, Allwinner (stateless) and Amlogic, Raspberry Pi (statefull) and Intel/AMD (vaapi) interfaces. Once you drop lower in the stack to the kernel driver code things appear to be more of a one-man effort because kernel DRM drivers tend to have a primary maintainer driving things forwards, but in all cases there's a community of other developers actively testing and contributing towards that driver and the surrounding stack. LE tends to have a single developer 'representative' among a group of developers working on code and influencing direction. We actively and successfully position Kodi as a fun and useful test application, and since many of the community developers have competing professional or commercial interests we often fulfil a role as a neutral test-case and it's common to see "good Kodi support" somewhere on the written agenda for V4L2 graphics initiatives.
Rockchip (and others) are in limbo at the moment while we wait for some upstream kernel changes to land. This is completely out of our control but it will happen (as big companies like Intel need it to) and then we'll start to show progress again. Raspberry Pi and its legion of supporters are ultimately dependent on the same changes and will also be moving wholesale to the Kodi GBM/V4L2 stack for LE10. Many things become interconnected in a way that makes it impossible to promise that Rockchip support will not drop off, but equally these changes makes it fundamentally more improbable this this will occur
-
Users sometimes mistake LE being a small and efficient Linux distro for it being ideal for using on old hardware, but our focus is on current and recent hardware so we are frequently missing drivers and support for older devices. That said, unless you tell us exactly what the hardware is (and share the dmesg output) all we can do is make broad statements ^ and guess at the issue.
-
Your box is from a vendor who saved pennies by not securing a unique MAC address range for their products. As a result the NIC in your box does not have a programmed (fixed) MAC address. Under Android the kernel has been hacked to assign a static MAC address (normally unique to the 20k or so boxes in the production run). Under Linux the kernel hack doesn't exist. If you're lucky you get a different static MAC. If you're less lucky the kernel will generate a random MAC that changes on each boot. If can be "fixed" with a udev rule or systemd service that corrects it during boot. There's some threads on the topic in this forum if you search for them.
-
Not even remotely possible.
-
Updates are enabled, but we only publish for official images. What hardware (and image) are you using?
-
It's really quite simple: inputstream.adaptive can leverage the widevine libs if present. On Android where some devices have L1 certificates this allows full hardware decoding of the stream. On Linux there are no open devices with L1 widevine support so inputstream.adaptive pretends to be a web browser with an L3 certificate that most content providers allow up to 1080p streams for. Some providers allow up to 720p streams. Some providers encrypt both video and audio (Netflix is one) while others only encrypt video which results in a lower decryption load; and on low-spec hardware this can be the difference between coping and not-coping with 1080p.
-
What's the use-case for needing LE devices in a swarm?
-
The police call it "eliminating suspects from your enquiries" .. I wasn't expecting a result, but wanted to know either way. The changes prevent the issue where we attempt (and never remove) ipv6 servers from the list of possible servers to use in addition to ipv4 servers.
-
You're better off asking in the Kodi forums where content add-on developers hang out.
-
OSD is a core Kodi function, but it is skinnable. So the dirty hack is to create a custom skin that removes the OSD, but then you remove all of the OSD and not just the start bit. To change things so there is no OSD at the start (but overall retaining the OSD) would require core code changes.
-
Discussion on how to bypass GeoIP and break service provider TOS will put this thread on the wrong side of forum rules.
-
I am 100% confident that widevine content is software decoded. There may be some other issue, but further diagnosis needs a debug log.
-
Anything that you play via libwidevine is software decoded so you're dependent on the capabilities of the CPU and most ARM boards are basically weak in this area. You might find 1080p is too much and 720p or even SD are the maximum possible.
-
-
What WiFi chip is in the device. What driver is being used?