Rapport d’avancement d’Asahi Linux 7.0

 (asahilinux.org)
1 points par GN⁺ 3 일 전 | 1 commentaires | Partager sur WhatsApp
  • La prise en charge de Linux sur Apple Silicon progresse simultanément sur plusieurs fronts : automatisation de l’installateur, gestion de l’alimentation, audio, affichage et activation du M3
  • Asahi Installer a été remanié pour séparer les manifestes d’images de la base de code et adopter un déploiement via GitHub workflow, afin de permettre des mises à jour plus fréquentes ; la version 0.8.0 apporte aussi la mise à jour de m1n1 stage 1, la prise en charge de l’installation sur Mac Pro et un mode de mise à jour du firmware
  • Le firmware d’étalonnage ALS peut désormais être extrait depuis macOS et mis à jour à nouveau après l’installation ; les coupures audio Bluetooth ont disparu grâce à la prise en charge des commandes de coexistence Broadcom, et la prise en charge de PMP réduit d’environ 0,5 W la consommation au repos sur M1 Pro
  • La prise en charge de la VRR n’est pas encore exposée correctement à l’espace utilisateur en raison des contraintes du DCP d’Apple, mais une fois la pull request fusionnée, il sera possible de l’activer de force via un paramètre de module du noyau ; le travail d’upstreaming de la pile audio inclut aussi une API générique de bus keeper et la prise en charge de fréquences d’échantillonnage supplémentaires pour le CS42L84
  • L’étendue de la prise en charge du M3 s’élargit à PCIe, aux périphériques d’entrée, au RTC, au reboot controller et au NVMe, tandis que Fedora Asahi Remix 44 maintient une sortie alignée sur Fedora 44 avec un nouveau flux d’installation basé sur Plasma

Automatisation de l’installateur et mises à jour du firmware

  • Asahi Installer, qui avait été peu mis à jour pendant près de deux ans, voyait son rythme d’évolution freiné par une procédure de publication manuelle et une dépendance à des droits administrateur sur le CDN, tandis que les changements accumulés depuis le tag de juin 2024 devenaient importants
  • Dans une installation UEFI uniquement, seuls m1n1 stage 1, le Devicetree et U-Boot sont installés ; si le Devicetree embarqué dans le bundle de l’installateur ne correspond pas à ce qu’attend le noyau, cela peut empêcher totalement le démarrage
    • Avec l’avancement de l’upstream, les bindings Devicetree ont changé, accumulant les décalages, et dans le kernel 6.18 les modifications autour de l’USB Apple sont devenues si nombreuses qu’il n’était plus possible de démarrer un live media en 6.18 ou plus
  • Le manifeste des images installables a été séparé dans asahi-installer-data, ce qui permet désormais de le mettre à jour indépendamment de la base de code de l’installateur
  • Le déploiement de asahi-installer est maintenant automatisé via GitHub workflow
    • Un push sur la branche main déclenche automatiquement une compilation et un envoi vers https://alx.sh/dev
    • Un push de tag GitHub est automatiquement déployé sur https://alx.sh
  • La version 0.8.0 la plus récente met à jour le m1n1 stage 1 embarqué vers la 1.5.2 et ajoute la prise en charge de l’installation sur Mac Pro ainsi qu’un mode de mise à jour du firmware

ALS et extraction du firmware

  • Dans l’environnement True Tone d’Apple, il faut mesurer non seulement la luminosité ambiante mais aussi les caractéristiques colorimétriques de l’éclairage ; le traitement des données ALS et la précision de l’étalonnage deviennent donc essentiels
  • L’AOP et le pilote ALS fonctionnaient déjà, mais sans données d’étalonnage, la précision des données ALS brutes produites par l’AOP restait faible
    • Ces données d’étalonnage sont un blob binaire qui doit être chargé dans l’AOP à l’exécution ; comme il ne peut pas être redistribué, il doit être récupéré depuis macOS lors de l’installation
  • Asahi Installer regroupe les firmwares nécessaires à Linux et les stocke dans l’EFI System Partition, puis un module Dracut les monte dans des sous-répertoires sous /lib/firmware/ afin que les pilotes puissent les trouver
  • Pour éviter qu’un firmware supplémentaire ne devienne nécessaire après l’installation, l’installateur prend désormais en charge la mise à jour automatique des vendor firmware packages
    • À partir de l’ALS, il est possible de démarrer sur macOS ou macOS Recovery, de relancer l’installateur et de suivre les invites pour mettre à jour le firmware requis
  • La prise en charge de l’ALS et des futures mises à jour de firmware nécessite Asahi kernel 6.19 ou plus récent ainsi que iio-sensor-proxy

Gestion de l’alimentation et PMP

  • La consommation au repos restait un problème persistant, surtout sur les SoC Pro/Max/Ultra, dont la gestion de l’alimentation repose sur une architecture complexe impliquant à la fois PMGR et PMP
  • PMGR est chargé d’activer et de désactiver les domaines d’alimentation du SoC, tandis que PMP reçoit et traite les rapports d’état d’alimentation transmis en mémoire partagée entre les blocs du SoC et les cœurs applicatifs
    • Si PMP ne démarre pas, il ne peut pas lire ces rapports et certaines fonctions de gestion de l’alimentation cessent aussi de fonctionner
  • Le pilote de prise en charge de PMP créé par chaos_princess permet à PMP de recevoir les rapports des blocs du SoC et de PMGR, et obtient environ 0,5 W d’économie au repos sur un MacBook Pro M1 Pro 14 pouces
    • Cela correspond à une baisse d’environ 20 % de la consommation au repos
  • Il reste encore du travail pour atteindre les temps de repos et de veille de macOS, mais ce changement représente déjà une avancée majeure
  • Le M1 de base utilise une ancienne variante de PMP incompatible avec les générations suivantes, et dd-dreams travaille sur cette prise en charge
  • PMP n’a pas encore été validé sur tous les appareils pris en charge et il n’est pas prévu de l’activer par défaut avant sa fusion upstream
    • Les utilisateurs capables de modifier le Devicetree peuvent l’activer en définissant APPLE_USE_PMP dans le DTS de leur appareil

Correction des coupures audio Bluetooth

  • Bluetooth et Wi‑Fi partagent la même bande 2,4 GHz, ce qui les rend sujets aux interférences, et les connexions sensibles à la latence et à la continuité, comme les flux audio, nécessitent une priorité plus élevée
  • La configuration de coexistence de Broadcom passe par des commandes d’extension vendor-specific du Bluetooth HCI, mais le noyau Linux upstream ne les prenait pas en charge, provoquant des pertes de paquets audio pendant les scans Bluetooth
    • Si KDE Connect déclenchait un scan Bluetooth, cela pouvait entraîner des coupures audio
  • chaos_princess a ajouté la prise en charge de ces commandes à la pile Bluetooth du noyau, et comme BlueZ marque tous les flux audio comme high priority, les commandes nécessaires sont automatiquement déclenchées pendant le streaming
  • Résultat : les coupures audio Bluetooth ne se produisent plus

DCP et VRR

  • L’interface du firmware DCP est très vaste et instable selon les versions, et pendant longtemps, après la prise en charge de base de l’affichage, d’autres travaux matériels sont passés en priorité, laissant des fonctions comme la VRR de côté
  • La prise en charge de la VRR nécessite à la fois un échange de paquets spéciaux entre le contrôleur d’affichage et l’écran, un ajustement du vertical blanking selon le moment d’affichage des images, l’annonce des capacités VRR de l’écran et l’intégration avec KMS
  • Le traçage a révélé qu’un paramètre DCP, auparavant réglé à 0 lors de l’alimentation d’un écran externe, basculait entre 0x300000 et 0x0 lors de l’activation ou de la désactivation de la VRR
    • L’écran de test avait une fréquence minimale de 48 Hz, et dans le format en virgule fixe du DCP, 48 valait 0x300000
    • Ce paramètre n’était donc pas lié à la séquence d’alimentation, mais au basculement de la fréquence minimale VRR ; écrire 0 avant le modeset désactivait la VRR
  • L’écran interne ProMotion du MacBook Pro s’active de la même manière, mais comme le panneau interne n’annonce pas EDID/DisplayID, le pilote Linux doit déterminer qu’il s’agit d’un LCD interne et définir statiquement les propriétés nécessaires
  • VESA DisplayPort Adaptive Sync et l’API KMS n’autorisent pas qu’un changement d’état VRR impose un modeset, alors que le DCP d’Apple ne peut pas l’éviter
    • À cause de cette contrainte, il n’est pas possible d’exposer correctement la VRR à l’espace utilisateur, et KWin ignore ce type d’interface
  • Pour l’instant, une fois cette pull request fusionnée, il sera possible d’activer la VRR forcée avec le paramètre de module du noyau appledrm.force_vrr
    • Si l’écran prend en charge la VRR, le DCP l’utilisera sans le signaler à KMS ni au compositor
    • Cela fonctionnait bien avec KWin, mais l’expérience peut varier avec d’autres compositors
  • Côté HDMI, les transitions VRR n’interdisent pas un modeset, et d’autres contrôleurs d’affichage comme ceux d’Intel fonctionnent de manière similaire
    • En upstream, la discussion porte soit sur un mode VRR toujours activé, soit sur l’autorisation d’un modeset pendant les transitions ; une fois l’orientation fixée, la VRR devrait être exposée de la manière attendue

Upstream de la pile audio et extension des fréquences d’échantillonnage

  • Le travail d’upstreaming de l’ensemble de la pile audio se poursuit, et les pilotes liés aux prises casque et amplificateurs de haut-parleurs Cirrus Logic et Texas Instruments, aux périphériques I2S et aux modifications du contrôleur DMA Apple ont déjà été fusionnés
  • La protection des haut-parleurs sur cette plateforme repose sur un schéma où l’amplificateur TI envoie tension et courant au SoC via I2S, qui calcule ensuite la température de la bobine mobile avec les paramètres de Thiele/Small du haut-parleur
    • Sur macOS, cette fonction est assurée par CoreAudio ; sous Linux, c’est speakersafetyd qui s’en charge
  • Dans cette architecture où les broches de transmission de données de plusieurs amplificateurs sont chaînées en série et où les lignes gauche et droite sont combinées par OR, il faut une configuration de bus keeper pour garantir qu’un côté force un niveau logique bas pendant que l’autre transmet
  • Jusqu’ici, le bus keeper était géré via des pilotes de puces d’amplification et un binding Devicetree dédié, mais cela s’est révélé trop restrictif pour l’upstream et a été remplacé par une API générique
    • Désormais, n’importe quel composant ASoC peut exposer la présence d’un bus keeper configurable, et le pilote de plateforme peut appliquer à l’exécution les réglages nécessaires
    • Cette série de patchs a été fusionnée dans Linux 7.1
  • La prise en charge des variantes de puces spécifiques à Apple continue elle aussi de s’élargir
    • Pour les amplificateurs TI, l’ajout de la prise en charge des variantes Apple dans les pilotes upstream TAS2764 et TAS2770 s’est fait relativement facilement
    • Le CS42L84 diffère davantage du CS42L42 et a donc nécessité un pilote Linux distinct, déjà intégré upstream
  • Se baser uniquement sur le traçage de macOS avait la limite de n’exposer que les fonctions utilisées par macOS, ce qui avait conduit le CS42L84 à ne prendre initialement en charge que 48 kHz et 96 kHz
    • Cette limitation obligeait PipeWire à rééchantillonner les autres flux, augmentant la charge CPU, la consommation de batterie et dégradant la qualité audio
  • En appliquant au pilote CS42L84 d’autres valeurs de fréquences d’échantillonnage courantes issues de la fiche technique du CS42L42, la prise en charge matérielle de 44,1, 88,2, 176,4 et 192 kHz fonctionne désormais à la fois en entrée et en sortie sur la prise casque
    • Le patch correspondant a été soumis upstream, fusionné dans Linux 7.1, puis backporté dans Asahi kernel 6.19.9

Extension de la prise en charge du M3

  • L’arbre de noyau Asahi reçoit aussi des patchs supplémentaires d’activation matérielle pour les appareils M3
  • Le périmètre couvert s’étend désormais à PCIe, au clavier et au trackpad des MacBook, au RTC basé sur le SMC, au reboot controller et au contrôleur NVMe
  • Grâce au travail de Michael Reeves et Alyssa Milburn, le niveau de prise en charge de Linux sur M3 a atteint un stade globalement comparable à celui de la première alpha d’Asahi Linux pour M1
  • L’ouverture immédiate de l’installation sur M3 via Asahi Installer n’est pas encore prête, mais les progrès continuent

Fedora Asahi Remix 44

  • Malgré le retard de Fedora Asahi Remix 43, Fedora Asahi Remix 44 prévoit toujours une sortie le 28 avril, en même temps que Fedora Linux 44 ou dans les jours qui suivent
  • La nouvelle installation basée sur KDE Plasma exploitera les nouvelles fonctions de Plasma 6.6
    • Plasma Setup remplace l’ancien assistant de configuration basé sur Calamares et fournit un flux natif Plasma pour la création de compte et la configuration du système
    • Plasma Login Manager devient le greeter et le session manager par défaut, en remplacement de SDDM
  • Ce changement ne s’applique qu’aux nouvelles installations ; la configuration des utilisateurs ayant fait une mise à niveau depuis une ancienne version de Fedora Asahi Remix ne sera pas modifiée
  • Fedora Asahi Remix 44 met fin aux paquets vendored de Mesa et virglrenderer
    • Les utilisateurs n’ayant pas encore basculé manuellement seront automatiquement migrés vers les paquets Mesa et virglrenderer des dépôts Fedora upstream

Soutien et infrastructure

À lire aussi

1 commentaires

 
GN⁺ 3 일 전
Réactions sur Hacker News

  • Le CS42L84 était configuré sous macOS pour n’utiliser que 48/96 kHz, mais quelqu’un a pris d’autres valeurs de fréquences d’échantillonnage depuis la fiche technique du CS42L42 et les a injectées dans le pilote, et cela a fonctionné tel quel
    Un patch ajoutant la prise en charge de 44,1/88,2/176,4/192 kHz sur l’entrée/sortie de la prise casque a été accepté en upstream, fusionné dans 7.1, puis rétroporté dans le noyau Asahi 6.19.9, ce qui le rend immédiatement utilisable
    Le travail de traçage de puce et de reverse engineering est vraiment impressionnant

    • Le plus surprenant, c’est que le fait de ne prendre en charge que 48/96 kHz oblige PipeWire à faire du rééchantillonnage, ce qui consomme plus de CPU et de batterie
      Apple est pourtant une entreprise obsédée par l’efficacité énergétique, donc on se demande pourquoi ils laissent encore ça ainsi
    • Le fait de pouvoir enfin lire des CD/FLAC en 44,1 kHz bit-perfect semble être une fonctionnalité vraiment importante

  • Les billets techniques et les résultats de l’équipe Asahi sont vraiment impressionnants, mais il est tout de même un peu inquiétant que cela reste encore un projet séparé, au lieu d’être quelque chose de pérenne dans le kernel mainline ou dans des distributions majeures comme Ubuntu, Debian ou Fedora
    Les projets de reverse engineering peuvent assez facilement produire des résultats utiles jusqu’à 80 %, mais atteindre un niveau de 95 % de finition réellement suffisant pour les utilisateurs ordinaires demande presque autant de travail pénible et minutieux en plus

    • Asahi fait justement beaucoup d’upstreaming dans cette direction
      L’une des grandes raisons du ralentissement récent est qu’ils se sont concentrés sur la réduction du nombre de diff, et une quantité assez importante de travail a déjà été intégrée au kernel mainline
      Asahi sert aussi d’espace d’expérimentation pour de nouvelles fonctionnalités
    • Il y a aussi la difficulté supplémentaire que les Mac ARM sont une cible mouvante
      Apple n’a absolument aucune intention d’offrir de la stabilité ou du support pour Asahi Linux, et n’a aucune raison d’assurer une compatibilité à long terme comme dans l’industrie du PC, donc ils continueront probablement à faire des changements qui compliquent la vie d’Asahi sans s’en soucier
    • L’un des bons côtés de Linux, c’est que c’est du logiciel libre, donc sans dépendance vis-à-vis des actionnaires ou de la rentabilité
      J’utilise Asahi comme OS principal sur un MacBook Air M1 et j’en suis assez satisfait ; même s’il y a des points frustrants comme 1 % de batterie perdu par heure en veille, c’est malgré tout bien mieux de l’avoir dans son état actuel que de ne pas l’avoir du tout sous prétexte qu’il n’est pas finalisé à 100 %
      Je ne ressens pas vraiment le besoin qu’il soit parfaitement poli pour le grand public
    • Le développement du kernel mainline fonctionne de toute façon comme ça : tout le monde travaille dans son propre fork, puis envoie des patchs en upstream
      Si Asahi paraît particulier, c’est simplement parce qu’il y a beaucoup de matériel étrange et propriétaire, donc beaucoup de pilotes spécialisés à écrire ; personne ne développe directement dans l’arbre de Linus
    • La présentation de la 39c3 https://youtu.be/3OAiOfCcYFM était bien aussi
      Au final, l’objectif est que Linux prenne en charge Apple Silicon nativement

  • J’espère que ce projet continuera à gagner en élan
    La combinaison matériel Apple + Linux donne l’impression d’être l’OS le moins cassé tournant sur le meilleur matériel, tandis que macOS devient de plus en plus confus à cause des bugs et des changements qui se renversent d’une version à l’autre

    • Essayer Fedora sur un Framework pourrait peut-être faire changer d’avis
      L’expérience a été extrêmement fluide, et le futur Framework 13 Pro pourrait atteindre le niveau de macOS pour la batterie et le trackpad, voire faire mieux sur la batterie
    • J’ai utilisé les trois grands OS, et macOS était celui qui avait le moins de bugs et qui fonctionnait tout simplement le mieux
      Sous Linux, je me retrouvais toujours à bricoler des patchs bizarres pour l’audio ou la compatibilité d’affichage, et sous Windows l’autonomie posait de gros problèmes
      On a parfois l’impression qu’au fond, beaucoup de gens qui aiment peaufiner Linux veulent surtout une expérience proche du Mac, mais avec davantage de possibilités de personnalisation
    • Dans l’ensemble oui, mais l’écosystème autour de MLX est déjà assez solide
      Même si les performances disque ne sont pas terribles et que l’OS a des bugs, au moins le ML se compile et tourne sur un OS récent
      À l’inverse, rocm semble presque prêt puis devient frustrant parce qu’il faut des paquets précompilés ou une Ubuntu vieille de plus de deux ans
      https://github.com/ROCm/TheRock/issues/3477
    • J’ai récemment utilisé un MacBook Air pour le travail, et j’ai du mal à être d’accord avec l’idée que le matériel est au plus haut niveau
      J’ai l’impression qu’avec 5 euros on peut déjà trouver un meilleur clavier

  • Je comprends mal pourquoi Apple ne coopère pas avec cet effort et ne publie pas la documentation
    Les raisons traditionnelles comme l’avantage concurrentiel ou le secret ne semblent plus très convaincantes aujourd’hui

    • La vraie raison est peut-être plus simple
      Apple a de très fortes marges sur le matériel, donc vendre des MacBook à des utilisateurs Linux reste rentable ; mais à partir du moment où l’entreprise reconnaît officiellement le support de Linux, cela devient immédiatement une responsabilité de support
      Chaque kernel panic signifierait une visite au Genius Bar, et chaque bug de pilote déclencherait un appel à @AppleSupport ; du point de vue d’Apple, la situation actuelle non officielle est peut-être le meilleur scénario possible, avec les ventes de matériel sans la charge du support
    • Il n’y a quasiment aucun bénéfice financier, et il faudrait en plus maintenir de la documentation Linux à chaque évolution du matériel
      Le fait que ce soit une base d’utilisateurs petite mais parmi les plus bruyantes et critiques n’a probablement rien de très attractif pour Apple non plus
    • Tracer clairement la ligne avec un « nous ne jouons pas à ce jeu » peut être bien plus simple que d’être critiqué pour une ouverture sélective ou pour avoir cassé la compatibilité d’interfaces non publiques
      En interne aussi, cela évite de rouvrir sans cesse des débats sans rapport avec les priorités
    • J’ai l’impression que cela touche presque au right to repair
      Un ordinateur portable est composé de plusieurs éléments matériels et des pilotes qui les font fonctionner ; cela amène à se demander si ce que j’ai acheté est un package indissociable matériel + pilotes, ou si je devrais recevoir les manuels me permettant de sauver l’un si l’autre casse
      Apple peut prétendre qu’un pilote ne s’use pas comme un engrenage ou un moteur, mais cela ne supprime pas pour autant, à mes yeux, le droit de comprendre son fonctionnement
      Je ne serais pas surpris de voir un jour un cas de test devant les tribunaux où quelqu’un exigerait la documentation en disant que /System/Trackpad.kext a été frappé par un vaisseau spatial et qu’il faut désormais réécrire le pilote soi-même
    • Ça me semble juste
      Ce serait facile pour Apple de prendre cela en charge, et cela leur apporterait sans doute aussi beaucoup de bonne volonté de la part de la communauté

  • Je me demande s’il y aurait un intérêt pour une variante Asahi Remix axée sur une expérience par défaut façon Mac
    Avec cmd comme touche de modification principale, des raccourcis et thèmes de style Mac, et les gestes configurés par défaut
    On peut bricoler n’importe quelle distribution pour obtenir cela, mais des valeurs par défaut bien sélectionnées ont aussi leur valeur

    • Faire de cmd la « touche de modification principale » est ambigu
      Dans un environnement X/Wayland classique, Cmd est déjà au centre pour les fonctions du DE, tandis qu’au niveau des applications c’est plutôt Ctrl ; changer cela crée beaucoup de chevauchements
    • J’ai réussi à obtenir quelque chose d’assez proche sous KDE
      J’ai demandé à Claude Code de l’implémenter, et il a fait des recherches web puis m’a même généré les fichiers de configuration
    • Une disposition de touches centrée sur Cmd ressemble en pratique à une bataille déjà perdue
      J’ai essayé plusieurs fois, puis j’ai fini par accepter la vie avec Ctrl et j’ai vendu mon dernier MacBook

  • Je me demande si, pour concrétiser d’abord la machine de développement idéale MacBook Pro + Linux, l’avance viendra du matériel ou du logiciel
    Reste à voir si Asahi y arrivera en premier côté logiciel, ou si Framework y arrivera en premier côté matériel

  • Une combinaison MacBook Neo + Asahi serait vraiment redoutable

  • C’est réjouissant de voir que la prise en charge du M3 progresse régulièrement pendant qu’ils résorbent le backlog upstream et améliorent les outils
    Des patchs de prise en charge de PCIe, du clavier et du trackpad des MacBook, du RTC basé sur le SMC, du reboot controller et du contrôleur NVMe sont en train d’entrer dans l’arbre du noyau Asahi, ce qui place le niveau de support Linux du M3 à peu près au stade du premier alpha d’Asahi Linux pour M1

    • À ce rythme, il ne sera peut-être vraiment utilisable qu’au moment de la sortie du M6

  • Le fait que ces rapports de projet continuent à apporter des percées et identifient avec précision les points où les utilisateurs rencontrent de vraies frictions montre à quel point l’équipe Asahi est expérimentée
    Ça me donne envie de revenir complètement sur Asahi très bientôt

  • Les nouvelles sur un M3 proche de l’alpha sont excellentes, et cela donne aussi envie de voir arriver le M4
    En revanche, je n’attends absolument rien de ce qu’Apple pourrait encore faire subir à macOS cette année ou l’an prochain