You're posting your unnecessarily bolded text in the wrong forum. Our interest and [limited] expertise in Rockchip hardware is focussed on mainline/upstream codebases, not downstream vendor garbage, and we don't use Yocto/OE, and we loathe hiding things behind secureworld.
--- a/projects/Generic/linux/linux.x86_64.conf
+++ b/projects/Generic/linux/linux.x86_64.conf
@@ -2442,7 +2442,11 @@ CONFIG_SKY2=y
# CONFIG_SKY2_DEBUG is not set
# CONFIG_OCTEON_EP is not set
# CONFIG_OCTEON_EP_VF is not set
-# CONFIG_NET_VENDOR_MELLANOX is not set
+CONFIG_NET_VENDOR_MELLANOX=y
+CONFIG_MLX4_EN=m
+# CONFIG_MLX5_CORE is not set
+# CONFIG_MLXSW_CORE is not set
+# CONFIG_MLXFW is not set
# CONFIG_NET_VENDOR_META is not set
# CONFIG_NET_VENDOR_MICREL is not set
CONFIG_NET_VENDOR_MICROCHIP=yModules need to be baked into the image. Something like that ^ should enable CX311 support.
As a general rule we are okay to enable modules by default , but will want to:
In short, user does the research on what's needed, then we can take it over in the long term. We are likely to refuse niche hardware requests if the modules and/or firmware are large in size; we care deeply about being a minimal distro and this is not maintained by adding driver/firmware bloat that only a single handful of users might ever use.
It's not hard to maintain a self-built image. As long as it works, there's no obligation to update and rebuild frequently.
Upon boot there is sequence with "u-boot" logo on the right, and on left, there isl like "uboot 2023.1-dfsg-something from 2025 september or october" - am i right in assuming this is sort of firmware that possibly could be updated?
LE doesn't show any logos or u-boot info on-screen during board so this means the u-boot on eMMC is from some other distro, e.g. some kind of vendor u-boot/kernel Linux image. As a general rule you need to run vendor kernels with vendor u-boot, and mainline u-boot with mainline kernels, because although they are separate things; there's a degree of alignment between them and you will often see random issues when using vendor u-boot and mainline kernel, or vice versa.
If you want to keep the current Linux image on eMMC you might be able to investigate whether there are newer versions of u-boot for it; and whether those work better. If you obtained and wrote a mainline u-boot to eMMC this would probably boot LE better, but may cause issues for a vendor-kernel Linux image. You can also write an LE image to eMMC using emmctool from the console, but this will overwrite whatever Linux is on eMMC.
I've never used it myself, but see https://wiki.libreelec.tv/configuration/pulseaudio
As Linux dominates the server market where optical NICs are normal, it's unlikely that any NIC more than a year old is not supported in the kernel, although LibreELEC probably won't have the modules enabled.
The CONFIG_NET_VENDOR sections define the top-level support for NIC families, but the defconfig is hierarchical and most vendors have multiple NIC families so when you enable a specific family; only then are it's options exposed so the defconfig is never showing you all possible options for all possible modules. If you know the specific NIC hardware tracing the config for it is simple. If you are working with hypothetical hardware it's not.
Instructions on building an image: https://wiki.libreelec.tv/development/build-basics
Then edit the defconfig to enable the module (uncomment and use =m) based on either looking at the file or some Google/GPT research on what's needed, then re-run the build command and the kernel will be rebuilt with the module enabled. Then tranfer the image to /storage/.update and reboot to see if it worked.
Random Q .. what kind of remote control do you use?
What u-boot version/source is on the eMMC module? - If this is present it will be used even if the board subsequently boots KERNEL and SYSTEM from the SD card. If you remove it, then the board uses u-boot from the SD card.
The short answer is "no idea" and it's not guaranteed that what you see if the same as what I see. On my LE13 image there's 100% a bad leak, but I'm running a whole heap of experimental things that mess with DRM planes and buffers and I see the same leak on Amlogic and Rockchip (with the same patches) too. The fact nobody but you has complained before on LE12 is the main thing I find odd, as it's the kind of thing that would attract forum complaints.
Either way, the LE13 patches need a load of reviewing and debugging and that's going to be my (Claude driven development) focus over the next week. Maybe that results in something..
This is our kernel defconfig https://github.com/LibreELEC/Libr…nux.x86_64.conf
Fibre NICs aren't a thing among our domestic userbase, hence there's probably little/no info on the topic, but that ^ file is where to cross-reference the NIC driver that's required for a specific device and whether it's enabled by default or would need to be enabled to work. Some NICs may also require firmware blobs but that can always be solved by dropping things in /storage/.config/firmware folders so they are overlaid on /usr/lib/firmware on next boot.
I'm watching Eurosport on an N150 device and the info overlay shows "vaapi-bob" is being used
LE will periodcally bump kernels to update drivers (which brings general fixes) but we're not aware of a frequently occurring issue and thus no need to take action fixing something.
See if adding video=HDMI-A-1:1920x1080M@60D to kernel boot params (change HDMI-A-1 to match the DRM connector used) solves the problem? - this will force the intial DRM state to 1080@60. As a general rule it's best to leave the Kodi GUI at 1080p and only switch to 4K when needed for playback, see: https://wiki.libreelec.tv/configuration/4k-hdr. I'll guess Kodi currently has a limit on the GUI being 1080p max but the desktop resolution or underlying kernel DRM layer is trying to use a 4K mode.
I was trying to set up Youtube Addon on kodi with the API keys. It worked some days, but now with the nighly build it stopped working because inputstream something is not available...
The repo was bumped and it took a few days to chase down some compile issues. The repo should now be fully populated.
It also looked like I had to increase the startup delay to 45 sec to get the connection working completely.
If the RPi4 is on a wired network, that really shouldn't be required, and something is borked/wrong somewhere.
Start here: https://kodi.wiki/view/Settings .. click icons, learn how things work
The addons server is hosted in a Hetzner EU datacentre on a static IP address that has never changed, so the adult-content list is probably over-blocking on some wrong assumptions about the subnet or perhaps ASN that the IP belongs to.
If you are using the wrong presets when ripping or converting media, change the presets to ones that work on your hardware. If you are stealing the media off the internet and expect all the random encodings that have been used to work on all hardware; a) you will be dissapointed, and b) we don't care about that problem.
It's important to understand that DV is not 'a' standard, it's a collection of them. It is technically possible to implement support for all DV requirements on PC boxes. However there are quite a few technical barriers towards that happening. There are also a pile of legal issues. The technical requirements are slowly being chipped-away at, so there is full support for Kodi on Android (on licensed hardware that follows standards) but only partial support for Kodi on Linux; there are still things missing in ffmpeg and the Linux kernel DRM architecture and hardware-specific drivers. As a result there are many dissinformation threads from DV "experts" in forums that reflect the disconnect between their opinions on on how things work, and actual facts 
There is currently only one known open-source implementation of FEL 5/7 and that's in OSMC, and the term open-source means only that it doesn't depend on closed-source Dolby libraries. However this open implementation depends heavily on the Amlogic vendor kernel (with its own proprietary DRM architecture) and intentionally uses OP-TEE secureworld to prevent an army of Dolby lawyers from inspecting how it's been done, so the open implementation is effectively closed.
