Voir épisode précédent : https://linuxfr.org/users/gnumdk/journaux/telephone-sous-linux-3c82896e-f65c-4012-9c71-3e1fdd2b9558
Pour rappel, Droidian un est un OS basé sur Debian (Mobian), Android et libhybris. Il y'a donc un mini conteneur Android qui se charge de communiquer avec les drivers du noyau Linux/Android.
Depuis le mois d'avril, beaucoup de choses ont changé.
Je comprends déjà un peu mieux le fonctionnement de Droidian après plusieurs contributions :
- Réécriture du service de déverrouillage via empreinte digitale (et du panneau de configuration dans GNOME control center)
- Réécriture du panneau de configuration Waydroid dans GNOME control center
- Réécriture du support de la luminosité automatique dans gnome-settings-daemon (ne sera pas upstream car certains devs GNOME voudraient sortir ce code de gnome-settings-daemon), mais en attendant ça fait le job
- Ajout d'un service DBus (mobile-settings) permettant de configurer facilement le noyau depuis une session utilisateur
- Création de mobile-power-saver afin de remplacer l'ancien gestionnaire d'énergie (batman) ainsi que mon module noyau (voir précédent journal)
- Nettoyage et fix dans OFono2MM: La connexion aux données est maintenant vraiment fonctionnelle
- Correctifs dans le gestionnaire MTP/RNDIS (et réécriture du panneau de configuration dans GNOME control center)
Grace à tout cela, j'ai intégré l'équipe Droidian il y'a quelques mois.
Ma plus grosse contribution reste mobile-power-saver. Sur les téléphones Miatoll, qui sont le mieux supportés à mon avis (c'est le modèle que je maintiens), il me permet d'avoir une autonomie de 2 à 4 jour en fonction de mon usage.
Sur un exemple concret avec un téléphone à 100% de batterie le lundi à 6h et avec l'usage suivant:
- 6 heures de musique/podcasts
- Coups de fils
- SMS/Signal
- Navigation sur le Web
Je termine le mercredi à 23h avec un téléphone aux alentours des 20%. Si je remplace les 6 heures de musique par 4h de musique et 2h de youtube, je finis à 20% le mardi soir.
Sinon, j'ai rejoint le projet juste après un fork, en effet, la personne qui m'a fait découvrir le projet au FOSDEM a forké le projet pour créer https://furilabs.com/
J'ai pas encore eu l'occasion d'évoquer ce fork avec les devs de Droidian mais je sens bien que ça s'est pas super bien passé. Au début, j'ai failli acheter un FLX1 pour remplacer mon Redmi Note 9 pro (écran cassé) mais après analyse des repos des deux projets, on a deux façon de travailler bien différentes:
- Chez Furilabs on veut que ça fonctionne sans attendre donc c'est plein de "dirty hacks" souvent très très moches
- Chez Droidian on cherche plus à avoir du code maintenable même si cela prend du temps vu la taille de l'équipe
J'ai donc fini par racheter un Redmi Note 9 pro :)
A titre d'exemple, voici le genre de code présent dans le FLX1 (hérité de Droidian) que j'ai du remplacer, code écrit par une des personnes à l'origine du fork:
https://github.com/droidian/droidian-fpd-client/blob/droidian/src/fpdidentify.cpp#L38
Pour finir, j'ai donc maintenant deux RN9P, un pour le dev et un comme téléphone de tous les jours qui me permet de faire tout ce que je veux (grâce à Waydroid pour la banque).
Voilà, j'espère que tout cela vous donner envie de tester voir de rejoindre le monde merveilleux des téléphones sous GNU/Linux (Mobian), GNU/Musl/Linux (PostmarketOS) ou encore GNU/Android/Linux (UBPorts et Droidian).
# Et mince
Posté par gnumdk (site web personnel) . Évalué à 5 (+3/-0).
Loupé sur la phrase d'intro:
Pour rappel, Droidian un est un OS basé sur Debian (Mobian), Android et libhybris. Il y'a donc un mini conteneur Android qui se charge de communiquer avec les drivers du noyau Linux/Android.
[^] # Re: Et mince
Posté par gUI (Mastodon) . Évalué à 3 (+0/-0).
Corrigé, merci.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Questions sur le projet et l'utilisation de Signal
Posté par bizaw . Évalué à 2 (+1/-0). Dernière modification le 17 octobre 2024 à 03:01.
Sympa le projet, je ne le connaissais pas.
- Question : tu arrives à appeler via Signal ? Du coup, c'est un fork de Signal Desktop ou vous utilisez l'APK de Signal ?
- J'ai une question sur le chiffrement du dispositif : cela fonctionne-t-il avec dm-crypt et cryptsetup ?
[^] # Re: Questions sur le projet et l'utilisation de Signal
Posté par gnumdk (site web personnel) . Évalué à 3 (+1/-0).
Signal: J'utilise Flare mais Signal desktop fonctionne bien aussi. Sinon, tu peux toujours lancer la version Android depuis Waydroid.
Bootloader: Non, je ne pense pas
Chiffrement: https://github.com/droidian/droidian-encryption-service
# Alternative sans Android ?
Posté par Walter5 . Évalué à 2 (+2/-0).
Ce serait possible de faire une Mobian, dont le noyau Linux accepte les pilotes matériels Android ?
Et ensuite récupérer les pilotes sur le smartphone Android de l'utilisateur, afin de les intégrer et de faire une image Mobian ?
[^] # Re: Alternative sans Android ?
Posté par gnumdk (site web personnel) . Évalué à 5 (+3/-0).
Non, car une grande partie des pilotes fonctionnent avec des services en userspace (donc Android). Et puis porter des modules 4.14 vers un noyau 6.11, je te raconte pas le boulot.
Après, oui en théorie, si tu es prêt à recoder tout l'écosystème vendor de chaque téléphone.
# Liens avec Mobian ?
Posté par Christophe . Évalué à 3 (+1/-0). Dernière modification le 17 octobre 2024 à 10:03.
Déjà, bravo pour ton travail sur Droidian, l'intégration dans le Gnome Control Center est un gros plus pour l'utilisation au quotidien.
Est-ce qu'il y a des interactions entre Mobian et Droidian ? Une mise en commun de certaines parties ?
De ce que je comprends la principale différence est que Mobian est axé sur le support "mainline", là où Droidian s'appuie explicitement sur libhybris. Mais vu de loin, passé cette couche de support hardware, le gros du boulot semble commun aux deux… Est-ce le cas ?
Pour LuneOS (dont je fais partie), on fait un peu des deux, avec une transition (récente) vers le mainline; toute la partie UI/Middleware est commune.
[^] # Re: Liens avec Mobian ?
Posté par tkr . Évalué à 2 (+1/-0).
Pour un certain nombre d'ingés, hybris ou halium = android, ne serait-ce que parce que la couche support logicielle dépend à 100% d'android, donc "décalque" les résultats en fonction de l'OS de google : si google dit B au lieu de A demain, tout ce qui dépend de hybris/halium devra en dépendre.
Or, depuis plusieurs mois, beaucoup de projets se concentrent sur les appareils "mainline", afin de ne dépendre ni de H/L précédemment évoqués, mais du dernier noyau Linux.
La sélection se fait "à la racine", càd selon l'appareil utilisé : un certain nombre d'anciens mobiles sont donc "condamnés" à rester à vie sur un vieux noyau linux, pour défaut de noyau récent adapté par le fabricant, via le sulfureux… qualcomm.
Ce pourquoi, exactement comme pour BSD dont l'ordi doit etre choisi selon le support logiciel, de plus en plus d'anciens tels sont voués à la poubelle en raison d'un noyau mainline non compatible avec l'appareil, le downstream étant de plus en plus poussé vers la sortie par toutes les distros (dont postmarket)
c'est triste, mais à l'avenir, seules quelques marques, comptées sur les doigts d'une main, seront bien prises en charges par les distros linux alternatives ; pour les autres, ce sera sans doute le placard.
Marques comme PP, fairphone, peut etre samsung, sans doute oppo/oneplus.
[^] # Re: Liens avec Mobian ?
Posté par Christophe . Évalué à 2 (+0/-0).
Le tableau n'est pas si sombre que ça: de façon générale, les téléphones avec SoC qualcomm arrivent assez bien à tourner avec un noyau récent. En m'appuyant sur les efforts faits par la communauté postmarketos, j'ai pu faire tourner "assez facilement" le Xiaomi Note 5 et le Xiaomi Mi A1 avec un noyau plutôt récent (6.9.1), et avec quasi toutes les fonctionnalités (le capteur photo reste un point noir).
Ofono et ModemManager ont maintenant une bonne gestion du protocole utilisé par Qualcomm, et Mesa n'est pas trop en retard sur les GPU Adreno.
Donc c'est loin d'être idéal, mais c'est largement mieux que la situation d'il y a 10 ans !
[^] # Re: Liens avec Mobian ?
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0).
Et un handicap important si tu veux t'en passer au jour le jour une fois que t'es habitué à en avoir une à porter sans avoir à trimballer une camera compacte avec toi.
[^] # Re: Liens avec Mobian ?
Posté par gnumdk (site web personnel) . Évalué à 2 (+0/-0).
Oui, via le fait de tout essayer d'upstream vers Debian et les projets comme GNOME, NetworkManager, …
# noyau figé
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 17 octobre 2024 à 12:22.
Si je comprends bien d'après le journal précédent, droidian utilise le noyau linux fourni avec le android du modèle de smartphone supporté pour avoir accès à tous les drivers matériels.
Mais du coup la version du noyau est figée complètement où des patches de secu sont backportés et le noyau recompilé de manière régulière?
Ou t'es condamné à utiliser un vieux noyau tout troué et jamais mis à jour comme si tu utilisais la rom d'origine?
[^] # Re: noyau figé
Posté par tkr . Évalué à 3 (+2/-0).
Hybris et halium apportent des drivers "compatibles android", un peu comme sailfish le fait.
Ce pourquoi j'ai du mal à voir l'indépendance envers android/AOSP : si google bouge un curseur demain, beaucoup devront s'y aligner.
C'est la raison pour laquelle je préfère postmarketos : le downstream est très peu apprécié, le mainline beaucoup plus considéré car indépendant d'AOSP en premier lieu, et base commune en second lieu pour le développement logiciel. Un appareil nécessitant halium/hybris me parait condamné aux choix de google, et aux restrictions de développement des fabricants et de qualcomm. C'est en tout cas ce qui attend l'univers des distros linux mobiles pour les prochaines années.
[^] # Re: noyau figé
Posté par Christophe . Évalué à 3 (+1/-0). Dernière modification le 17 octobre 2024 à 16:41.
Halium/libhybris est un projet né d'un choix pragmatique: à l'époque, la possibilité d'avoir une gestion décente du matériel avec un noyau "mainline" était quasi inexistante.
La dépendance à Google n'est pas vraiment le problème ici: la couche Android est minimale, et ne sert qu'à dialoguer avec les pilotes. On peut garder un vieil Android, le risque pour les données ou l'appareil est quand même très restreint.
Le gros souci, c'est plutôt le noyau, qui est lié aux pilotes non maintenus par le constructeur: on est condamné à utiliser un vieux noyau, qui ne bougera quasiment plus.
Et pour qualcomm, le mainline ne résoud pas grand chose: si demain ils décident d'abandonner le protocole QRTR pour le modem 4G/5G et passent à un truc non documenté et obscur, ofono et ModemManager mettront un certain temps avant de trouver une solution, si jamais elle existe.
[^] # Re: noyau figé
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0).
Oui il est important pour le support Linux de sortir du niveau expérimental et atteindre au moins le status de "marché de niche" pour être pris en compte par les constructeurs.
[^] # Re: noyau figé
Posté par gnumdk (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 17 octobre 2024 à 17:37.
Clairement le noyau est un problème mais c'est aussi une partie de la solution.
Pour l'instant, même sur le téléphone le mieux supporté par PMOS (que j'ai à la maison), c'est clairement pas utilisable, le routage du son fonctionne très mal, la caméra pas du tout et l'autonomie est vraiment pas terrible.
De l'autre côté tout fonctionne mais on dépend d'un noyau ancien mais quand même patchable pour les plus grosses failles du noyau Linux mainline.
En particulier, on peut backport pas mal de chose depuis les noyaux encore maintenus sur un vieux noyau comme le 4.14.
https://github.com/droidian-devices/linux-android-xiaomi-miatoll/commits/feature/next/testing
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.