Posts by chewitt

Quote from noblock

chewitt, now, when using the mainline kernel, everything is the same at the linux packages level between Allwinner and Amlogic. With one exception, the m2m cedrus and meson implementation are not compatible. Is there some standardization / merge in progress on that matter?

The video pipelines for Amlogic, Raspberry Pi and Exynos have stateful decoders while Allwinner and Rockchip have stateless decoders. It's not possible to combine them into a single m2m implementation as stateful/stateless work in fundamentally different ways, although we are working to minimise the differences and have ffmpeg mask the implementations so there's still a single/common interface with Kodi. As there's no prior art for anything it's a "two steps forwards, one step backwards" kind of process, and there's still a ton of code to write, but the direction is still forwards, and each month ever more bits of the big jigsaw puzzle are falling into alignment.

You'll get the DTS core of HD formats on Raspberry Pi, but that's all.

Yes, within the limits of the audio formats that Raspberry Pi supports.

How you burn the image (USB/SD Creator or Etcher) has nothing to do with how the image runs. If it boots, it boots.

Try running "systemctl stop [email protected] && systemctl disable [email protected]" and reboot.

The audio drivers for G12 hardware are not fully upstreamed yet, and since it's Easter week and lots of people downed tools for a while that's not likely to change for a bit. As has been clearly written (but not read) in previous posts, only USB audio devices will work on G12 things right now.

There are no Kodi add-ons or open source applications (apart from suites like LibreOffice) that play pps files.

autostart.sh is run at the start of the userspace boot process and if you want things to happen in the background you will need to (background)& the commands. If your script fails un-gracefully it can block the boot process.

Kodi does not support playing PowerPoint files. Powerpoint can export the slides as a movie that Kodi can play.

Support for installing to VIM emmc will be added to the mainline kernel AMLGX image. It's not there yet, but soon.

There's a bug in Kodi that should be resolved in the 18.2 update.

The DesignWare HDMI driver used in Amlogic (and Allwinner/Rockchip) devices still needs to evolve 10-bit video support, and the Intel developers still need to get their HDR and colorimetry patches merged into the upstream kernel (still work in progress). In the last week or so we've started to poke the Kodi side of that work using Intel hardware where the dependences in a more mature state, but this is really a green-field area for all Linux hardware, so there are no prior examples to crib things from and we are literally making up the rules (and code) as we go. In the mid/long-term I have absolutely no concerns about LE (and Kodi) having A1+ support for HDR .. and hopefully in the near future I can write a blog post to explain what's going on in the background and why we're rather confident about that

As long as the LE release that you had installed on the 3B also supports 3B+ then you can just swap the card. If not, update to latest first and then swap and all should be fine.

tools/docker in our git repo, but our distro image/buildsystem environment isn't going to help you develop for our OS. I wish I could help more, but I am not a python developer.

wpa_supplicant exists but networks are configured through connman, and both are achieving the same result as the modprobe command. I'm not sure "EU" is a correct value since wireless regulations are normally country specific, hence DE/FR/UK etc. are used.

Use the Generic x86_64 image .. shouldn't be any drama (famous last words)

G12A support (which is the target of commercially funded work) needs to reach the same level of incomplete as GX and then video work (which is largely common to both) can continue. There is already 4k 8-bit support, but as most 4K video uses 10-bit formats that's not so useful. Intel's HDR plumbing is also starting to fall into place so we've started to look at what Kodi needs to use it. There is also refactoring/rework of the ffmpeg stateful code as we learned lots from writing stateless support for Allwinner/Rockchip. It's all green-field coding so it's often a "two steps forwards, one step backwards" process. The nice thing is that we've successfully positioned Kodi (and LE) as the go-to demo application for a number of development efforts which is attracting some nice contribution from the wider Linux community - although a lot of the activity isn't public visible. GXBB devices like the WP2 have a few quirks that need to be ironed out (currently a bug in audio support) but we'll circle back on that generation shortly.

The X96 device tree describes the x96max remote, hence it works OOB. If you can point me at a working remote keymap for the Y5 we can create a device-tree that does that same thing.

Some comments:

WiFi on S905X2: may not be supported for a while yet, or at all. S905X2 has a design flaw in how the SDIO module is internally connected and while an egregious hack/workaround exists in Amlogic's 4.9 kernel it's looking unlikely that a cleaner solution acceptable to upstream kernel maintainers can be found. We might attempt a mainline kernel version of the egregious hack through a local patch, or since the majority of users stream media over Ethernet anyway, we might just leave it unsupported and avoid the support/maintenance work. The issue is allegedly resolved with the S905X3 chip which is already being sampled to manufacturers.

Device trees: The mainline kernel avoids the silliness of 1G/2G/3G variants needed on the legacy kernel which makes life easier, but we will still need to figure out (and then upstream) the device trees for popular devices. I'm keen that device trees are sent upstream so that devices can be uniquely identified by "compatible" strings in the device-tree, as this allows simple things like the remote control keymap (also sent upstream) to be described in the device-tree for a better out of box user experience. Submitting changes to the kernel is not the most straightforward process but if non-coding folk like myself can figure it out (my personal collection of one-line kernel changes is slowly increasing) the bar is not set impossibly high.

arm vs. aarch64: performance is marginally higher on aarch64 but arm allows us to support widevine drm (which is not available in 64-bit format) so arm is our preferred option and official nightlies and the Kodi binary add-ons to match them, once they start, will be arm only. Maintaining a single image for all Amlogic hardware (two images until panfrost evolves bifrost support) is a bigger win than the minor performance gain. On G12 hardware the future gain from running the CPUs at full speed (at the moment they are under-clocked) will dwarf the architecture difference.