Cocoa-Way – un compositeur Wayland pour exécuter nativement des apps Linux sur macOS

 (github.com/J-x-Z)
2 points par GN⁺ 2026-03-30 | 1 commentaires | Partager sur WhatsApp
  • Un compositeur Wayland qui permet d’exécuter des applications Linux sans machine virtuelle sur macOS, avec un rendu basé sur Metal/OpenGL pour une intégration naturelle à l’environnement de fenêtres de macOS
  • Communication directe via le protocole Wayland à travers des sockets Unix afin de minimiser la perte de performances, avec prise en charge de l’optimisation HiDPI et des décorations côté serveur
  • Écrit en Rust, il offre une accélération matérielle du rendu pour une faible latence et une haute efficacité
  • Avec SSH et waypipe-darwin, il est possible d’afficher les applications d’un hôte Linux dans des fenêtres macOS
  • Distribué sous licence GPLv3, avec une feuille de route en cours incluant des extensions backend pour Windows et Android

Vue d’ensemble

  • Cocoa-Way est un compositeur Wayland qui permet d’exécuter des applications Linux sur macOS comme si elles étaient natives
  • Grâce au rendu Metal/OpenGL, il s’intègre naturellement au bureau macOS et prend en charge une connexion directe au protocole Wayland via des sockets, sans machine virtuelle
  • Comprend des fonctions d’optimisation pour les écrans HiDPI, de décorations côté serveur et de rendu accéléré matériellement
  • Écrit en Rust et distribué sous licence GPLv3

Fonctionnalités principales

  • Intégration native à macOS : rendu basé sur Metal/OpenGL maintenant une compatibilité complète avec la gestion des fenêtres et les effets visuels de macOS
  • Zero VM Overhead : communication directe via le protocole Wayland à travers des sockets Unix sans virtualisation afin de minimiser la perte de performances
  • Prise en charge HiDPI : mise à l’échelle et précision au pixel adaptées aux écrans Retina
  • Interface plus aboutie : inclut des fonctions de décoration côté serveur comme les ombres et les indicateurs de focus
  • Accélération matérielle : pipeline de rendu OpenGL efficace pour obtenir une faible latence et de hautes performances

Méthode d’installation

  • Installation via Homebrew (recommandée)

    • brew tap J-x-Z/tap
    • brew install cocoa-way waypipe-darwin

  • Téléchargement du binaire

    • Les fichiers .dmg ou .zip peuvent être téléchargés depuis la page GitHub Releases

  • Compilation depuis les sources

Démarrage rapide

  • Composant requis : installation de waypipe-darwin nécessaire
    • brew tap J-x-Z/tap && brew install waypipe-darwin
  • Lancer le compositeur 
    cocoa-way
  • Connecter une application Linux 
    ./run_waypipe.sh ssh user@linux-host firefox
  • Affiche les applications Wayland d’un hôte Linux dans des fenêtres macOS via SSH

Architecture

  • Côté macOS se trouvent le compositeur Cocoa-Way et le client waypipe
  • Côté VM Linux ou conteneur se trouvent le serveur waypipe et les applications Linux
  • Application Linux → protocole Wayland → serveur waypipe → SSH/socket → client waypipe → Cocoa-Way → Metal/OpenGL → affichage macOS
  • L’ensemble du chemin est directement connecté sans virtualisation, pour une faible latence et une haute efficacité

Comparaison

Solution Latence HiDPI Intégration native Complexité de configuration
Cocoa-Way ⚡ faible ✅ prise en charge complète ✅ fenêtres natives 🟢 facile
XQuartz 🐢 élevée ⚠️ prise en charge partielle ⚠️ particularités de X11 🟡 moyenne
VNC 🐢 élevée ❌ non pris en charge ❌ plein écran uniquement 🟡 moyenne
VM GUI 🐢 élevée ⚠️ prise en charge partielle ❌ fenêtre séparée 🔴 complexe

Feuille de route

  • ✅ backend macOS (Metal/OpenGL)
  • ✅ intégration Waypipe
  • ✅ mise à l’échelle HiDPI
  • 🚧 backend Windows (win-way)
  • 📱 backend Android NDK (prévu)
  • ⏳ prise en charge multi-écran
  • ⏳ synchronisation du presse-papiers

Contexte de recherche

  • Fait partie du projet de recherche « Turbo-Charged Protocol Virtualization », qui explore une virtualisation Wayland multiplateforme à coût nul en s’appuyant sur la monomorphisation des traits Rust et la conversion de pixels basée sur SIMD

Résolution de problèmes

  • En cas d’erreur SSH « remote port forwarding failed », la cause peut être un fichier socket restant sur l’hôte distant
    • Le script run_waypipe.sh le gère automatiquement avec l’option -o StreamLocalBindUnlink=yes
    • En exécution manuelle : 
      waypipe ssh -o StreamLocalBindUnlink=yes user@host ...

Contribution

  • Il est recommandé d’ouvrir une issue et d’en discuter avant d’ajouter ou de modifier une fonctionnalité
  • Les contributions via Pull Request sont bienvenues

Licence

  • GPL-3.0
  • Copyright © 2024–2025 J-x-Z

À lire aussi

1 commentaires

 
GN⁺ 2026-03-30
Commentaires sur Hacker News

  • Honnêtement, je me pose une question. Quels apps GUI Linux n’ont pas de build native pour macOS ? La plupart reposent sur Qt ou GTK, donc sont multiplateformes, et je ne vois pas vraiment d’app populaire qui me vienne à l’esprit

    • Ce n’est pas vraiment le sujet. L’intérêt ici, c’est d’exécuter les apps d’un hôte Linux distant dans des fenêtres locales. Par exemple, lancer VS Code sur un serveur distant dans une fenêtre sur Mac, ou accéder à l’interface GUI de Matlab sur un cluster de labo. On peut faire quelque chose de similaire avec xpra sous X11
    • Il n’y a pas beaucoup d’apps grand public, mais dans le secteur de la conception de circuits intégrés, il existe beaucoup d’apps réservées à Linux. J’ai essayé de les faire tourner dans des conteneurs sur Mac, mais XQuartz était vraiment médiocre. Avec un passage à Wayland, ça pourrait être bien meilleur. Certaines commencent aussi à avoir des builds ARM, donc une GUI Mac native sera peut-être possible un jour
    • Personnellement, ça m’intéresse pour deux raisons. D’abord, je voudrais utiliser un environnement de développement pour Siri avec une gestion de fenêtres en tuiles, mais je suis coincé dans l’écosystème Apple, donc cette approche pourrait être une bonne alternative. Ensuite, il existe des apps uniquement disponibles sur Linux, comme Iridium Niagara Workbench, et c’est devenu pénible depuis l’arrêt du support de Quartz
    • Moi, je veux juste utiliser KDE Plasma. Franchement, je trouve l’interface de macOS assez mauvaise
    • Ce n’est pas seulement utile pour exécuter des apps Linux, mais aussi pour faire tourner localement les apps graphiques d’un serveur Linux distant

  • Parfait. On peut maintenant faire tourner des apps GUI dans des conteneurs. J’avais essayé quelque chose de similaire avec X11 auparavant, mais ça ne m’avait pas plu. J’ai de plus en plus l’impression que la position d’Apple sur le desktop s’affaiblit. On va finir dans un monde où tout le monde devient « développeur »

    • On dit qu’Apple s’affaiblit sur le marché du desktop, mais en réalité, sa part a toujours été supérieure à celle de Linux. Il ne devrait pas y avoir de grand changement
    • Moi, je voudrais ouvrir des environnements de conteneurs isolés par projet. L’objectif, c’est de regrouper les apps pour la sécurité et la concentration, un peu comme le mode d’intégration des fenêtres de Parallels

  • Ce projet paraît un peu suspect. Le README est rempli d’emojis et n’explique rien de l’implémentation. Il prétend avoir un backend Metal, mais en pratique il semble ne pas exister. La liste des dépendances est aussi étrange

    • Ça ne vaut absolument pas le coup. Ils ne disent même pas quel hyperviseur est utilisé. Impossible de savoir si c’est QEMU ou Docker. Le tableau aussi est bizarre — normalement, une VM est ce qu’il y a de plus simple à configurer, mais ici c’est présenté à l’envers. Le code utilise aussi OpenGL 3.3 Core, donc c’est franchement dépassé. Il est fort probable que ce soit du code généré par un LLM. J’ai l’impression qu’on surestime beaucoup trop le code produit par l’IA en ce moment. C’est tape-à-l’œil en surface, mais creux au fond. Ça me rappelle l’ancien projet promotionnel d’Anthropic, un compilateur C écrit en Rust

  • Il faudrait aussi quelque chose comme ça pour Android. termux-x11 est un point de départ, mais si termux prenait en charge Wayland, ou si la VM Linux d’Android pouvait exposer un socket Wayland, alors il ne manquerait plus qu’un compositeur natif pour un rendu fluide

  • Je trouve dommage que macOS ne puisse pas démarrer en mode shell Darwin sans GUI ; ça aurait pu faire un UNIX vraiment sympa avec un environnement de bureau comme KDE ou COSMIC et le gestionnaire de paquets brew par-dessus

    • Dans ce cas, on peut se demander pourquoi utiliser macOS tout court. Sans l’interface, Darwin n’a pas grand-chose de différent de FreeBSD ou GNU
    • Le noyau des Mac est moins performant, et la gestion des paquets est inférieure à nix
    • À l’époque des Mac Intel, il y avait un mode mono-utilisateur, mais même là on ne pouvait pas contrôler le framebuffer

  • Si c’est possible, je me demande aussi si un client Wayland sur macOS peut créer une surface EGL

  • Est-ce qu’on pourrait exécuter un environnement Android via Waydroid dans Orbstack ? En théorie, ça semble possible

  • Si on pouvait faire en sorte que macOS utilise les raccourcis clavier Windows/Linux, ce serait beaucoup moins frustrant

    • C’est une mauvaise façon de voir les choses. Les raccourcis macOS sont optimisés pour le travail dans le terminal. Les raccourcis système utilisent d’autres touches, donc ils n’entrent pas en conflit avec les codes de contrôle
    • On peut échanger les touches cmd et ctrl dans les réglages, ou tout personnaliser avec Karabiner-Elements. Au début, ça me perturbait aussi, mais on s’y fait en une semaine. Maintenant, ce sont plutôt les raccourcis Windows qui me gênent. L’histoire de la touche Command est aussi intéressante
    • Devoir utiliser ctrl+shift dans le terminal, c’est vraiment atroce. Je trouve que le système de raccourcis de macOS est bien meilleur
    • Personnellement, je trouve qu’utiliser la touche Super pour la plupart des raccourcis est une meilleure idée. Sous Windows, c’est du gâchis de la réserver au menu Démarrer
    • En pratique, j’utilise Karabiner-Elements pour mapper cmd, option et control respectivement vers ctrl, alt et super. On peut déjà faire pas mal de choses avec les réglages par défaut de macOS, mais si on veut différencier les touches gauche et droite, Karabiner est nécessaire. C’est étonnamment assez flexible pour un produit Apple

  • Je me demande si ce projet pourrait susciter ne serait-ce qu’un peu d’intérêt pour GNUstep