The 'Generic' LE12 image supports Intel/AMD GPUs, the Generic-Legacy image supports nVidia GPUs; although only as far back as the 340.xx driver series. Also note that 340.xx has been dropped from LE13.
Posts by chewitt
-
-
I am openSUSE tumbleweed desktop KDE.
You're in the wrong forum then. We create and support LibreELEC not openSUSE
.. desolé -
I don't think SD card capacity makes any difference, and (as mentioned above) the patches I added for LE12 are missing from LE13 so it's more of an omission than a regression.
-
Do you need to build it?
Yes/No .. It's not mandatory, but building from source gives clearer provenance, and often gives flexibility around packaging.
-
I am using Argon case with SSD port
The number of users that show up with an Argon case and swear it cannot possibly be their magic/favourite case; who then go quiet after we insist they remove the board and test playback without it .. is notable. So, remove the board and test.
-
Current images have intentionally dropped a load of "WIP" Linux kernel patches because I've had some long periods of downtime on LE during 2024 and I basically forgot what patches were added for what purpose on what device. I have fuzzy recall a change to SD/emmc speeds is needed for U9-H, but I'll need to poke around in old kernel trees.
NB: I don't think the panfrost error is itself important, it's most likely a casualty of overall OS instability caused by the I/O issues.
-
Do you see any objection to this choice ? (for 4K HDR (10bit), DTS/5.1 audio and 3D content)
Yup, LE (AMLGX) does not support HEVC hardware decode on G12B chips like the S922X used in the N2/N2+ due to long-standing bugs in the codec driver that lock-up the board with 10-bit media, so hardware decode is intentionally disabled and this limits the device to 1080p output. There is also zero 'hardware' 3D support, although ffmpeg might do things in software?
CE has released images based on the vendor kernel that are allegedly more functional, but I have no idea if they still support 'old' hardware like the S922X or what state 3D support is in - it's always the bastard child that's been forgotten about. For informed info on CE support you need to ask in their forum because I pay zero attention to their releases.
OSMC vero devices might be a good choice. They also use the use the Amlogic vendor kernel, but (at the risk of being heckled by CE fanbois) are better maintained than CE based on user feedback I've seen.
Cheap Intel HW is sometimes attractive but there are regular user reports of issues with native HDMI vs LSPCON based HDMI output and with Intel breeding new chips faster than drivers get written .. Intel support is not as reliable as it used to be.
RPi5 doesn't support 3D either, but is rock solid for everything else and the higher initial cost provides better long-term value than chasing bugs in cheaper hardware. Source an old (and cheap) RPi3B+ on LE 9.2.8 if 3D support is important to you, as that's the last hardware/software combo to really support it with LE.
-
Do not attermpt to use old vendor-kernel device-tree files found on the internet, they will not work.
Do not rename files to dtb.img and kernel.img etc. - this also will not work.
The supported device-tree files are in the amlogic folder on the SD card.
This is all explained in the wiki instructions you didn't read.
-
Odroid C2 uses an S905 chip which does not support HDR. The original vendor codebase can convert HDR to SDR on-the-fly using an image processing function called ge2d, but this capability has never been implemented on the upstream kernel codebase now used in current AMLGX images. S905X (one generation newer) supports 8-bit HDR output, and S912 supports 10-bit, although only 8-bit is currently implemented in the unfinished upstream code.
RPi5 is the current go-to recommendation for something simlar with excellent software support. The 2GB model is fine for normal LE use, unless you want to run Docker containers and other things in the backgroud, then 4GB or 8GB will be more appropriate.
-
Read this: https://wiki.libreelec.tv/hardware/amlogic - You need to use the "box" image.
The generic p212 device-tree will probably work.
-
The "Failed to start Xorg" message implies you are using the Generic-Legacy image? - Unless the message needs to be updated. You should be using the 'Generic' (non-Legacy) image. If you are, AlderLake GPUs should be supported in the LE12 and LE13 kernels and you need to share the system log from the device so we can see more about the boot process. Although Kodi hasn't started the rest of the OS will be functional so Samba is running and accessing the Logfiles SMB share will generate a log zip file. Or you can modify kernel boot params in syslinux.cfg to add 'ssh' which forces the SSH service to start on boot so you can login.
-
evdev:input:b0005v06E7p8144*
KEYBOARD_KEY_c0041=enterThanks, I'll add that to the default hwdb file for LE13.
-
It's not something I've ever looked for so I honestly couldn't tell you, and I suspect the other 99.999% of users in this forum will be in the same position. Hence the lack of replies.
Take a backup, then load each Kodi skin one-by-one to check. If you find one, revert to the backup and then install only that skin. If you don't find one, revert to the backup to clear the 10+ other skins you installed from the config (even if they are not used they are installed and will be updated etc.).
-
It was going to be last week, but we expect Kodi to release 21.2 in early Jan so we'll wait and combine with that.
-
I understand that this is all that is needed for the latest version of CoreELEC to work perfectly on a Dreambox
LibreELEC is not CoreELEC .. If you want to run CE you're in the wrong forum. CE is someone else's problem.
-
-
What exact LE version did you update from? .. and to?
-
Kernel drivers need to be compiled for the specific kernel version running and 'dkms' drivers automatically rebuild (recompile) when a change in the kernel version (magic) is detected. Compiling requires header files, so that's easily explained.
Logs show the hardware being probed and the wl driver loading. If that doesn't result in a working interface it's probably due to a difference between current kernel APIs and ageing/un-current driver code. The kernel evolves and moves (drifts) forwards while the driver code is static, so at some point the kernel has drfted far enough for things to stop working.
I have a suspicion the driver stopped working (although still compiled) some time ago, but few people use hardware old enough to need 'wl' these days (most people use Ethernet) so the breakage has gone un-reported.
As per earlier comments: a decent USB wifi stick or replacing the PCIe module are probably the best options. The latter is probably cheapest although cracking older 'mini' boxes open is quite a task.
