Asahi Linux est sur le point de prendre en charge officiellement les Mac équipés des puces M3 d'Apple

Et les travaux sur les modèles M4 et M5, plus récents, sont déjà en cours

Asahi Linux est sur le point d’assurer une prise en charge officielle des Mac équipés des puces Apple M3. Après des mois passés à procéder à la rétro-ingénierie du matériel d'Apple, le projet intègre désormais une prise en charge des webcams, des microphones, de l’USB 3.0, du Thunderbolt, ainsi que des écrans, dont la prise en charge est presque équivalente à celle des systèmes M1/M2. Ces progrès permettent ainsi au projet d'être suffisamment abouti pour une sortie officielle. Parallèlement, les développeurs ont déjà commencé à travailler sur les systèmes équipés des puces M4 et M5, en activant la prise en charge du stockage NVMe et la détection des périphériques PCIe, et en corrigeant un bug lié aux processeurs multicœurs. Aucune de ces nouvelles puces n’est toutefois encore prête pour une utilisation quotidienne sous Linux : la plupart des matériels ne fonctionnent pas encore et aucun des deux modèles ne peut être installé via l'Asahi Installer.

Asahi Linux est un projet lancé par Hector Martin visant à porter le noyau Linux et les logiciels associés sur les Mac équipés d'Apple Silicon. Pour ce faire, il procède à une rétro-ingénierie des SoC, pour lesquels il n'existe aucune documentation officielle mise à la disposition du public par Apple.

Selon un communiqué publié le 26 août dernier, Asahi Linux est sur le point de prendre officiellement en charge les Mac équipés des puces M3 d'Apple, et les travaux concernant les modèles plus récents, les M4 et M5, sont déjà en cours.


La prise en charge complète de la webcam est désormais disponible pour tous les Mac de la série M3 équipés d’une caméra intégrée. Le matériel est globalement identique à celui d’avant, mais le M3 Max a nécessité une légère modification du pilote pour fonctionner correctement.

Les microphones intégrés fonctionnent maintenant sur toute la gamme M3. Apple ayant modifié le matériel audio pour cette génération, l'équipe a dû effectuer un travail supplémentaire de rétro-ingénierie avant que Linux puisse l'utiliser correctement. Les ports USB 3.0 et Thunderbolt fonctionnent également sur tous les Mac M3.

La prise en charge des écrans sur les Mac M3 est presque aussi complète que celle des systèmes M1 et M2. Asahi affirme que la prise en charge du contrôleur d’affichage M3 est pratiquement équivalente à celle disponible pour les anciens modèles Apple Silicon. Grâce à tous ces progrès récents, le projet est désormais suffisamment abouti pour une sortie officielle.

Les travaux vont également au-delà de la génération M3. Les développeurs d’Asahi ont activé le stockage NVMe sur les systèmes M4 et les premiers modèles M5 en adaptant Linux et l’environnement de démarrage m1n1 au micrologiciel mis à jour du contrôleur de stockage d’Apple.

La prise en charge du PCIe a été améliorée, ce qui permet désormais à Linux de détecter les périphériques présents sur le bus. L'équipe a également corrigé un bug qui provoquait le plantage de Linux après le démarrage lorsque plusieurs cœurs de processeur étaient activés.

Cependant, les Mac M4 et M5 ne sont pas encore prêts pour une utilisation quotidienne sous Linux. Asahi précise que la plupart des composants matériels ne fonctionnent toujours pas et qu'aucun des deux modèles ne peut être installé via l'Asahi Installer. Néanmoins, la prise en charge du stockage, du PCIe et des processeurs multicœurs constitue une première étape importante.

L'équipe progresse par ailleurs dans le domaine du décodage vidéo accéléré par le matériel. La prise en charge du décodeur vidéo d'Apple permet désormais un décodage fiable des formats H.264, H.265 et VP9 sur les machines compatibles. Les Mac équipés d'un processeur M3 ou plus récent prennent également en charge le décodage AV1.

Enfin, l'équipe s'attaque à l'un des aspects les moins visibles mais particulièrement importants de l'exécution de Linux sur Apple Silicon : la gestion de l'alimentation du processeur. Les processeurs Apple gèrent différemment les états de faible consommation du CPU ; c'est pourquoi Asahi a utilisé jusqu'à présent un pilote Linux spécifique à Apple. Selon les développeurs, cela fonctionne, mais ils ne peuvent pas l'intégrer au code principal de Linux car les mainteneurs d'ARM64 exigent l'utilisation de l'interface standard de coordination des états d'alimentation (Power State Coordination Interface, ou PSCI).

Cette évolution d’Asahi Linux intervient toutefois dans un contexte de tensions internes qui ont récemment marqué le projet et son rapport au développement du noyau Linux. En février 2025, Hector Martin, mainteneur principal d’Asahi Linux, a annoncé sa démission après un conflit autour de l’intégration de Rust dans Linux, reprochant notamment à Linus Torvalds un manque de soutien. Le désaccord portait sur un correctif permettant aux pilotes écrits en Rust d’utiliser l’API DMA du noyau, principalement développé en C. Certains observateurs estiment que ces tensions entre défenseurs du C et du Rust auraient pu être évitées si Linux avait opté pour la conversion du code C du kernel vers du C++ moderne.

L'extrait du communiqué d'Asahi Linux, présenté ci-dessous, fournit des détails supplémentaires :

Encore des progrès sur la M3 !

Les travaux visant à porter Asahi Linux sur les appareils de la série M3 avancent.

Le processeur de signal d'image de la webcam est resté pratiquement inchangé, à l'exception d'un seul message d'initialisation ignoré sur le M3 Max en particulier. chaos_princess a ajouté la prise en charge de ce message au pilote Linux, ce qui a permis d'activer la prise en charge complète de la webcam sur tous les appareils de la série M3 équipés d'une webcam intégrée.

Les microphones intégrés ont également subi quelques modifications. Les appareils de la série M3 intègrent désormais un décimateur « haute fréquence » qui nécessite un nouvel ensemble de coefficients et un message d'initialisation beaucoup plus volumineux. Une fois de plus, chaos_princess a réussi à résoudre ce problème en un clin d'œil, permettant ainsi la prise en charge des microphones sur tous les appareils de la série M3 qui en sont équipés.

ATCPHY — le bloc matériel chargé de négocier les connexions USB 3, DisplayPort et Thunderbolt via les ports USB Type-C — a également subi de légères modifications, nécessitant une nouvelle séquence de paramètres réglables lors de l'initialisation en raison du passage au nœud de fabrication N3 de TSMC.

Même si notre hypothèse selon laquelle Apple éviterait d'apporter des changements architecturaux radicaux juste pour le plaisir s'est globalement vérifiée, nous avons bien sûr constaté quelques changements de ce type…

Tous les appareils de la série M1 à la série M3 de base utilisaient un contrôleur de port USB Texas Instruments spécifique à Apple, appelé CD3217 (ou ACE2). Celui-ci est connecté au bus I2C et négocie avec les périphériques USB lorsqu’ils sont branchés. À partir des modèles M3 Pro/Max, Apple est passé à l’ACE3. L’ACE3 utilise quant à lui le bus SPMI, ce qui a nécessité un peu plus de rétro-ingénierie. Grâce aux efforts conjoints de mildsunrise et chaos_princess, nous avons découvert que l’ACE3 dispose pratiquement du même jeu de registres que le CD3217, mais encapsulé dans une interface SPMI au lieu d’être adressé via I2C. L’interface SPMI et l’ACE3 lui-même fonctionnent désormais sous Asahi Linux, apportant ainsi la prise en charge de l’USB 3.0 et du Thunderbolt à tous les appareils de la série M3.

Un changement majeur auquel nous nous attendions concernait l’ABI du micrologiciel, tant pour le GPU que pour le contrôleur d’affichage. Étant donné que les micrologiciels de l’AGX et du DCP sont associés à une version spécifique de macOS, Apple n’a pas à se soucier de maintenir la stabilité de l’interface d’une version à l’autre. C’est l’une des principales raisons pour lesquelles nous « ciblons » des versions spécifiques de macOS pour chaque génération de matériel. Les machines de la série M3 cibleront l’ABI de macOS 14.8.3, et la prise en charge du DCP est désormais presque équivalente à celle de l’ABI existante de macOS 13.5 que nous utilisons pour les M1 et M2 !

Compte tenu de tous ces progrès, qui viennent s'ajouter aux étapes déjà franchies sur la version M3, nous sommes ravis d'annoncer que nous sommes sur le point de lancer une version officielle !

N'oubliez pas non plus les M4 et M5 !

Non content de contribuer uniquement au développement du M3, Yureka a également travaillé sur le M4 et même sur les premières étapes de mise en service du M5. Outre le problème de WFI sur le M4, ces SoC ont été affectés par un changement majeur dans le firmware du contrôleur NVMe d’Apple, inclus dans le pack de firmware macOS 15.x. Yureka et Sven ont collaboré pour analyser ces modifications et les implémenter à la fois sur m1n1 et sous Linux. Nous disposons donc désormais d’un NVMe fonctionnel sur les M4 et M5 !

Yureka a également réussi à rendre le PCIe fonctionnel au point que les périphériques présents sur le bus puissent être détectés par Linux, et a corrigé un problème qui provoquait le plantage de Linux peu après le démarrage lorsque plusieurs cœurs de processeur étaient activés. Peu d’autres fonctionnalités fonctionnent pour l’instant sur les M4 et M5 ; nous ne sommes donc pas encore tout à fait prêts à les activer dans l’Asahi Installer, mais comme toujours, nous vous en dirons plus en temps voulu.

La vidéo sur bureau est compliquée

La dernière fois, nous avions annoncé une prise en charge préliminaire du décodeur vidéo Apple (Apple Video Decoder, ou AVD). Ce bloc matériel accélère le décodage vidéo H.264 (AVC), H.265 (HEVC) et VP9 sur les puces M1 et M2, ainsi que le décodage AV1 sur les machines équipées d’une puce M3 ou supérieure. Depuis lors, la prise en charge de l’AVD a été encore affinée par sofus, et les formats AVC, HEVC et VP9 fonctionnent désormais de manière globalement fiable sur toutes les machines prises en charge par Asahi Linux ! Nous en sommes désormais au stade où nous envisageons l’intégration au bureau, et c’est là que les choses commencent à se compliquer…

Le matériel AVD est fondamentalement « sans état », ce qui signifie qu’il se contente de prendre une image encodée et de la transformer en tampon vidéo. Le matériel n'effectue aucune analyse du flux binaire, aucun suivi des sessions de décodage, ni aucune autre gestion du pipeline de décodage. Cela s'accorde parfaitement avec l'API V4L2 Stateless, conçue spécialement pour ce type de décodeurs. Bien que cette API ait fait son apparition dans le noyau en amont il y a plus de 10 ans, son adoption dans l'espace utilisateur a été lente en dehors des logiciels spécialisés destinés aux appareils embarqués. GStreamer offre une prise en charge de base de V4L2 Stateless, mais FFmpeg (et tout ce qui l'utilise) ne le prend pas en charge sans correctifs hors arborescence. Les logiciels de bureau, tels que les navigateurs web, se sont historiquement concentrés sur VA-API, NVDEC et VDPAU. Plus récemment, les efforts sur les ordinateurs de bureau ont commencé à s'orienter vers Vulkan Video. Cela a conduit à l'abandon effectif de V4L2 Stateless avant même qu'il ne soit véritablement adopté par les logiciels de bureau.

Tout espoir n'est toutefois pas perdu. La VA-API est désormais quasi universellement présente dans les logiciels destinés aux ordinateurs de bureau, grâce à son adoption par AMD et Intel pour leurs composants matériels d'accélération vidéo. Afin d'éviter que le matériel V4L2 Stateless ne soit incompatible avec ces logiciels, Bootlin a développé une couche de traduction entre la VA-API et le V4L2 Stateless. Malheureusement, ce projet a été abandonné depuis un certain temps et ne peut plus être compilé sans correctifs. Une version plus récente développée par megi fonctionne cependant, et sofus en a créé un fork qu’il a rendu opérationnel pour AVD. Une fois cette couche de traduction installée et une variable d’environnement définie pour la session de connexion, les logiciels prenant en charge VA-API peuvent désormais utiliser AVD pour accélérer le décodage vidéo ! Cette fonctionnalité n’est pas encore intégrée par défaut dans Fedora Asahi Remix et ne fonctionnera pas avec le bac à sable de décodage vidéo de Firefox ; nous espérons toutefois pouvoir proposer une version utilisable très prochainement.

« Think Different »… encore une fois

L'infrastructure de gestion de l'alimentation de la plateforme Apple Silicon est complexe. Les responsabilités sont réparties entre plusieurs blocs matériels, notamment le SMC, le PMGR et le PMP. Bien que la prise en charge de ces blocs soit importante pour la consommation d'énergie, l'un des principaux obstacles à l'amélioration de l'autonomie de la batterie réside dans les cœurs d'application eux-mêmes.

Il existe plusieurs façons de « mettre en veille » un cœur de processeur, et chacune doit être utilisée dans un contexte spécifique. La méthode la plus simple pour mettre un cœur de processeur ARM en veille consiste à utiliser l’instruction Wait For Interrupt (WFI). Celle-ci ordonne au cœur de cesser toute activité jusqu’à ce qu’il soit réveillé par une interruption provenant d’une source d’interruption. Bien que cela permette d’économiser de l’énergie en empêchant le cœur d’exécuter du code, celui-ci reste sous tension et conserve suffisamment d’informations d’état pour reprendre son travail très rapidement. De ce fait, l’instruction WFI n’est généralement utilisée que pour mettre un cœur en veille sur un système en fonctionnement. Les cœurs Apple intègrent un mode WFI « profond », qui met hors tension une plus grande partie du cœur au prix de la perte de son état. Notre pilote cpuidle en aval fonctionne en configurant la WFI dans ce mode, en sauvegardant l’état du cœur, puis en lançant une boucle WFI.

Ce genre d'anomalies liées à la gestion de l'alimentation, propres à certains fabricants, est assez courant. Heureusement pour les mainteneurs du noyau, il existe une méthode standard pour y remédier : l'interface PSCI (Power State...