Vilka telefontillverkare ger bra CM stöd i form av drivrutiner osv.

Vilka mobilmärken ska man satsa på om man vill ha bra cyanogenmod stöd eller rättare sagt välfungerande tredjepart roms.

Min SGSII har ju en exynos process som saknar publika drivrutiner vilket skapar dåliga roms.

Hur ska man tänka när man köper en telefon om man vill ha bra och välfungerande CM roms.

 

alla som kör qualcomm gissar jag på dvs de flesta men inte samsung förutom s4 nu då

sony har ju en ganska trevlig attityd mot community officiellt iaf sen att det är garantiärendets satan själv är väl en avvägning man får göra

 

Nexustelefoner.

Eller, som sagt ovan, alla lurar med qualcomm-chip.

Sent from my Nexus 7 using Tapatalk HD

 

Om det är Qualcomm telefoner så lär telefonin fungera bra pga publika drivrutiner, men hur är det med till exempel kameran, måste man inte ha drivrutiner där med? Och Samsung som är så tröga med att lämna ut sånt.

 

Tänk dig ett SoC (system on a chip) som mobilens hjärta. Allt drivs av den, även kameran. Kameran fungerar bra i AOSP-roms för mobiler som har qualcomm. DOck är inte ens qualcomm-lurar felfria med aosp-support då inte ens qualcomm ger ut exakt 100% vilket ingen kan göra utan att gå med förlust, men skillnaden mellan stock-mjukvaror och aosp på sådana lurar är så liten att den nästan är obefintlig.

 

Som en del av CM-teamet kan jag passa på att förtydliga lite av problematiken.

Det som behövs för att kunna skapa en väl fungerande version av CM för en viss enhet är den SoC-specifika koden samt matchande drivrutiner (samt givetvis kernel-källkod för den enheten eller en liknande modell). De enheter som får överlägset bäst stöd är de där SoC-tillverkaren släpper referenskällkod för aktuell SoC och där tillverkaren av telefonen inte frångått referenskoden alltför mycket, eller där tillverkaren åtminstone är hyfsat tydligt med vad som är ändrat.

SoC-tillverkarna:

Samsung (Exynos)

Exynos 3: Ganska ok att jobba med då Google tillhandahåller både SoC-kod och drivrutiner till Nexus S. Kräver mer arbete ju mer utdaterad koden blir nu när Nexus S är end-of-life:ed dock.

Exynos 4: Är extremt frustrerande att jobba med då referenskoden som Samsung tillhandahåller i de flesta fall är extremt utdaterad och ofta skiljer sig helt från vad de använder själva på alla enheter de säljer. På grund av detta är koden de släppt ofta mer eller mindre värdelös eftersom den nästan aldrig är kompatibel med de drivrutiner som finns.

Exynos 5: Sägs vara hyfsat bra att jobba med då Google återigen levererar kod och drivrutiner för den pga. Nexus 10. Vår Nexus 10 maintainer brukar dock inte vara så aktiv i vår privata kanal så jag har inte hört så mycket om eventuella problem där.

Qualcomm (Snapdragon)

Situationen är ungefär densamma för deras nyaste SoC samt de några generationer bakåt förutom att de nyare ofta prioriteras i ordningen de släpper uppdaterad referenskod när nya versioner av Android släpps.

Generellt handlar "portning" av CM till en ny Qualcomm-baserad enhet om att man manuellt försöker identifiera den tag på CAF (Code Aurora Forum) som telefontillverkaren baserat sina ändringar på. På så sätt ser man vilka ändringar de gjort och kan få mer commit-historik. Sedan brukar vi försöka uppdatera dessa till nyare versionen av Qualcomms kod och se hur mycket kod som kan delas mellan de enheter vi har stöd för. Qualcomm släpper även uppdaterade versioner av vissa drivrutiner som vi kan använda, något som krävs för kompabilitet med nyare versioner av deras referenskod.

Texas Instruments (OMAP)

OMAP 3: Finns referenskod att jobba med på OMAPZOOM. TI är/var i allmänhet duktiga på att hålla sin referenskod uppdaterad, även för äldre enheter och var klart tidigare än Qualcomm med att släppa uppdaterade GPU-drivrutiner till annat än de som licensierat deras SoC. De lade exempelvis ner en massa tid på att uppdatera referenskoden för OMAP 3 till ICS etc, trots att de troligen visste att ytterst få telefontillverkare skulle uppdatera de modellerna. Var ju väldigt bra för oss dock.

OMAP 4: Finns bra stöd från Google och fanns åtminstone tidigare även bra stöd från OMAPZOOM.

Tyvärr får vi nog inte nöjet att jobba med fler OMAP-baserade enheter.

Nvidia (Tegra)

Tegra 2: Olika revisioner av SoCen kräver olika drivrutiner och eftersom Nvidia i princip bara släpper binär-blobbar samt lite kod för att länka mot dem så går det inte att göra så mycket när Nvidia anser revisionen vara för gammal (händer ganska snabbt). Går ofta att med lite trixande få drivrutiner från lite nyare revisioner av Tegra 2 att fungera men utan fungerande kamera.

Tegra 3: Vissa enheter går ok att jobba med men då måste de fungera med de drivrutiner och blobs som Google släpper för Nexus 7. Rent allmänt bör man undvika Tegra-baserade enheter om det inte är en Nexus-enhet.

AllWinner

Går att få hyfsat fungerande men deras referenskod har inte stöd för Androids mediauppspelning utan använder en portad version av ett framework från en annan plattform. Därmed går det inte på något vettigt sätt att få HW-decoding av video.

Telefon/Tablet-tillverkarna:

Samsung

De släpper kernel-källkoden relativt snabbt, åtminstone för vissa enheter. Däremot har de ibland för sig en del lustiga saker som att forward-porta en uråldrig drivrutin till en ny kernel-version istället för att se till att den nyare drivrutinen fungerar. Ibland har de bara gjort skumma ändringar som gör att saker slutar fungera som korrekt. Då säger vi att en drivrutin är "samsunged".

Om man lägger ner en del extra arbete går det ibland med deras Qualcomm-baserade telefoner att migrera över till en CAF-baserad kernel med så lite samsung-specifik kod som möjligt. Det är det Steve har gjort med d2-enheterna (de amerikanska Galaxy S3-varianterna).

Sony

Sonys team verkar fortfarande till största delen bestå av SonyEricsson-folket i Lund. De är tydligen väldigt bra att ha att göra med och de bistår med både svar på tekniska frågor om deras implementation samt även drivrutiner de kompilerar åt oss där de tagit bort hooks till sina proprietära libs och därmed gör dem kompatibla med AOSP-implementationen. Deras kod är i övrigt extremt nära referensimplementationen från CAF så därför är de tacksamma att jobba med. Detta gäller både SoC- och kernel-koden.

LG

LG bistår med bootloader-upplåsta versioner av internationella telefonmodeller. Utveckling av stöd för dessa är därför inte nödvändigtvis bunden till om det finns en officiella unlock eller exploit tillgänglig.

LG själva är väl tyvärr inte alltid de snabbaste att släppa uppdateringar och innan de släppt kernel-source till en enhet kan vi inte släppa CM till den, även om vi har en läckt stock-kernel som fungerar eftersom vi då skulle bryta mot GPL.

HTC

HTC är tyvärr bland de sämre tillverkarna när det gäller att släppa kernel-källkoden i rimlig tid. De brukade också tills helt nyligen precis som Samsung göra en massa onödiga ändringar som skapade en massa merarbete och gjorde det svårare att dela kod med andra enheter med samma SoC. Tydligen ska de ha blivit mycket bättre på att inte göra ändringar som i onödan förstör kompabilitet med drivrutiner och med AOSP-implementationerna i sina allra senaste modeller. Förhoppningsvis slutar de larva sig med sin semi-unlock och istället låter sina kunder flasha även /boot från recovery.

Oppo

När det gäller Oppo Find 5 ska de tydligen ha wrappat sina kernel-ändringar med en egen ifdef. Föredömligt. Arbetet på den har bara börjat dock.