Posts by chewitt

LE12.2 and LE13 codebases should be using the same kernel/firmware and connman/iwd versions.

Start with building a standard image. Then (outside the LE buildsystem) clone ConnMan sources, and make/commit your changes to the files. Then create diff patches of your changes (git format-patch) and move the patch files to packages/network/connman/patches and rebuild the image; the presence of patches will be detected and the buildsystem will rebuild connman (only) and package a fresh image. Transfer the .tar or .img.gz file to /storage/.update/ on the RPi and reboot to update.

RK3288/RK3328/RK3399 depend on a different kernel patchset which I am still trying to encourage (re)work on from knaerzche and Kwiboo. I'm not really able to judge the state of things and I don't have working test hardware. I'm not suprised there are issues, and I don't plan to do much about it for now.

RK356X is expected to have issues with page faults as there's been zero development on fixing buffer sizes. As I don't really code, I plan to have Claude AI investigate that problem, but first I need to prepare all the relevant source materials for the prompt, and then I'll need to have enough tokens/time to let it work on the issue. AV1 isn't supported on the hardware.

It's not uncommon to find Android u-boot firmware that hardcodes the same MAC for all devices, so LE normally (re)creates a new MAC from the CPU serial which is guaranteed to be unique.

AFAIK that's been fixed (worked-around) in RPi kernel code.

Most S905W boxes have SDIO WiFi chips like SSV6501P that aren't supported in the mainline kernel. Drivers can be found for the 3.14 and 4.9 Amlogic (Android) vendor kernel, but they don't compile against the mainline kernel due to major crypto differences that were made in mainline several years ago. One of the Armbian devs did manage to evolve/fixup the SSV6501P driver enough to work on Rockchip boards, but he nuked Amlogic support in the driver in the process, and it doesn't work that great on Rockchip so AFAIK nobody has bothered to reinstate Amlogic support. Even if it was done I'd refuse to include that driver in LE images as the driver code looks like it was authored by a first-year computer science student (and that's being rude to students); it's garbage.

Look at https://wiki.libreelec.tv/configuration/…ration-advanced for IR remote things.

#!/bin/sh

# SPDX-License-Identifier: GPL-2.0-or-later
# Copyright (C) 2009-2016 Stephan Raue ([email protected])
# Copyright (C) 2017-present Team LibreELEC (https://libreelec.tv)

token=$(echo "LibreELEC-9.2" | sha256sum | cut -d ' ' -f 1)

cat "$@" | curl https://paste.libreelec.tv -F 'file=@-' -H "Authorization: Bearer ${token}"

Save that ^ as /storage/newpaste and make it executable with chmod +x /storage/newpaste

Then do pastekodi -c | /storage/newpaste and it will generate the URL

ix.io has been down for years, hence we use our own paste server these days.

You can interrupt boot to enter the u-boot console and set things in the u-boot environment (env) if you ave a USB debug UART tool connected, but I don't think that will get you anywhere as I'm not sure mainline u-boot supports that kind of GPIO power-on control on Amlogic hardwar; the mainline codebase is rather minimal and focussed on not much beyond booting the board. I'd suggest asking Q's in the Armbian forums as their devs are more up on this kind of topic, and while LE is a little different to Armbian, they are also using upstream u-boot not the downstream vendor sources that CE are using.

Banned add-ons are present, no support.

Official:Forum rules/Banned add-ons - Official Kodi Wiki

Use full path to the binary, e.g. /usr/bin/connmanctl not just connmanctl as the bash script doesn't have knowledge of $PATH from the bash interpreter, unlike the console which does.

The gold standard for support is currently still an RPi5 board; not the fanciest specification but definitely the most reliable. Rockchip is making strong progress though and is now ahead on media codec support. Some audio issues need to be resolved for RK3588 to steal the crown from RPi5, and support for the trickle-down derivatives and slightly older RK hardware that share capabilities with the RK3588 chipset also need some attention.

LE10+ uses a completly different (ground up rewrite) display pipeline to LE9.2, so yes there is a HUGE software difference. The main way this manifests for users is that almost all config.txt tweaks for forcing video and audio output used in the older display pipeline are no longer supported using config.txt, and are now achieved using standard Linux DRM methods/properties.

It would be helpful if you described how everything is physically cabled/connected, and please share the "pastekodi" URL taken from the LE9.2 and a clean-install LE12.2 (or LE13 nightly) image so we can see kodi/kernel and various bits of config from the systems; the kodi.log on its own isn't giving us the full picture. If the RPi4 is connected to the projector using the HDMI socket nearest the power connector, please also run edid-decode /sys/devices/platform/axi/axi:gpu/drm/card1/card1-HDMI-A-1/edid | paste and share that URL too.

Make sure you set/configure the wireless regulatory domain for your country in LE settings, it can make a large difference to the radio spectrum that's usable.

This is a long running known issue without resolution impacting a small number of users. The issue correlates with poor WiFi signal and is seen with all common manufacturers of WiFi chipsets so the root cause likely resides in common ConnMan or IWD code not device drivers. The only known workaround is reinstating wpa_supplicant support (we removed the wpa_supplicant package from our buildsystem in 2023) then self-building an image using wpa_supplicant instead of iwd.

This patch looks promising https://patchwork.kernel.org/project/connma…[email protected]/ but the author submitted no detail on the problem and we've also seen reports from people self-building images saying it did not resolve their issue, so there's no guarantee that it's the same issue or the correct fix.

This LE13 test image has the patch applied: https://chewitt.libreelec.tv/testing/LibreE…1-tinker.img.gz

Go test and see if it changes anything?

There are no known HDMI audio problems in recent images (and we have a large RPi4/RPi5 userbase) but HDMI audio depends on the EDID data on the HDMI connection. No EDID or bad EDID or connecting to a monitor with no speakers or using HDMI adapters or bad HDMI cables or bad config.txt/cmdline.txt are the cause of most audio problems.

• Ensure the board is running updated RPi firmware (done via LE settings)
• Ensure the HDMI cable is a proper micro-HDMI to HDMI one (adapters frequently cause issues)
• Ensure the cable is connected to HDMI-A-1 (socket nearest the power connector)
• Connect the RPi directly to the TV (no AVR in the chain) then remove the SD card and power on. The board will boot to a status screen and you should see 'EDID = okay' against the active HDMI connection
• Create a new/clean SD card using LE12.2 or a current LE13 nightly to ensure no old/existing config causes issues

If still seeing a problem, put Kodi into debug mode, reboot to get a clean and complete debug log, then run "pastekodi" and share the log URL so we can see the output.

Most USB dongle WiFi devices normally trump on-board WiFi as the antenna is larger (albeit still small) and separated from other chips and RPi5 may or may-not be an improvement on earlier models, it's hard to tell. If you are in a poor/difficult signal area USB dongles also allow you to choose a device that can be hooked up to a proper external antenna. As a rule we avoid making wireless hardware recommendations due to the ephemeral nature of success; what works amazing for one person often sucks for someone else. This page from a linux-wireless maintainer is worth reading: https://github.com/morrownr/USB-WiFi/

Revert of the PR will restore the previous driver to the buildsystem, but you'll probably need to update the driver source version or add some source patches to compile the driver against newer kernels that we are using now; Realtek downstream drivers often break when we bump the kernel major version (hence we dumped them in-favour of in-kernel ones).

The RK3588, RK3567, RK356X images in my test share have been updated to use Linux 6.19.0 and HDR is now working on RK3588 and hopefully RK3576 too (limited tested on RK3588, no testing on RK3576 yet). I'm finding the output a little dark compared to the family daily-driver RPi5 board, but different hardware will always give different results, and most users won't have multiple devices wired up to the TV for comparisons; meaning you can tweak TV settings/profiles to get things as you like.

LE was created using https://www.linuxfromscratch.org principles. It is not a derivative of any other distro. It should boot and run on any type of x86_64 hardware but LE is not a general purpose OS and it intentionally targets HTPC/SBC hardware and will be lacking drivers useful on non-target devices like tablets and laptops. In some cases you can enable drivers in the kernel when building an image. In others not, it depends on the specific hardware you're trying to use and what drivers exist for that device. As a rule we avoid trying to curate lists of "what works best" because the lists are never maintained for long and are outdated; and you won't find lists of tablets in our forum because people rarely use them and we don't have experience with them. There's not much need for touch-screens among our userbase so support for them is a bit of a grey area and our experience is limited/non-existent.

Our 'Generic' image runs Kodi under GBM, while Generic-Legacy (not something that I'd guarantee is around for much longer) runs under Xorg. It can also run under Wayland which exists in our buildsystem to support the Lakka retro-gaming fork that leverages our codebase; but we don't release LE images that use Wayland (as no need to) and our buildsystem is missing lots of things you would need to create a desktop environment.

Kodi implements its own rendering engine so you'd need to learn their UI and skinning process to do something. Kodi plays media well, but it is not a kiosk systema and does not support ebooks, email, or much in the way of communications. It could of course do more, but that's down to you and your development skills. IMHO you'll get further faster using a conventional distro or perhaps Yocto/OpenEmbedded which has a much broader hardware audience and more packages in its ecosystem.