3 ms·

> What's wrong with pixel drivers for instance? I'm of course not talking about those written by e-waste ODMs like Tinno who can't even release GPL kernel sourc

> What's wrong with pixel drivers for instance? I'm of course not talking about those written by e-waste ODMs like Tinno who can't even release GPL kernel sources properly A couple of issues , back from my sailfish os porting days (haven't touched it in half a decade so things might have changed): 1. You would still need to run a lot of Android user space to make use of these drivers. We had a separate second init system that runs a stripped down version of Android init, starting enough services to make use of these drivers. 2. These binary drivers are tied to the kernel and Android versions that were released with the phone. So if you wanted some of the newer kernel features (back then it was like better container support), you're out of luck. Usually, all this means you rely on a lot of hacks to fix some bugs... And porting takes a lot of time and effort.

chaosharmonic 2mo ago
One thing that has changed in around that time (maybe) is that GKIs[1] are now standard across (Google-branded) Android devices. Board/SoC support is handled via kernel modules now. The builds are directly from the Android Common Kernel, and an explicit goal is to be able to upgrade kernels on-device. (This has actually been demonstrated on Pixel devices, though I'm not sure how widespread it's been across others.) The Common Kernel also doesn't take contributions, and specifically encourages vendors to just upstream their drivers instead. Not that this fully solves the problems you're describing, but Android as a platform has become more intentional about dealing with kernel fragmentation and making itself more structurally friendly toward mainlining. For the Pixel specifically, Google actually is working to upstream its hardware drivers and enable devices to boot off mainline. [2] [1] https://source.android.com/docs/core/architecture/kernel/generic-kernel-image https://source.android.com/docs/core/architecture/kernel/gen... [2] https://lpc.events/event/17/contributions/1445/ https://lpc.events/event/17/contributions/1445/

chaosharmonic 2mo ago

One thing that has changed in around that time (maybe) is that GKIs[1] are now standard across (Google-branded) Android devices. Board/SoC support is handled via kernel modules now. The builds are directly from the Android Common Kernel, and an explicit goal is to be able to upgrade kernels on-device. (This has actually been demonstrated on Pixel devices, though I'm not sure how widespread it's been across others.) The Common Kernel also doesn't take contributions, and specifically encourages vendors to just upstream their drivers instead. Not that this fully solves the problems you're describing, but Android as a platform has become more intentional about dealing with kernel fragmentation and making itself more structurally friendly toward mainlining. For the Pixel specifically, Google actually is working to upstream its hardware drivers and enable devices to boot off mainline. [2] [1] https://source.android.com/docs/core/architecture/kernel/generic-kernel-image https://source.android.com/docs/core/architecture/kernel/gen... [2] https://lpc.events/event/17/contributions/1445/ https://lpc.events/event/17/contributions/1445/