Armbian adds all sorts of non-mainline Linux kernels and other stuff in order to achieve the hardware support it does have. Other more standard distros like Debian or Fedora don't do this.
> Well, do you want things to work or are you willing to wait years until things are mainlined?
What I want is for the SoC vendors to actually learn how to participate in the kernel process. Design their drivers from the ground up to be maintainable and mainlineable.
The problem with "wanting things to work now" that we've seen over and over and over in the ARM SoC world is that each family of chips ends up with its own fork of the kernel which never gets mainlined because of one or more of the following:
* It can't actually be compiled as provided
* Successful compilation depends heavily on the build environment which is undocumented
* It depends on binary drivers
* It is written in ways that do not meet the standards of the kernel
* It modifies kernel interfaces in ways that break other drivers
* It's just bad code in general.
When this happens the vendor might update it a couple of times over the product's profitable life but inevitably they will stop doing so. If there's enough of a community around the platform and they're lucky enough to have complete source it's sometimes possible for the community to take over development of the fork and try to port the vendor code to newer kernels while slowly cleaning it up. Most of the time though there's a binary driver somewhere critical to many if not all users which will only work with a certain range of kernel versions, at which point the community is left supporting an obsolete kernel and mostly just backporting relevant fixes rather than gaining anything new. Sometimes there's a way to shim an old driver to work with a new kernel, and sometimes a driver for a newer piece of hardware from the same vendor can be made to work on the older versions, but in neither case can it be counted on.
The worst part IMO is that it's usually not even a LTS kernel that these vendors decide to settle on, it's all too often one that was obsolete and unsupported before the SoC was ever in the public's hands. If you're going to launch a Linux-based product with no intent of mainlining the kernel code at least make it run either the latest LTS or SLTS kernel.
It doesn't take years to get code mainlined, lots of vendors are doing it every day for hardware that hasn't even been released yet. A lot of SoC vendors either just don't care or actively don't want to.
My definition of "work" is a Linux kernel that can be upgraded as CVEs are discovered and new features added. Modified versions of Linux usually aren't that, much of the time they are stuck on the same kernel version, which eventually leaves security support periods.
That's the thing, it forces me into a specific distro/kernel where the stuff that I actually want to run isn't available.
I have a pair of Orange Pi 5Bs and they didn't really replaced my old Raspberries after spending more time on it than what I was initially willing to spend on my upgrade.
