The problem with these devices is the MTK chipset. Some of them might perform even worse when upgrading their base version.
Hi, no the mediatek SoCs are not an issue, mediatek devices I played with, mostly mt675x with 3.10 LP-alps / 3.10 MM-alps / 3.18-MM&N-alps branches, they all perform better or at least as good as previously and I can tell you O-preview-2 is blazing fast compared to stock flyme, it’s even ahead of a well-optimised lineage-14.1 rom (and O is still ~a preview~), mediatek only releases “template devices”, then SKU & vendors have to make a “commercial product” out of it, adding additional peripherals to the main device (selecting components, capabilities).
SKU & vendors buy licences from mediatek and have to buy new ones for newer alps (LP => MM is not free, I know, it’s discutable but hey).
Up 'til now, mt675x will have N alps and prolly O-alps due to popular demands (mostly the biggest companies using mtk : htc/sony/lenovo, etc…)
At this point MTK has been a disaster for Meizu as MediaTek doesn’t provides source code.
I’m just trying to raise awareness that MediaTek is not the problem here, but morely likely middlemen like 3rd-party peripherals : lack of support for out-of-tree / non-mediatek drivers, can’t be attributed to mediatek nor the linux kernel.
The linux kernel has simple rules and the world would be a better place if they were followed, yet there’s not enough resources to include/merge-in every “fancy drivers” small electronics company never care to maintain. Imagine if linux had every LCM drivers, every sensors ones; etc…
Mediatek have working branches for 3.10/3.18/4.x kernels, they are actually doing their job at providing “updates”.
When it comes to smaller companies for X or Y drivers/hardware, most of the time, business world works like “you get what you pay for”, Meizu is big enough to pay for updates so this mostly sounds like an “small economy” or “contract terms” issue.
As an amateur, when those small companies don’t provide updates, I can tell you from experience you can easily contact them, explain your case and get help from them and get datasheets / spreadsheets and a lot of informations, far enough to dev your own drivers from scratch, be it that you are resourceful enough to gather infos online (here’s an example I contributed to, thanks to himax for the docs : https://github.com/MediatekAndroidDevelopers/android_kernel_ulefone_metal/commit/c5504bf8e223327b779e420ea7265b5eb17626b3 ).
And we’re talking about young/student people, with few resources and knowledge, who did it. I wonder what a real company with experienced engineers (from most domains : electronic / IT / CS / etc…) could possibly do :P
However, due to the “little investment” of several hundred of millions, Meizu doesn’t cares about it.
This is mostly why they don’t care about updating old devices, they don’t risk anything and they sell “en masse” and releases newer devices each time they can cut prices on the production line (the various Mx (note) with mt6735/mt6753 or mt6755 socs).
Meizu M2 Note: mt6753 - kernel sources are 3.10 LP0.alps.
Meizu M5s : mt6753 - kernel sources are 3.18 MM1.alps.
the only differences between those two phones are the “3rd parties drivers”, but you can clearly see that if Meizu released 2 devices with the same SoCs over different alps sources, they had to acquire (the newer MM) alps. So meizu have sources from mediatek for mt6753.
I’m pretty sure the biggest problem here is that it’s not a good investment to spend man-hours and port the m2 note 3.10 to a 3.18 sources and bring MM to older devices. (and what it involves if they can’t get oem updates, RE their drivers, etc.).
And due to how mediatek alps sources work, and how meizu handles their release, most of meizu’s customised blobs (mtkcam and audio Hals mostly) are mostly generic across devices (if meizu uses mtk alps, they have their custom code live in /vendor/meizu ) (not to mention for example, meizu’s “hifi” audio thingy is just ported from exynos to mediatek sources, that’s inter-platform compatible).
Meizu just want quick profit, and mediatek is sold as “cheap” (pardon the pun). There’s still (like every new “market”) a few bad apples, because smaller companies released N for mt6753 / mt6755 and mt6752/mt6797 also is coming. (vernee, umi, elephone amongst others)
At this point, non-savvy phone-maker companies have been a disaster for Mediatek ;) (and that includes fishy economical decisions to hire small companies without contracting for updates, or shipping “precompiled” .a drivers in some kernels even when other vendor released the sources of the same exact drivers (looking at you, Ulefone p9000 and your .a lsm6ds3 driver, kappa), or blaming mediatek for a “no-release policy” when mediatek strongly encourage about respecting the GPL licence of the gnu/linux kernel : looking at you Umi…)
Sorry for the long post, I’m not trying to bring a conflict over who’s faulty, but it appears to me that meizu is just trying to cash-in passively on their mediatek devices lines, they also quickly turned their vests about mediatek or they forgot about their hugely increased visibility and benefited (both in $ and in making a name as a “quality” brand) when they released one of their first “flagship” (the mx4) with a mt6592 soc and also offering ubuntu touch and making open-source promises.
As a last argument, I brought LP (cm-12.1) / MM (cm-13.0) / NG (cm-14.0 & los-14.1) and OC (aosp-o-preview2) on my Meizu M2 Note and most of the roadblocks are meizu’s own customisation (mtkcam have meizu code, audio hals too) but they also extended their modifications and planted stems everywhere in the kernel(s) (which in definitive makes it close to impossible to rebase m2 note’s kernel to a newer kernel sources or a cleaner one like aosp-common/3.10 branch).
And I still haven’t talked about the fact they released Flyme 4.5 sources-based kernel-source (github/meizuosc only have outdated flyme 4.5 kernel sources) when Flyme 5.x was already “available and installed” on almost all of their devices.
Which means they are breaking the GPLv2 licence, for all of their hosted repositories, and not letting “indy devs” like me, have their newer updates/fixes (which also means I can’t use their latest blobs from flyme 5.x / 6.x) because the kernel imgsensor drivers are not updated and litteraly hardcrash the device board.
I’ll stop here or else I’ll spend the day listing to Meizu’s poor decisions and implementations. I do still acknowledge they did some good devices and coded some quite robust and well-working drivers (I think Weng Pingbo is to thank here, for the kernel-side gestures / flipflap cover drivers, that are still working on android 7.x/8.x)