It's not just Qualcomm it's closed source driver blobs in general. 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 fa…
Fairphone suggests Qualcomm is the biggest barrier to long-term Android support
211–220 of 226 posts
Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support
#212Earlier quoted context omitted.
> It's not just Qualcomm it's closed source driver blobs in general. 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…
That may keep the phone working but that doesn't provide security updates. Only Qualcomm can provide security updates for the binary blobs, so if Qualcomm won't sell security updates past 3 years than no OEM can guarantee a secure phone for more than 3 years. Sure, they can update other components but I would be very upset if 3.5 years into my 5 year supported phone a CPU vulnerability was discovered that let apps ge…
Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support
#213It's not just Qualcomm it's closed source driver blobs in general. 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 fa…
> It's not just Qualcomm it's closed source driver blobs in general. 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…
Hopefully they recognize the value of "upstream first" more now. I think it is getting better...
Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support
#214Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support
#215Earlier quoted context omitted.
Google has been promising to 'solve' fragmentation and long-term support for almost a decade, and it doesn't seem like there is any real solution. If you interested in long-term updates, the answer is simple: buy an iPhone.
> If you interested in long-term updates, the answer is simple: buy an iPhone. 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?
Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support
#216Earlier quoted context omitted.
People aren't using it because it is no longer receiving updates. 2-3 year old hardware should not be considered "old", or obsolete.
Android hardware ages really poorly. I have an iPad and a few android tablets from around 2014 and the iPad is on the latest version of iOS 14 and feels almost new while the android tablets are basically unusable and on 2015 versions of android.
Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support
#217Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support
#218Earlier quoted context omitted.
Android hardware ages really poorly. I have an iPad and a few android tablets from around 2014 and the iPad is on the latest version of iOS 14 and feels almost new while the android tablets are basically unusable and on 2015 versions of android.
If the software doesn't get updated, it doesn't mean the hardware is not aging well.
Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support
#219Earlier quoted context omitted.
It's a decent device, but feels several generations behind any mid-range phone released in 2019. The screen has color blurring when scrolling especially visible with text, the fingerprint reader often doesn't get a good read, and it's noticeably sluggish in everyday tasks. 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…
> it's noticeably sluggish in everyday tasks. 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?
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.
Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support
#220Earlier quoted context omitted.
What I don't understand (due to my ignorance, please explain if you can)... what keeps the driver blobs from continuing to work from one version of Android to the next? 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 drasticall…
This is because the Linux kernel itself is constructed and developed in a way where driver interfaces (API) are ruthlessly refactored and the linker interface for kernel modules (ABI) is intentionally version-incompatible. If the driver's source code is not in the kernel, it doesn't gain the benefit of kernel developers doing this ruthless refactoring and falls behind immediately from a source point of view, and from…
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?