Fairphone suggests Qualcomm is the biggest barrier to long-term Android support
arstechnica.com
arstechnica.com
Even if your CPU might still be supported your other hardware might not. A common offender is camera drivers as far as I know and while you sometimes can still make the camera work it often comes with noticeable decreased quality (as the special patent encumbered closed source image post processing sausage is missing).
Besides that potential but as far as I know less likely offenders include the modem.
Ironically both might be integrated into the SoC which then massively increases the chance for problems.
Right now it is the worst of both worlds. Closed interface for a closed undocumented chip able to execute arbitrary code.
Edit: expanding the acronym, to evade Android/Apache confusion.
What prevents people from using the same drivers for a device on Android 7 and upgrading the OS to 9 or 10? I always understood that drivers would continue to allow the OS to recognize the component that the drivers are for unless something drastically changes on the OS side of things.
Why can't we say "Fuck you, Qualcomm" and continue to use the older drivers for newer OS versions without having to wait for them to officially support it?
I doubt that was the "intent"... perhaps a contributory argument in favour of a non-stable ABI, but I understand the reasons are far more pragmatic: maintaining a stable kernel ABI is a lot of work which could have strangled Linux in its early years.
And likely would still do so toady. I mean we are speaking about the kernel internal API (not the syscall API, which is stable).
Even systems which pride themself for internal kernel API stability do change the API every view years, while often having much less internal (feature/platform support) changes then Linux. Furthermore in android Linux LTS versions are often used which do support a long term stable ABI, potentially longer then certain other more niche systems priding themself with long support.
The problem is when a device is sold the kernel (minus back ported security fixes) is often already multiple years old so even if you use a kernel with 7 years longtime support you still have a good chance to run into problem. And supporting any kernel internal API for more then that time is unrealistic.
Are the improvements worth the cost? I don't know. (For server applications likely yes, but for desktop likely not).
What I do know is that there are clear benefits of micro kernel architectures, even if they are kinda messed up (for a micro kernel) hybrids like windows has.
Lastly the way the kernel API's are designed can also make a major difference independent of the rest. Honestly the Linux kernel API feels much more raw then the windows API, but I only have every written a single dummy driver for each platform and that was quite a while ago.
NT has been shifting towards running more driver-code in user-space, as has macOS as well, especially with UMDF (especially for USB devices) and for graphics drivers, which are historically the #1 cause of BSODs - however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the kernel is still responsible for huge swathes of the computer's functionality. With a true micro-kernel there isn't any third-party code in the kernel space - not even a stub.
I typo'd that - it should be
> however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the kernel isn't still responsible for huge swathes of the computer's functionality
Let's not forget about massive stuff like the whole Windows Subsystem For Linux, which was literally an entire separate process type alongside Win32 processes, with its own set of syscalls etc. Added and then deprecated (and probably eventually removed entirely) over the span of years.
Maintaining a stable kernel ABI is no doubt a big investment, but it's possible and doesn't have much to do with whether your kernel is a microkernel or not. Lots of Windows drivers these days are user-space which helps maintain compatibility and stability.
The reason I got them initially is that, some about 2.5y back, they were sold on Aliexpress for 3.50 EUR (~5$) and could do dual-band with at least 40 MHz channels, iirc maybe even 80 MHz on 5GHz. They are just tiny USB-A dongles with a USB 2.0 HighSpeed host interface, but they could do station/softAP/station+softAP, obviously restricted to a single channel.
There's a related issue of a rtl8812-au or rtl8821-au (or compatible) stick (Edimax EW-7822UAC) I got before that, with a USB 3.0 SuperSpeed host interface, intended for trying out a remote radio head point-to-point configuration using polarization-duplex with a recycled satellite-TV dish on each end, as it could do AP-mode on 80 MHz wide channels in the 5 GHz band on Linux, with a 867 Mbit/s link rate (assuming full polarization multiplexing based on the stick's 2x2 MIMO and a circular polarizing feed antenna).
The android ecosystem is already better than the completely proprietary feature phones of before.
But it's still the thing we want, for that and a lot of other reasons. So presumably what we need to do is find a way to exert more leverage, so that we actually get what we want, instead of folding and letting the bad thing take root forever.
This is a conscious and opinionated strategy on the part of Linux, as an effort to make the cost of keeping drivers closed-source high and the cost of kernel refactoring low. It also has... disadvantages, in the form of a massive wasteland of only-supported-once snapshot-in-time devices. I am sure this comment thread will happy expound on this in great and painful detail.
Secondly, there was an entire effort by Google called "Project Treble" to build a stable Android HAL/ABI over the top of these unstable kernel interfaces. Unfortunately it would/will require essentially an Android-specific rewrite from vendors in order to fully implement, so many drivers are not yet operating in this model.
And Qualcomm is probably very, very happy with this arrangement. They can put a gazillion devs to maintain their BSPs using any means possible, but a small 2nd tier SoC fabbless don't.
Also as far as I remember (I might be wrong) the google HAL isn't a abstraction/redirection in the low level kernel module layer it lives on a higher abstraction level and was meant to make the amount of ways braking less but never planed to add abstractions on top of which you could build a graphics driver or CPU support (which doesn't only affect drivers but potential also kernel compiler time conditional compilations).
When asked about it most kernel developers point to closed-door negotiations that are being kept confidential. Usually also saying "trust us, we know what we are doing, we'll get more source opened our way".
Those who actually try to enforce GPL publically are ignored or shunned, e.g. Harald Welte/LaForge of gpl-violations.org
I don't think it is intentional. Linux development is very pragmatic, they just want to have freedom to refactor anything without caring about stable kernel APIs.
> Support a stable kernel API probably wouldn't be that expensive
The issue is that Treble simply shifts the compatibility issues from on from one layer (kernel) to another (Android HAL). There's still a compatibility horizon, because newer Android systems will eventually want to use newer kernel features and HAL APIs which were not present on ancient HALs which have been abandoned by the vendor.
And even if the OS could theoretically maintain backwards compatibility with older HAL APIs for 10 years, in practice the System + HAL combinations which aren't fully tested tend to break for various unforeseen reasons, making it unwise to push OS updates to devices which aren't fully supported by their vendor.
If anyone wants to read the Linux developers’ explanation directly, here it is:
https://www.kernel.org/doc/html/latest/process/stable-api-no...
I bet a lot of drivers are just interfacing with a standard serial line which could be done in the stable user space and then exposing the next layer through something like FUSE.
If I understand treble correctly that’s close to what Android is doing, where each HAL can be done in userspace?
To be precise, Qualcomm's Linux drivers are GPL'd like the rest of the kernel. Drivers often come with firmware blobs and proprietary binaries in userspace, but it should be possible to keep the kernel driver compatible with both.
The actual reason why older SoCs stop working on newer Linux kernels is that Qualcom's drivers were not fully upstreamed, either because they didn't submit them, or because they tried, but there were quality issues.
In theory, anyone could port those drivers onto the latest Android kernel, but without hardware documentation it's not an easy job.
I get that they have no responsibility vis a vis the GPL to upstream their changes, and I have no doubt that this is a cheaper way for them to run their business.
The OEM has to use that version. Oftentimes the SoC manufacturer will deliberately make it an old version because they know that the next android release will require a newer kernel version, therefore forcing the OEM to update to a new and more profitable SoC rather than continuing to sell an old model.
Also; has any work been done on decompiling that kernel and trying to match up the symbols with existing source code?
So while in practice this is rare it means that longer updates can't be offered as a product feature, and if it can't be offered as a product feature than how does it help sell phones.
I'll tell you right now that if any somewhat reputable manufacturer promised 5 year support on an otherwise reasonable phone I would buy it (and 5 isn't even that much). I would even pay a bit more for it. The amount of environmental waste that is basically working phones that just need a couple of software patches is disgusting.
I think that's exactly what Fairphone does. Sure they are not as big as Samsung, but they seem to be true to their word (I'm a happy FP3 customer, but to be honest I have much reasonable expectations for my phone than many :) )
Hopefully they recognize the value of "upstream first" more now. I think it is getting better...
This is precisely why open source libcamera[1] exists.
Personally I feel we need to push for a law where the iser has a right to an open driver in the same way he has a right to a manual. Attempts to ship undocumented / secret functionality is software or devices should be equates with spreadind spyware or malware.
Additionally with the work the Android Kernel team are doing to upstream so Android Common Kernel can be just replaced with using the Linux mainline, we're getting ever closer to limiting the effect that closed-source drivers have on updates.
[1] https://source.android.com/devices/architecture/kernel/gener...
Somehow people seem to be running on 15 year-old Thinkpads without a problem, yet a $1000 phone apparently can't scrape by for more than three years due to vendor support?
They don't "provide" anything. It's the software (eg. linux/windows) that's providing backwards compatible support. Vendor support for pc hardware lasts a few years at most.
The CPUs might be, but the chipset drivers definitely aren't. You'll have a hard time booting windows 95 on a ryzen system, for instance. Hell, ryzen doesn't officially support windows 7. Still, I get your point, standardization in the PC space (mainly stemming from the "IBM compatible" standard) has made backwards/forwards compatibility much easier.
And the current versions of various Linux distributions do run on 25+ year old PC hardware, if you really want to.
Windows and Linux (and others) seem to hold the policy of drivers for old hardware being maintained and supported seemingly indefinitely. This work isn’t free, but there’s no reason Qualcomm and Samsung and others couldn’t do the same.
So, not quite 10 years. Still a hell of a lot better than Qualcomm, though.
The HP400 specs I found only list Bloomfield processors[2], not Westmere. Perhaps that is the source of your confusion?
1- https://www.intel.com/content/dam/www/public/us/en/documents...
https://www.techpowerup.com/forums/threads/new-microcode-for...
Otherwise, just loading the microcode update once you get into the running OS is fine. I've never actually had a system that needed to use the former, but I've certainly used the latter.
The OEMs came up with a simple solution. Make batteries non-replaceable so that given the limited charge/discharge cycle life of a Li-ion the phone becomes almost useless after 2-3 years anyway.
Replaceable batteries might be moot if after two batteries the device was unbearably slow. Consumers would still replace their phones within a few years.
If the phone still had years of milage, its worth doing
I justified the higher price to support their vision, not because it's a great daily driver, but it serves well as a backup phone with /e/OS. The cameras can be upgraded to the 3+ ones, so it's great that it's the only truly modular and DIY repairable device on the market.
I wish that a chipset swap and upgrade would be possible though. Google's Project Ara was interesting, but it was probably infeasible, and the technology might not be there yet.
> The screen has color blurring when scrolling especially visible with text
Mine doesnt
> the fingerprint reader often doesn't get a good read
I don't make a habit of volunteering biometric data near Google, so can't comment.
> it's noticeably sluggish in everyday tasks.
Not sure what everyday tasks you mean? Haven't ever really noticed it being sluggish? HN is snappy as hell :)
> The cameras can be upgraded to the 3+ ones
I didn't know, thanks!
This was a big issue on my Samsung Galaxy S9 (2-3 years old flagship), OnePlus 7 Pro (2 years old flagship), and Google Pixel 5 (8 month old flagship). Those are all AMOLED so it's not an issue in normal mode black text on white background, but with dark themes scrolling makes the text look really bad, and it's even worse at low brightness.
I'm not a fan of statements like this. They really should be qualified further, because the Fairphone project deserves thoughtful critique.
What exactly is sluggish? Scrolling in the mail app? Tapping links when browsing over cellular? Opening the app drawer?
I'm sure newer phones are significantly faster, and heavier workloads can probably feel a bit janky (I don't usually have those), but phones haven't been sluggish the way pre-SSD computers could be for quite a while now.
Granted, I'm comparing this to a OnePlus 5T with a more powerful chipset, but I also think the screen itself is not as responsive to touch input which adds to the slowness perception. It reminds me of the way Android devices responded before Google's Project Butter, so seeing it in a modern $500 mid-range device from 2019 is underwhelming.
None of these are dealbreakers and the phone is perfectly usable, but together with the other (bigger IMO) issues it adds up to a lackluster experience.
If Android used FreeBSD and Qualcomm shipped drivers for the latest build when the SoC was released, you’d have up to five years of support from that kernel release.
Windows Phone 10 was actually in a position to support phones for years and even got Qualcomm onboard. It’s a shame the platform was never competitive, and they’d burned all their goodwill on the 7 and 8 fiascos.
1. There are longterm kernel releases, with up to 10 years support, and Android uses those exactly to avoid major support issues (https://en.wikipedia.org/wiki/Android_(operating_system)#Lin...).
2. That doesn't fix the issue that Qualcomm themselves do not want to release documentation and only want to support their hardware for up to two years. Ergo, you would run some outdated binary blob.
So either you need the source so that you can support it yourself, or you need a contract with Qualcomm to release security patches.
Sure, a stable ABI may mean that it would be cheaper for Qualcomm to release version updates as well, but at this point I would be happy if I could get security updates for more than 3 years. We can start asking for feature updates next.
The newest LTS release at the end of 2019 was 4.19, released in October 2018. 4.9 and 4.14 are also LTS releases. 4.4 is a bit special because it's a Super Long Term Support kernel but 4.19 is SLTS as well.
[0] https://www.appbrain.com/stats/top-manufacturers
[1] https://github.com/mohammad92/android_kernel_samsung_sm8350/...
2. Android did change drivers architecture across version in the past. We are talking something as old as Android 6
Yes, they could upstream drivers, but they won’t. It’s not in their best interest. I’m taking about what could be done in spite of this.
Given that they won’t upstream drivers, if the blobs they release keep working for the reasonable life of your device, your phone can get other software updates, including major OS updates. I don’t expect or need the camera or radio driver to change across various android versions. The hardware is the same!
And if you want a newer phone, you’re free to buy one! It’s just sad that you can’t safely use older devices just because the blobs break compatibility with OS security and feature updates. This need not be the case.
You probably don't. But a serious security vulnerability could be discovered that lets apps get root. So yes, it likely is fine, but I want a promise from my manufacturer that I will be able to keep using my phone for 5-10 years. I want to take the guaranteed lifetime into account when I am buying a phone.
Ideally it would be legally binding such that I can get a refund if they don't uphold it.
Regardless of how much goodwill they burned with 7 and 8, their handling of the WM 10 release nailed the coffin shut. They actually made a release that ran ok, but it was 18 months after the initial release. And Edge managed to be worse than mobile IE, but they were pretending to be Apple and disallowed competing browsers in WP. Grumble mumble, live tiles were nice.
Maybe microsoft was always doomed in the mobile space because of app support, but they did a lot of things wrong that sealed the deal.
I don't think they really were. They were actually gaining market share in the 8.x days, in part because their low priced phones were a lot more usable than similarly priced Android phones. Had they continued that trend with 10, instead of making a terrible release and pivoting towards high priced phones, they might have gotten enough market share to change developer's minds. And it's not like Microsoft didn't have experience on breaking into a market; the first xbox was weird and different, but they became a top tier console.
Androids awful graphics API is hack that allows Qualcomm to keep the driver source closed which means the BSPs rot and you can't use your phone after 2-3 years.
I'll happily buy a 10 year old SoC with half the clock speed but open source drivers over anything from Qualcomm because of how awful they are with this.
the only open source part (which is the kernel) will be closed source. No chances for customization and freedom now.
It would have gotten Microsoft a lot of goodwill if they had, but strangely enough Microsoft at that time did not seem to be interested in the goodwill of Windows Phone users anyway :-)
I'm still hanging on to a 950XL for some weird reason.
Most of the WP8 devices were able to run WM 10, but the experience was really poor on the low memory devices, so those didn't get a release outside of the public insider builds. There was one or two devices that didn't get upgrades for some reason, other than those and the low memory devices upgrading to 10 was available, but it took a long time for them to get around to fixing things; it actually got a lot better in the release after they officially gave up. Possibly if there was a focus on mobile during development of 10, they could have made the first release good, and maybe even got it to work OK on low memory devices; Edge was still going to be trash though.
All of that said, a bigger problem was dumping goodwill of developers. WP7, WP8, and WM10 all had new frameworks for apps that were needed for new functionality and didn't work with prior Microsoft OSes; calling the WM10 one 'Universal' was darkly humorous.
I think this was somewhat overstated, since compatibility in the other direction was great. I wrote a WP7 app that worked fine across WP7/WP8/WM10 that I supported until MS pulled the plug entirely on the ecosystem.
The Linux kernel used by Android is based on the LTS version that now has 6 years of support [1]. So by the time an OEM releases a new device the support window will be about 4 years. Google has also been working to stabilize the Android kernel HAL so that OS updates don't require a brand new kernel [2]. Because of these developments Android devices can now offer 4 years of support [3].
>Windows Phone 10 was actually in a position to support phones for years and even got Qualcomm onboard. It’s a shame the platform was never competitive, and they’d burned all their goodwill on the 7 and 8 fiascos.
This is pure speculation and I highly doubt Qualcomm would have invested the time and money, to support a platform that had no chance of success, beyond their obligated 2 years of support at the time.
[1] https://arstechnica.com/gadgets/2017/09/android-users-rejoic...
[2] https://arstechnica.com/gadgets/2019/11/google-outlines-plan...
[3] https://android-developers.googleblog.com/2020/12/treble-plu...
I still think there is some possibility of Microsoft releasing Windows Kernel as open source. But they will need Azure to be a competitive and stable business first. ( Which is not right now )
This is because the PC market is standardized (I guess, correct me if I'm wrong), compared to the phone market which has all of these proprietary blobs, private interfaces and lockdown. I hope we could have open source drivers, standardized hardware and software interfaces (like UEFI) for mobile smart devices just as PC does. Thus we can install whatever operating system or software without limitations. Also there will be less e-waste just as PC.
The Fairphone concept of easily replacing common problems with screens and battery complements the longterm chipset support, one needs both. It wouldn't help the repair/replace decision if the screen needs 2 hours and heatguns to replace. Making it difficult to unlock the bootloader is another barrier manufacturers and mobile operators are guilty of.
Mainline phones can be used until their counterpart antennas fall from the operators towers - and for 4G I think this is well into 2030.
Qualcomm just doesn't want to do this. I'm not sure if it's because they don't feel like spending the developer time (money) to do so, or if they believe 2-year obsolescence is better for their bottom line. Probably both.
This is not a sustainable model.
If you interested in long-term updates, the answer is simple: buy an iPhone.
Basically their moving away from the copyleft Linux kernel.
Given Google's awful track record with Android and security updates, and their lack of ability to force companies like Qualcomm to provide longer support windows, I'm not sure their new strategy will be successful.
Inevitably they'll be severe vulnerabilities found in the drivers including eg, Cellular radio / baseband drivers, Bluetooth driver, Wifi driver, and the vulnerabilities will never get patched.
Hopefully Google's capability-based microkernel approach with Zircon will stop this ever happening. But again, given Google's atrocious track record with Android and security I highly doubt it.
Even Windows doesn't support eg, i586 and i686 CPU architectures yet the Linux kernel does, so it seems like copyleft drivers are the only way to get security updates decades later.
Just a correction, I meant "Hopefully Google's capability-based microkernel approach with Zircon will reduce the incidence and severity of vulnerabilities being exploited once they are inevitably discovered".
This isn't a technical problem, it is an economic (and social and legal) problem.
But yes, it's an economic problem because that's pretty expensive (but has been achieved before eg, nouveau driver)
Google could easily use their monopolistic position to force all SoC vendors to provide greater software support.
Heck, Google could even simply pay every SoC vendors to open source their drivers. It's unlikely to even cost that much.
But today's Google is simply too incompetent to ever fix Android's security update problem. They've been making silly excuses for decades.
Android Pie: https://www.androidauthority.com/project-treble-2019-1045370... Android 11: https://9to5google.com/2020/12/16/android-updates-4-years/
I would, if apple wouldn't dictate what i can and cannot install on my phone.
Is there a smartphone that's usable as a daily driver, lets me have root and provides long term updates?
A touchscreen notebook with a GSM/LTE modem and a decent microphone running Linux is the closest you can get today as far as I know
while there are android phones that are supported by custom rom's up to ~5 years (exceptions even longer), the majority isn't.
meanwhile a 5year old iphone se is seamlessly supported by the manufacturer and probably will be for a few years to come.
I, as an OEM, am still NOT allowed (by Google) to use Treble to provide upgrades. This "legality" issue is being fixed ( https://android-developers.googleblog.com/2020/12/treble-plu... ), but its effect won't reach users for at least 2 years.
To release a smartphone with Google apps, an OEM must adhere to some requirements. One of those requirements, is that if you provide to customers an Android version X, then you must provide drivers targetting this version. You are not allowed by Google to provide an Android version 10 with drivers targgeting Android 9. This is true even across updates: if you release the smartphone with Android 9, then upgrade it to Android 12, then the Android 12 upgrade must include drivers targgetting Android 12.
The change that is coming, is that for Android 13, OEMs will be allowed to keep the drivers they made for Android 12.
Qualcomm is abusing its monopoly position and the laws/patents that allow this need to be changed. Qualcomm is a great example of how IP laws can hurt progress and competition.
In the future China and other countries will leapfrog the US in areas where competition is banned, because the only possible competitors will be in other countries.
That doesn’t mean that it could not go terribly wrong as for example when patents blocked progress in 3D printing for decades.
The reason things are the way they are is simple - users doesn't care. Users will happily throw cash the for next groundbreaking, awesome possum camera innovation that is just so totally worth the $1000 upgrade, because fabulous selfies are what people care about.
They have exclusive possession or control of supply of these types of chips. I'm not sure if the question of whether or not they could sell or want to sell it comes into question. Lets say I buy up all the supplies of diamonds and exclude the use of diamonds in any other use than my jewelry. I believe this still falls under a monopoly
There is no supply to buy up - these are just a part apple has made for their own product.
If you use the logic that parts you make for your own products are ‘monopolies’, then most product companies are monopolies, and the term becomes meaningless.
Most of the industry, except some Chinese vendors, use Qualcomm technology. There just are not a lot of 4G and 5G implementations out there.
In most markets, you end up licensing their patents regardless of whether you use their hard and software too. They have a near monopoly because building a replacement is a non trivial exercise and even if you succeed, you'll still have to license the patents. So, even when Apple ships their replacement, they'll be licensing patents from the likes of Nokia, Qualcomm and a few others for quite some time.
https://www.bloomberg.com/news/articles/2020-12-10/apple-sta...
Every single Android device from every manufacturer that wants access to Google apps must be approved by Google, and compliant with Google's terms. The "poor Google is at the mercy of other companies" narrative about Android's product line just doesn't square with the reality.
The only thing that could break are the radios (wifi,bt,modem) becoming incompatible with the networks they communicate with but they're separate components anyway and the modem speaks a standard protocol so I'm sure it could be replaced.
Even GPU?
The Librem 5 uses a Vivante GPU that is supported by the open source Etnaviv driver.
Most of Android's rendering is still mostly GLES, using directly OEM's GLES driver. Since Android 10, apps can decide to use Angle for generic GLES over Vulkan, but that's opt-in.
Also the Snapdragon 801 chip of the Fairphone 2 doesn't have (official) support for vulkan
Why is it so easy to boot any linux distro on almost any desktop computer? What makes it more difficult for phones?
The second problem is the proprietary nature of the chips. The PC became popular because other manufacturers copied and reversed IBM's BIOS and hardware, bringing a huge variety of available hardware that runs the same software. The only way that model could be profitable was to make sure everyone stuck mostly to the same standard, because breaking compatibility made your computer significantly incompatible with existing software your customers want. The crux of this requirement was that the user brought the software to the hardware, and the manufacturer could at most provide an operating system with a few tweaks at risk of breaking whatever the user wanted to run. This backwards compatibility still exists today, to the point that many BIOS update tools from manufacturers will boot FreeDOS to flash chips, running a software architecture older than many of their users on bleeding edge x64 chips.
The mobile ecosystem is designed so that devices last two, maybe three years, after that consumers throw their phones out and buy a new one. If you want to use your phone for longer then good luck, hope you bought a brand that ships you updates.
Qualcom, Huawei and Mediatek do not share the same level of compatibility the original PCs did, because they control the software supply chain. You don't take your software to Qualcom and make it work, you take Qualcom's kernel and then write your software. If Qualcom doesn't want to update the kernel version for your chip, good luck getting Android to boot; their open source drivers probably won't work because they either don't exist or are shoddily designed to fit only one kernel.
There's ongoing work over at the postmarketOS to mainline existing devices. Mainlined devices can run a proper, modern version of Linux with normal update support like any operating system, though Linux distributions often fail to properly implement things like deep sleep that are essential to using a phone. It'll be a while before mobile Linux becomes viable.
Then there's Apple, kind of a weird manufacturer in that they provide updates for well over five years even for slow mobile devices. They can do this because they don't need to buy chips from a manufacturer with an incentive to provide as little support as possible so end users buy new devices. They're also too popular for Linux not to hack in support for their weird, proprietary architectures.
All modular prototypes for Android have had the same problems with chipset and operating system constraints their constant-hardware cousins had; the same kernel supply line, with the same update problems.
A phone doesn't really have this standard; it's closer to a microcontroller with random shit attached to its pins, including for critical operations such as display or disk IO (where as on PCs you can get away with using the generic BIOS-provided functionality, which while not fast will at least work).
generally i still feel tortured by the situation, by highest of high tech devices being unsupportable, unmaintainable after a couple years, and it seems like upstream support is the only available path to keep devices from turning to e-waste. however, there are some positive signs. most chips still have seen nearly no support from the chip makers, but we have seen, for example, Qualcomm land some additional support for some additional the SD845 gpu, for which reverse engineered support had already been nicely developing.
we're also seeing more phones with Samsung, MediaTek, & some other chips. it's notable that none of the other chip makers have much of a presence in kernel upstreaming either. it's not just Qualcomm: everyone is very bad at making mobile devices able to be supported.
i'm very interested to see what starts happening with cars, which face a similar supportability problem, but which are less disposable. long term kernel support has been extended greatly to enable a longer life. Google's Project Treble has created a device-driver abstraction layer to try to ease things along some. but it's very hard to imagine the sea-change necessary for commercial teams to take their work, & rebuild it, safely, successfully, easily, atop the complex drops of vendor code &c. chip makers have had an enormously difficult job supporting the teams making software, providing them updates that they can readily begin to use, and it's been a very conservative, slow, deliberate process. most technical folk seem anxious to shift the mode, to get more upstream support, such that kernel & system upgrades don't require carefully tailored support packages from the chip maker to make updates possible. the current pace feels very logjammed, there's so much custom code people shipping products rely on, and trying to make folks less critically dependent is such a powerful compelling vision for so many techies to improve supportability, to make updates shippable both faster & doable in the long term.
[1] https://en.wikichip.org/wiki/qualcomm/snapdragon_800/845
[2] https://www.phoronix.com/scan.php?page=news_item&px=Qualcomm...
Not many device trees written yet (really only Sony devices) though
I presume that there's a good reason why that isn't being enforced, but I would like to better understand why.
There are some rules though: Kernel module is always open source and cannot use all the symbols. Also, using such driver marks the kernel tainted.
There are some very valid reasons for not releasing open source drivers. NDA bound 3rd party code is one (Java had it, fglrx had it, HDCP stuff has it, Intel's old GPU drivers had it). Another reason is software based secret sauce. Again GPU drivers are the worst offenders in this class. Third reason is greed/being insecure. Lastly, some companies use this method to effectively deprecate their products, so they can sell newer units more. Embedded space is the biggest example of this. I also worked with such vendor in a very unrelated product category. It's unpleasant.
I don't support any of these reasons, but I understand them from an economic sense. Some companies started to bake their magic into their hardware (Mellanox, AMD), so they can open their software completely. This is a much better path IMHO.
Customers want devices with in-kernel drivers. Not just curmudgeonly Richard Stallmans who care about the plight of the wild libre, but Joe Sixpack who just wants to be able to keep using the phone he likes instead of having to buy another one every other year. There is a market for that. Regular people would choose it on purpose.
And it's not being satisfied because Qualcomm keeps buying up their competitors. Because they dominate the Android market and the incentives of an effective monopolist are different than the incentives of a competitive market.
If you're one of five equally-sized chip makers, you don't care that the customer isn't going to buy a new phone for ten years instead of three, because with high probability they could buy from one of the other four next time anyway. And because you need a competitive advantage to get the sale today, and "don't have to buy a new phone after three years" is that.
If you're Qualcomm, you get the sale even if you don't offer the advantage because there is no viable alternative, and then you get another sale in three years.
Time to break them up. Or at least, and I mean come on, stop letting them buy their competitors.
But if you have bugs either in other processors' firmware, or in userspace binary libraries, kernel's GPL won't save you.
One could say that userspace binary blobs are meant to circumvent the GPL, but I don't have that feeling: GLES libs are userland just like Mesa, modem is userland just like ofono It looks like userspace/kernelspace separation is pretty much the same between oss world and android smartphones' proprietary world
1k pages is underestimating by quite a bit. 3-4k pages is closer to the norm, and that's just most of the programming/registers documentation. The complexity in these SoCs is astonishing.
It seems that open source can never really win.