Očekává se další várka telefonů podporovaných Linuxem

Více než 60 moderních telefonů má díky práci týmu dobrovolníků SOMainline šanci na zařazení do oficiálního linuxového jádra. Patche pro podporu chipsetu SD630 a SD660, kterým jsou tyto telefony poháněny, jsou postupně začleňovány. Tým se soustředí na zprovoznění klasických linuxových distribucí pro telefony, ale věnuje se i zprovoznění běžného AOSP. Další tým vývojářů postmarketOS již delší dobu pracuje na podpoře chipsetu MSM8953, který umožňuje vdechnout život dalším nejméně 30 telefonům vydaných v letech 2017 a 2018.

28.9. 13:22 | David Heidelberg | Zajímavý projekt

Komentáře

[Ovoce]

Jakou myslíte, že to má šance? Ono jedna věc je rozchodit SoC, ale typicky je pak problém, že nefunguje ten nebo onen senzor, kamerka, tlačítka, foto aplikace nebo nějaké jiné věci, které jsou v image telefonu nějak ad-hoc zhackované a tedy to pak v alternativní romce nefunguje.

[David Heidelberg]

Linuxové telefony Librem 5 (PureOS) a PinePhone (Mobian) používají poměrně základní buildy Debianu obohacené o úpravy pro lepší běh na telefonech a relativně málo vlastních, pro daný telefon specifických, hacků. Pokud se napíše korektně ovladač pro jádro, tak systém a jeho aplikace by ho měli využívat bez potřeb obezliček.

Svět Linuxu se rozhodně nerovná světu Androidu a AOSP ve kterém se opravuje hack hackem (viz. většina Custom ROMek pro Androidí telefony).

[Fluttershy, yay!]

Tipuji, že Ovoce naráží na to, zda z těch zařízení jde skutečně především telefonovat, ba dokonce mobilně. Což v případě Androidu často jde, bez ohledu na estetiku vnitřní implementace.

Mezitím…

Purism's goal is to get a battery life of 24 hours, so the Librem 5 only needs to be charged once per day, but first there are a number of challenges that need to be solved in the software to make that happen

potažmo následující

I can make and receive calls on my Dogwood phone. It works quite well when using headphones, but there are some problems:

• using the speaker phone, the other party hears their voice echoed back after approx. a second
• sound level is a bit weak
• Bluetooth headsets only work for sound playback, not for calling
• I have issues with the proximity sensor leading to lots of spurious touch events when using the phone’s earpiece
• phone drops to 2G during calls, cutting all internet access
• I keep forgetting the mic kill switch, because there is no indication in the UI

Upřímně řečeno, říkat tomu telefon, natož mobilní, je někde na hranici klamání spotřebitele. Proto dlouhodobě takovým přenosným počítačům – včetně těch s Androidem – říkám raději prostě „šmatlaplacka“.

[kralyk z abclinuxu]

phone drops to 2G during calls

To je trochu redflag, protože to má bezpečností implikace (nejsem odborník, ale AFAIK na 2G je MITM snadný).

[David Heidelberg]

viz. druhý příspěvek - je předpoklad, že to bude vyřešeno v rámci dodávaného FW třetí stranou. Druhá věc je, že v rámci "bezpečné" komunikace je vhodnější použít řešení šifrovaného hovoru přes VOIP over TLS.

[David Heidelberg]

I can make and receive calls on my Dogwood phone. It works quite well when using headphones, but there are some problems:

• using the speaker phone, the other party hears their voice echoed back after approx. a second
• sound level is a bit weak
• Bluetooth headsets only work for sound playback, not for calling
• I have issues with the proximity sensor leading to lots of spurious touch events when using the phone’s earpiece
• phone drops to 2G during calls, cutting all internet access
• I keep forgetting the mic kill switch, because there is no indication in the UI

• předpokládané řešení: zapnutí a odladění Pulseaudio pluginu
• poladění nastavení hlasitosti
• k tomuhle bohužel musím hodit část viny na mrtvé maintainery Pulseaudio, viz. např. snaha Paliho dostat do PA kvalitní kodeky
• proxymity senzor - odladění, ten kus HW co tam mají by měl být OK
• odladění firmwaru modemu (FW jim dodává třetí strana, bohužel jinak to v dnešní době udělat nejde)
• indikace killswitche mikrofonu se už řešila a samozřejmě bude implementována

To co tu píšeš jsou otravné věci. Ač je jich hodně, vše se mi zdá řešitelné v rámci několika měsíců.

[Fluttershy, yay!]

Tak a teď totéž vztáhnout na ty desítky telefonů z OP.

[David Heidelberg]

Budiž.

• (předpokládané řešení: zapnutí a odladění Pulseaudio pluginu) vyřešíš jednou, potom jen upravíš parametry v konfigu
• (poladění nastavení hlasitosti), to musíš odladit na každém kusu
• (k tomuhle bohužel musím hodit část viny na mrtvé maintainery Pulseaudio, viz. např. snaha Paliho dostat do PA kvalitní kodeky) vyřešíš jednou pro všechny
• (proxymity senzor - odladění, ten kus HW co tam mají by měl být OK), musíš odladit na každém telefonu
• (odladění firmwaru modemu (FW jim dodává třetí strana, bohužel jinak to v dnešní době udělat nejde)) to je už hotové.. (a nebo to bude zlobit stejně jako na Androidu)
• (indikace killswitche mikrofonu se už řešila a samozřejmě bude implementována) nemají killsitche

Taky je důležité si uvědomit, že Purism teď řeší hardware i software pro svůj telefon, až bude produkční várka HW hotová (Evergreen) hotová, přesune se více pozornosti k odladění softwaru (z kterého benefitují všichni) a bude moct přejít více pozornosti na odladění jednotlivých telefonů.

[Fluttershy, yay!]

Tak a nyní si můžeme udělat syntézu s vláknem níže, abychom získali nějaký časový harmonogram.

Tedy, že je řeč o elementární podpoře ~3 roky starých zařízení, která bude potřeba dále ladit, zatímco na trhu půjdou snadno sehnat – jak dlouho?

[xxx]

No podle te diskuse ohledne PA, spis na nekolik let.

[?]

Dalo by se tomu říkat mini tablet s nedokonalou funkcí volání? Kolik to stojí na naše cca 5000kč, nebo to je moc?

[BFU]

Jenomze librem5 je imx8mq, coz je docela dobre podporovane v upstreamu, a proto si ten SoC vybrali. Pinephone je nejaky allwinner, jinak plati to same co pro imx8mq.

Staci se podivat treba na to, jak dopadl ten gemini PDA, mt6797 nebo tak neco to bylo, 3.5 MLoC patch do ad-hoc ohackovaneho linuxu 3.18.y. To se bez obrovskeho usili neda ani vycistit ani upstreamovat, to je tak blby kod ze se to musi proste od zakladu prepsat aby to melo v upstreamu sanci. A tam pak budes resit, ze upstream na nektere veci ani nema framework, nebo je to zrovna ve vyvoji (treba kamera a bloby na 3A). A jako bonus ti pak chybi takove ty ruzne detaily co nejsou v datasheetu toho SoC (a zrovna u toho mediateku je ten datasheet hodne slaby), ale jsou nejakym zpusobem pohrbene mezi tema milionama radku downstream kodu, protoze si to vyvojari HW a SW rekli mezi sebou behem prestavky na kafe.

Nedelam si iluze, ze ten qualcomm bude o moc lepsi.

[BFU]

A navic, zivotnost tech mobilnich SoC je cca rok, nekdy i mene. Kdyz je v SoC bug, udela se novy SoC a k tomu novy software. Hardware a software je pak jeden balik, co si vyrobce mobilu vezme, upravi, proda mobil a je to hotovo. Takze se neni moc cemu divit, ze ti vyrobci nemaji moc incentivu se starat o nejaky hardware, co za rok bude davno na skladce.

[David Heidelberg]

můj kamarád má půjčený můj starý Moto G4 z roku 2016, když jsem ho nedávno viděl - funguje dost slušně. Po 4 letech používání.

Tablet Nexus 7 2012! s Linuxem běží hezky ač je jeho hardware pomalejší. 2013 jsem ještě s moderním jádrem nerozběhnul (taky jsem neměl moc času).

Samozřejmě že SOC mají bugy a fabriky to chrlí, ale 5-8 let staré telefony fungují obstojně (ač nemají všechny vymoženosti). Nevidím důvod, proč místo starého, nepodporovaného a děravého Androidu nenahrát aktuální Linux podporovaný komunitou (ač malou).

[BFU]

Protoze je skoro nemozne to dotahnout do aspon pouzitelneho stavu v rozumnem casovem useku. Bud se to povede a kdyz uz to bude nejak hotove, tak hardware stejne uz nepujde sehnat, novy hardware bude natolik jiny ze vsechna tahle snaha byla k nicemu a muzes to zahodit. A nebo to bude tolik prace, ze se to proste nepovede.

[David Heidelberg]

Jo a ne. Telefony od SoMainline jsou 2018-19, takže na trhu jsou a nějakou dobu budou. Samozřejmě ještě nejsou hotové, ale dost je uděláno (ref. Xperia 10 & 10 Plus, kde si např. klidně už spustíš normální Arch Linux s GNOME).

Např. chipsety od Qualcommu se sice liší, ale jednotlivé generace a třídy (low,mid-end) mají hodně společného - high-end je naopak peklo. Pokud seš schopný napsat solidní podporu pro jeden chipset, odvodit základy podpory pro ostatní není raketová věda pro studenta či programátora znalého embedded věcí.

Za další úvahu stojí fakt, že vývojářů s zájmem o reengineering a mainling/upstreaming přibývá (doufám, že i díky osvětě, kterou do toho vkládá komunita). Jsou to lidi, které to baví a pokud jich máš dost, komunikují navzájem a vidí nějaký cíl (což dnes díky dostupnému user-space je možné), věci se hýbou vpřed. Doporučuju zkouknout #postmarketOS-mainline kanál na Matrixu, tam se to hemží i2c sběrnicemi, GPIO adresami a DTS layouty..

[BFU]

Na to aby jsi rozchodil framebuffer a mozna i KMS a GPU toho moc nepotrebujes. Obzvlast, kdyz se podivas, kolik se toho presouva do TFA nebo v tomhle pripade LK, aby to nemuselo byt v Linuxu, a tim padem to neprojde ani upstreamovy review. Ten LK blob ma nekolik mega, resi ti cely clock/power management, a ten kernel do toho vola pres nejaky SMC hypercall. Ono to skutecne pripomina volani ACPI na x86 a neni to od toho daleko.

Ja se nehadam, ze ubalit nejaky zakladni DT se seriovym portem je tezke, to neni. Tezke je zajistit, ze nenarazis na ty ruzne hardwarove bugy, ktere maji v ruznych driverech nejake podivne quirky a workaroundy. Vubec zjistit takove detaily a pochopit co to vlastne je za bug, co se v tom chipu fakt deje, a proc teda ten workaround je napsany zrovna tak, jak je napsany, neni trivialni ani kdyz pro toho vyrobce chipu delas. Kdyz to budes delat uplne externe, tak to budes mit o to tezsi.

Zajem muze byt, ale komplexita hardwaru roste, a uz ted je opravdu tezke pochopit chyby i v jednodussich a mnohem lepe zdokumentovanych SoC nez ten SD. Takze bych asi krotil svoje ocekavani.

Ale je mozne, ze vyrobci hardwaru nacpou jeste vice veci do LK popr. jineho firmwaru a Linux pak pobezi vicemene v necem, co se nebude moc lisit od nejakeho virtualniho stroje, pomoci virtio bude pristupovat na virtualizovany hardware, a vlastne to bude jenom takova adaptacni vrstva nad binarnim blobem / firmwarem Stejne od toho moc daleko nejsme, ani na x86, ani na ARMu.

[David Heidelberg]

S první větou si dovolím nesouhlasit. Ovladače pro KMS a MM jsou dost komplexní. Samozřejmě když jsou už jednou napsané, napojit nový chipset je už "relativně hračka".

Nějaké HW bugy jsou (a budou), ale to má v podstatě téměř každý stroj (včetně AMD64, kterou všichni používáme). Pravda, že bez dokumentace je to peklo, na druhou stranu jsou k dispozici alespoň zdrojáky AOSP jader (ač uprasené) a občas nějaké datasheety.

Komplexita roste a dost - např. porovnání QCOMu (2016+) vs Tegra 3 (2012), ale pořád to není nepřekonatelný práh pro vstup do RE a vývoje. Co se týká očekávání, sám se považuji za realistu s optimismem (ač sám nedělám RE, sleduji vývoj kernelových věcí a dev diskuze, občas do něčeho sáhnu atd., takže všeobecnou představu mám).

Ten přístup virtuálního stroje je jisté riziko, každopádně dělají to procesory, dělají to EC firmary, TFA. Doufejme, že brzy (do 10 let a to jsem optimista) budeme mít rozumné implementace RISC a Power architektur.

btw. kdybys chtěl zkouknout jednu děsivou přednášku (v rámci komplexity návrhu) návrhu budoucí archtektury (GEN-Z)

[BFU]

Zkus git grep drm_simple_display_pipe_init a to ti da treba drivers/gpu/drm/cirrus , ktery ma ~700 LoC , vetsina toho je boilerplate. To je cely KMS driver pro scanout engine. Pro GPU je vetsina logiky v userspacovych blobech nebo mesa3d (shader compiler etc.) a do kernelu se posila command stream a resourcy, takze ten kernelovy driver taky neni nikterak slozity.

Hardwarove bugy v AMD64 ti vyresi vyrobce procesoru (intel/amd/...) bud v kernelu nebo ve firmwaru, protoze ma k dispozici vsechnu dokumentaci k tomu bugu, popr. ma rovnou HDL. Ty ji v takovem detailu nemas. Ze zdrojaku to vytahnes jen velmi tezko, a pouze pokud to implementator dobre zdokumentoval (tj. ne code-drop bez komentaru a historie VCS).

Ad. komplexita, moderni SoC dostat do upstreamu aby to bylo kompletne pouzitelne trva roky, i kdyz tam mas nejake zaklady. Velka cast toho jsou multimedia.

Pristup virtualniho stroje je dnesni realita. Vyrobcum HW se to libi, protoze to ma dve vyhody, jedna je ze muzes schovat veskery hnusny kod a bugy do firmwaru, druha je ze se muzes vyhnout reviewovani kodu v upstreamu. Beznym uzivatelum se to libit nemusi

[yv]

Uživatele zajíma user-space, ne kernel. Podstatné je, aby si tam mohl spustit libovolnou linuxovou aplikaci, mohl vrtat kam chce, a mohl naplno využívat hardware. To, jestli jsou pod tím binární bloby a původní kernel je až na druhém místě. (byť je to samozřejmě stále důležité)

[David Heidelberg]

Naprosto souhlasím že běžný uživatel se nezaobírá čímkoliv pod aplikační vrstvou. Na druhou stranu během budování platformy je potřebné mít kvalitní základy. Naplácat něco, co nějak funguje (UBPorts, Jolla) se dá, jenže potom v praxi se tyhle projekty v některých aspektech nedostali za dlouhou dobu své existence tak daleko jako Phosh od Purismu za rok.

[Bedňa]

Ja som si kvôli Uborts kúpil zabijáka vlajkových ľodí OnePlus One, teraz sa dá zohnať za pár korún. Keď už sa dostali k MSM8953, dúfam že sa dostanú aj k MSM8974. Chcel by som mať na to viac času a aj pomôcť, mno ušil som si teraz sám na seba byč z novým projektom, ktorý chceme nasadiť. Zas to beriem tak, že ide o zábavu a raz sa na to dostane.