Posts by chewitt

You can try the AMLGX "box" image here: Index of / - edit uEnvi.ini to use device-tree files with "sm1" in the name. Удачи.

You haven't shared any details of what kind of crappy Android box it was (Allwinner, Amlogic, Rockchip, etc.)?

Quote from havhav

I know it is H3 and not aml..

^ devices using GBM/V4L2 (Allwinner, Amlogic, NXP, Raspberry Pi, Rockchip, etc.) do not support VNC and that's not likely to change anytime soon.

Quote from ghtester

I know, maybe I am wrong but I still believe in this case these commands should not be queued.

autostart.sh is run at the very start of usespace boot, so the network is not started, kodi (which runs docker via an add-on) is not started. So running the docker command at that point will *allways* fail, and (backgrounding)& is the correct approach.

The case statement ^ above was incorrect, not sure if it was copy/paste typo or what but I edited it to be correct.

As lrusak says, look at systemd logs

It's not trivial and there are other things with a higher priority right now.

Try setting DRIVER_ADDONS_SUPPORT="yes" but then (lower down) set DRIVER_ADDONS=" " (null)?

Quote from Andrew_K

is it possible to use the "sm1_s905x3_4g.dtb" device tree from the LibreELEC project in the Armbian project to add device support?

If Armbian = Linux 4.9, then probably it can be used, because that filename is from a Linux 4.9 vendor kernel. It is *not* from a LibreELEC image because we use Linux 5.11 and the filenames for A95XF3-AIR in LibreELEC images are:

meson-sm1-a95xf3-air-100.dtb

meson-sm1-a95xf3-air-1000.dtb

Stats show 4GB is the most popular choice but from a pure technical perspective 2GB is all you need for LE use. Avoid the 1GB model unless you only plan to use 1080p media. I find running from an SD card perfectly fine (and nothing extra hanging off the case).

LE master branch (currently LE10) is still using X11 so the changes would not be accepted even if PR'd. Generic will not switch to GBM/V4L2 until a future point. It's not been seriously discussed whether this will be an interim release like LE 10.2 (K19) or LE11 (K20) yet, but my guess is the latter.

Also note: if the add-ons in question are on the Kodi banned add-ons list, i.e. pirate add-ons, we really don't care.

I'm told this was fixed in PIN cleanup by MilhouseVH · Pull Request #159 · LibreELEC/service.libreelec.settings · GitHub last April - so please test a currently nightly image and confirm.

Kodi supports binary add-ons which can add functionalty. One of the available add-ons (installed as a dependency if needed, so it's not a starting point for gaming) is libretro libraries which allow Kodi "RetroPlayer" to run. You can also load emulator cores, which sometimes depend upon BIOS images to work, allowing you to run a game. In the retro console world games are often ROM dumps of cartriges. For example:

Open Game ROM > Select Emulator to use > Kodi loads dependencies and maps controllers > Play Game.

Retro gaming is inherently a bit complicated due to the number of moving parts, frequent choices of many different emulators for some of the more popular platforms (each with different quirks), with some emulators using licenses that prevent redistribution (so they must be installed not bundled in a pre-configured way) and Kodi is missing a "Game Library" that allows you to map/store frequently used or preferred combinations.

BUT .. it does work, and games are fun

For more specific advice you'll need to explain what hardware bits you have and what games you are trying to play? Note that Kodi does not provide game ROMs and we are not going to discuss where to obtain them.

I'm not aware of any issues with CEC. It wasn't working for a whlie recently due to a wrong kernel config option but that got spotted and fixed. I don't use it myself though so it's always unknown territory.

I can see the correct BT firmware is loaded now. I'll be dropping you an email to ask for permission to use a real-name and email address for "Tested-by" signature when I send the device-tree and keymaps upstream to the kernel.

Quote from Shoog

Hows that strategy working out for your users Chewitt ?

It could be better, but I have a thick skin for armchair pundits like yourself and prefer to focus on the still reasonable numbers of LE (and now CE) users running older releases on older hardware. I'm confident they are more positive about someone working to bring the latest Kodi releaase on a modern efficient kenel to their board/box, even if progress is woefully slow.

Quote from Jocke.Sve

And pressing keys there is (close to) as visible as everything else?

Correct, but still not as obvious to kids/spouse as showing the PIN on the screen

Can you share dmesg from one of the boxes again - I want to confirm the BT firmware is loaded so I can get the changes merged.

I've flagged it in team chat. I agree it should be hidden when entering the PIN.

CE have a more functional but rather ugly and complicated vendor kernel codebase. LE has an much cleaner (modern and better implemented) kernel codebase which also respects backwards compatibility and supports open source GPU drivers (so S912 is not an issue) but it's lacking mature media drivers. CE's issue is that Amlogic supports "current and one previous" hardware generation; meaning Amlogic kernel devs do not maintain backwards compatibility with older devices and frequently break support foor older devices when hacking new features in. CE wants (or needs) to use the latest Amlogic kernel drop which presumably drops support or makes life difficult. This is 100% why LE (and Team Kodi) are persuing a path based on Linux kernel standards that breaks the cycle, but it's not the easiest route, in part because we have to write the standards as we go.