wslg
Release 1.0.61
WSLG est court pour le sous-système Windows pour GUI Linux et le but du projet est de permettre la prise en charge de l'exécution des applications GUI Linux (X11 et Wayland) sur Windows dans une expérience de bureau entièrement intégrée.
WSLG offre une expérience intégrée aux développeurs, aux scientifiques ou aux passionnés qui préfèrent ou ont besoin d'exécuter des fenêtres sur leur PC, mais ont également besoin de la possibilité d'exécuter des outils ou des applications qui fonctionnent le mieux, ou exclusivement, dans un environnement Linux. Alors que les utilisateurs peuvent y parvenir aujourd'hui à l'aide d'une configuration de système multiple, avec un PC individuel dédié à Windows et Linux, une machine virtuelle hébergeant Windows ou Linux, ou un XServer fonctionnant sur Windows et projeté en WSL, WSLG fournit un plus intégré, convivial et productif alternative.
WSLG s'efforce de faire en sorte que les applications GUI Linux se sentent natives et naturelles à utiliser sur Windows. De l'intégration dans le menu Démarrer le lancement à l'apparition dans la barre de tâches, une expérience alt-tab à l'activation des applications Cut / Coller à travers Windows et Linux, WSLG permet une expérience de bureau sans faille et un flux de travail en levant Windows et les applications Linux.
WSLG est pris en charge sur Windows 11 et Windows 10. Les utilisateurs de Windows 10 doivent s'assurer que leur installation Windows 10 est entièrement à jour en visitant Windows Update et en installant toutes les mises à jour disponibles.
WSLG est disponible à la fois dans le cadre de la prise en charge de la boîte de réception Windows 11 ainsi que via le sous-système Windows pour Linux à partir de la boutique Microsoft. Il est fortement recommandé d'utiliser la version Microsoft Store de WSL, qui prend en charge à la fois Windows 10 et Windows 11, et contient la version la plus à jour de WSL et WSLG.
Assurez-vous de mettre à jour votre pilote graphique vers le dernier pilote disponible sur le site Web de votre fabricant GPU pour bénéficier de l'accélération GPU dans votre environnement WSL.
À partir d'une invite de commande avec les privilèges de l'administrateur, exécutez la commande wsl --install -d Ubuntu , puis redémarrez si vous y êtes invité.
Après le redémarrage, l'installation se poursuivra. Il vous sera demandé de saisir un nom d'utilisateur et un mot de passe. Ce seront vos informations d'identification Linux, elles peuvent être tout ce que vous voulez et n'ont pas à correspondre à vos informations d'identification Windows.
Voilà! WSL et WSLG sont installés et prêts à être utilisés!
Si vous avez une installation WSL existante sans WSLG et que vous souhaitez mettre à jour vers la dernière version de WSL qui inclut WSLG, exécutez la commande wsl --update à partir d'une invite de commande élevée.
Veuillez noter que WSLG n'est compatible qu'avec WSL 2 et ne fonctionnera pas pour la distribution WSL configurée pour fonctionner en mode WSL 1. Vérifiez que votre distribution Linux est configurée pour l'exécution en mode WSL 2, sinon, passez à WSL 2. Bien que vous puissiez continuer à exécuter Linux Distro en mode WSL 1 après l'installation de WSLG si vous le souhaitez, une distribution configurée pour exécuter en mode WSL 1 Ne pourra pas communiquer avec WSLG et ne pourra pas exécuter les applications GUI.
Vous pouvez répertorier votre distribution actuellement installée et la version de WSL, elles sont configurées pour utiliser la commande suivante à partir d'une invite de commande élevée.
wsl -- list - vSi vous exécutez en mode version 1, passez à la version 2. Cela peut prendre un certain temps.
wsl -- set-version _distro_name_ 2Redémarrez WSL en exécutant cette commande à partir d'une invite de commande surélevée, assurez-vous d'enregistrer tout travail en attente:
wsl -- shutdown Pour mettre à jour la dernière version de WSL et WSLG publié pour l'aperçu, exécutez simplement wsl --update à partir d'une invite de commande élevée ou de PowerShell.
Vous devrez redémarrer WSL pour que les modifications prennent effet. Vous pouvez redémarrer WSL en exécutant wsl --shutdown à partir d'une invite de commande surélevée. Si WSL était actuellement en cours d'exécution, il s'arrête, assurez-vous d'enregistrer d'abord n'importe quel travail en cours! WSL sera automatiquement redémarré la prochaine fois que vous lancerez une application ou un terminal WSL.
Si vous avez installé la distribution Ubuntu Linux selon ces instructions, vous trouverez une icône Ubuntu dans votre menu Démarrer, lancez-le. Cela lancera la VM WSL 2, lancera la distribution Ubuntu WSL dans cette machine virtuelle et vous donnera un terminal pour interagir avec lui. Voilà! Vous utilisez Linux sur Windows!
Si vous souhaitez explorer des distributions Linux supplémentaires conçues pour WSL, vous pouvez utiliser la commande wsl --list --online à partir d'une invite de commande élevée pour énumérer la liste des distributions disponibles pour votre système. Vous pouvez avoir plusieurs distributions Linux installées dans WSL et elles coexisteront avec plaisir côte à côte, alors n'ayez pas peur d'expérimenter et d'essayer les choses.
Félicitations, vous avez terminé et prêt à utiliser les applications GUI!
Si vous souhaitez commencer avec certaines applications GUI, vous pouvez exécuter les commandes suivantes à partir de votre terminal Linux pour télécharger et installer certaines applications populaires. Si vous utilisez une distribution différente de celle d'Ubuntu, il peut utiliser un autre gestionnaire de packages.
# # Update list of available packages
sudo apt update
# # Gedit
sudo apt install gedit - y
# # GIMP
sudo apt install gimp - y
# # Nautilus
sudo apt install nautilus - y
# # VLC
sudo apt install vlc - y
# # X11 apps
sudo apt install x11 - apps - y
# # Google Chrome
cd / tmp
sudo wget https: // dl.google.com / linux / direct / google - chrome - stable_current_amd64.deb
sudo dpkg - i google - chrome - stable_current_amd64.deb
sudo apt install -- fix - broken - y
sudo dpkg - i google - chrome - stable_current_amd64.deb
# # Microsoft Teams
cd / tmp
sudo curl - L - o " ./teams.deb " " https://teams.microsoft.com/downloads/desktopurl?env=production&plat=linux&arch=x64&download=true&linuxArchiveType=deb "
sudo apt install . / teams.deb - y
# # Microsoft Edge Dev Browser
sudo curl https: // packages.microsoft.com / repos / edge / pool / main / m / microsoft - edge - dev / microsoft - edge - dev_118. 0.2060 . 1 - 1_amd64.deb - o / tmp / edge.deb
sudo apt install / tmp / edge.deb - y Une fois ces applications installées, vous les trouverez dans votre menu Démarrer sous le nom de la distribution. Par exemple Ubuntu -> Microsoft Edge . Vous pouvez également les lancer à partir de votre fenêtre de terminal à l'aide des commandes:
xcalc , xclock , xeyesgimpgedit ~/.bashrcnautilusvlcgoogle-chrometeamsmicrosoft-edge
La distribution de l'utilisateur est essentiellement la distribution WSL que vous utilisez pour votre travail Linux. Vous pouvez utiliser la commande wsl --list --online à partir d'une invite de commande Windows élevée pour répertorier les distributions WSL disponibles sur votre système. Vous pouvez exécuter plusieurs distributions d'utilisateurs côte à côte et ils coexisteront paisiblement, alors n'ayez pas peur d'essayer une nouvelle distribution. Chaque distribution de l'utilisateur sera associée à une instance unique de la distribution du système, mais vous pouvez toujours interagir entre les applications d'interface graphique exécutées dans différentes distributions utilisateur de manière transparente, comme la coupe / coller entre eux. La conteneurisation sous-jacente des différents espaces utilisateur doit être invisible pour vous.
Toutes les distributions d'utilisateurs et système pour un utilisateur Windows particulier exécutent dans la même machine virtuelle WSL contre une seule instance du noyau Linux. Différents utilisateurs de Windows sur un PC ont leur propre machine virtuelle et leur instance de WSL. Votre environnement Linux est garanti que toujours le vôtre et non partagé avec les autres utilisateurs de Windows sur le même PC.
La distribution du système est l'endroit où toute la magie se produit. La distribution du système est un environnement Linux conteneurisé où le serveur WSLG XServer, Wayland Server et Pulse Audio fonctionnent. La prise de communication pour chacun de ces serveurs est projetée dans la distribution de l'utilisateur afin que les applications client puissent s'y connecter. Nous préconcentrifions l'affichage des variables de la distribution de la distribution de l'utilisateur, Wayland_Display et Pulse_Server pour référer ces serveurs par défaut, donc WSLG s'allume hors de la boîte.
Les utilisateurs souhaitant utiliser différents serveurs de celui fourni par WSLG peuvent modifier ces variables d'environnement. L'utilisateur peut également choisir de désactiver complètement la distribution du système en ajoutant l'entrée suivante dans son fichier .wslconfig (situé à c:usersMyUser.wslconfig ). Cela désactivera la prise en charge des applications GUI dans WSL.
[wsl2]
guiApplications=false
La distribution du système est basée sur le Microsoft CBL-Mariner Linux. Il s'agit d'un environnement Linux minimal, juste assez pour exécuter les différents morceaux de WSLG. Pour plus de détails sur la façon de créer et de déployer une distribution système privé, veuillez consulter nos instructions de construction.
Chaque distribution d'utilisateurs WSL 2 est associée à sa propre instance de la distribution du système. La distribution du système s'exécute partiellement isolée de la distribution utilisateur à laquelle il est apparié, dans son propre espace de noms NS / PID / UTS mais partage d'autres espaces de noms tels que IPC, pour permettre une optimisation de la mémoire partagée à travers la limite.
Bien qu'un utilisateur puisse obtenir un terminal dans la distribution du système, la distribution du système n'est pas censée être utilisée directement par les utilisateurs. Chaque instance de la distribution du système est chargée de lecture seule à partir de son support VHD. Toutes les modifications, apportées à l'instance en mémoire de la distribution du système (comme l'installation de nouveaux packages ou la création d'un nouveau fichier), sont effectivement rejetées lorsque WSL est redémarré. La raison pour laquelle nous le faisons est d'activer un modèle de service pour la distribution du système où nous remplaçons l'ancien par le nouveau sans avoir à se soucier de migrer les données utilisateur contenues à l'intérieur. Nous utilisons un mappage en lecture seule de sorte que l'utilisateur obtient un comportement de défausse bien connu sur tous les modifications, chaque fois que WSL est redémarré, au lieu d'obtenir une surprise lorsque WSL est entretenu.
Bien que le Microsoft ait publié la distribution du système WSLG en lecture seule, nous voulons encourager les gens à briller avec lui et expérimenter. Bien que nous nous attendions à ce que très peu de gens aient réellement besoin ou voulons le faire, nous avons partagé des instructions détaillées sur notre page de contribution sur la façon de créer et de déployer une version privée de la distribution du système. La plupart des utilisateurs qui souhaitent simplement utiliser des applications GUI dans WSL n'ont pas à se soucier de ces détails.
WSLGD est le premier processus à lancer après init . WSLGD lance Weston (avec Xwayland), PulseAudio et établit la connexion RDP en lançant MSTSC.exe sur l'hôte en mode silencieux. La connexion RDP restera active et prête à afficher une nouvelle application GUI en cours de lancement dans un instant, sans aucun retard d'établissement de connexion. WSLGD surveille alors ces processus et s'ils sortent par erreur (par exemple à la suite d'un crash), il les redémarre automatiquement.
Weston est le compositeur de référence du projet Wayland et le cœur de WSLG. Pour WSLG, nous avons étendu le backend RDP existant de Libweston pour lui apprendre comment les applications distantes plutôt que le moniteur / bureau. Nous y avons également ajouté diverses fonctionnalités, telles que la prise en charge du multi-moniteur, de la coupe / collage, de l'audio dans / out, etc ...
L'intégration de l'application est réalisée via une technologie RDP appelée rail (application distante intégrée localement) et Vail (application virtualisée intégrée localement). La principale différence entre le rail et le VAIL est la façon dont les pixels sont transportés en face du serveur RDP vers le client RDP. En rail, il est supposé que le serveur et le client fonctionnent sur différents systèmes physiques communiquant sur le réseau et donc les pixels doivent être copiés sur le transport RDP. Dans Vail, il est entendu que le serveur et le client sont sur le même système physique et peuvent partager la mémoire à travers la limite de machine virtuelle invitée / hôte. Nous avons ajouté le support pour le rail et le VAIL au backend RDP Libweston, bien que pour WSLG, seul le support Vail est effectivement utilisé. Lors de la construction de WSLG, nous avons d'abord implémenté le rail tandis que les pièces nécessaires permettant à l'interrupteur de Vail étaient en cours de développement en parallèle. Nous avons décidé de maintenir ce soutien car il pourrait réutiliser d'autres scénarios intéressants en dehors de WSLG, par exemple pour l'application éloignée d'un PI exécutant Linux. Pour partager la mémoire entre l'hôte Linux Guest et Windows, nous utilisons Virtio-FS.
Weston est modulaire et dispose de diverses coquilles aujourd'hui, telles que la coque de bureau, la coque en plein écran (aka kiosque) et la coquille automatique. Pour WSLG, nous avons introduit une nouvelle coquille appelée Shell Rail. Le but du shell rail est d'aider à la répartition des fenêtres individuelles de Linux vers les fenêtres, car telle le shell est très simpliste et n'implique aucun widgets réels ou pixels détenus par coque.
Weston exploite FreerDP pour implémenter son serveur RDP backend. FreerDP est utilisé pour coder toutes les communications allant du serveur RDP (à Weston) au client RDP (MSTSC sur Windows) en fonction des spécifications du protocole RDP. Il est également utilisé pour décoder tout le trafic provenant du client RDP dans le serveur RDP.
Pour l'audio dans (Microphone) et Out (haut-parleurs / casque) WSLG exécute un serveur PulseAudio. WSLG utilise un plugin de puits pour son audio et un plugin source pour l'audio. Les flux audio sont fusionnés par le serveur RDP de Weston sur le transport RDP, permettant efficacement l'audio dans / out dans le backend RDP de Weston dans tous les scénarios (Remoting de style bureau / rail / vail), y compris WSLG.
WSLG utilise un canal virtuel RDP personnalisé entre le serveur RDP Weston et le client MSTSC RDP fonctionnant sur l'hôte Windows. Ce canal est utilisé par Weston pour énumérer toutes les applications GUI Linux (c'est-à-dire des applications qui ont une entrée de fichier de bureau de type GUI) ainsi que leur ligne de commande et leur icône de lancement. L'open source WSLDVCPLUGIN traite la liste des applications GUI Linux envoyées sur ce canal et crée des liens pour eux dans le menu de démarrage de Windows.
Bien que WSLG fonctionne avec ou sans support GPU virtuel, si vous avez l'intention d'exécuter des applications graphiques à forte intensité telle que Blender ou Gazebo, il est préférable d'exécuter un système avec un GPU et un pilote qui peut prendre en charge WSL. Un aperçu de notre architecture VGPU et de la façon dont nous permettons aux applications Linux d'accéder au GPU dans WSL est disponible sur notre blog DirectX.
Le soutien au rendu accéléré OpenGL est rendu possible grâce au travail que notre équipe D3D a effectuée avec Collabora et la communauté MESA sur la création d'un pilote Gallium D3D12.
La prise en charge de Linux, y compris la prise en charge de WSLG, a été en amont et fait partie de la version MESA 21.0. Pour profiter de cette accélération, vous devrez mettre à jour la version de MESA installée dans votre distribution d'utilisateurs. Cela nécessite également que votre fournisseur de distribution ait choisi de construire et de publier le nouveau pilote D3D12 Gallium dans son référentiel de colis. Nous travaillons avec les divers éditeurs de distribution WSL pour les informer de ces changements.
Veuillez noter que pour la première version de WSLG, VGPU interoppe avec le compositeur de Weston via la mémoire du système. Si vous exécutez sur un GPU discret, cela signifie effectivement que les données rendues sont copiées de VRAM à la mémoire du système avant d'être présentée au compositeur au sein de WSLG, et téléchargée sur le GPU du côté de Windows. En conséquence, il existe une pénalité de performance proportionnée au taux de présentation. À des fréquences d'images très élevées telles que 600 images par seconde sur un GPU discrète, ces frais généraux peuvent atteindre 50%. À la fréquence d'images inférieure ou sur le GPU intégré, les performances beaucoup plus proches des natives peuvent être réalisées en fonction de la charge de travail. L'utilisation d'un VGPU offre toujours des performances très significatives et une amélioration de l'expérience par rapport à l'utilisation d'un rendu de logiciel malgré cette limitation V1.
WSLG s'appuie sur le grand travail de la communauté Linux et utilise un grand nombre de projets open source. La plupart des composants sont utilisés tels quels sur leur version en amont et n'ont pas besoin de modifications pour s'allumer dans WSLG. Certains composants au cœur de WSLG, en particulier Weston, FreerDP et Pulseaudio, ont nécessité des changements pour permettre la riche intégration WSLG. Ces changements ne sont pas encore en amont. Microsoft travaille avec la communauté pour partager ces contributions avec chaque projet de sorte que, au fil du temps, le WSLG peut être construit directement à partir de composants en amont, sans avoir besoin de modifications spécifiques WSLG.
Toutes ces contributions en vol sont conservées dans les références Microsoft Mirror. Nous gardons ces miroirs à jour avec les versions en amont et mettons en scène nos changements WSLG dans ces repos. WSLG tire et construit du code à partir de ces reposs de miroir dans le cadre de nos versions de prévisualisation WSLG d'initié. Ces miroirs sont publics et accessibles à tous. Les développeurs curieux peuvent jeter un coup d'œil aux premiers stades de notre contribution en regardant le code dans ces miroirs, en gardant à l'esprit que la version finale du code sera probablement différente une fois que la contribution atteindra le projet en amont et est adapté en fonction des commentaires reçus par les différents propriétaires de projet. Tous nos miroirs suivent le même modèle. Il y a une branche principale qui correspond à la branche en amont de notre dernier point de synchronisation. Nous mettons à jour la branche principale de temps à autre pour choisir la mise à jour du projet en amont. Il y a aussi une branche de travail qui contient tous nos changements en vol. WSLG est construit en utilisant la branche de travail de chacun des projets miroir.
Les projets pour lesquels WSLG maintiennent des miroirs changeront au fil du temps à mesure que les contributions en vol évoluent. Une fois certaines contributions en amont, il ne sera peut-être plus nécessaire de maintenir un miroir, à quel point il sera supprimé et WSLG commencera à tirer parti de la version en amont du composant directement. Alors que nous allumons de nouvelles fonctionnalités dans le WSLG, de nouveaux miroirs peuvent être introduits pour les contributions de scène à de nouveaux composants. En tant que tels, attendez-vous à ce que la liste des miroirs change les heures supplémentaires.
À ce stade, nous avons les miroirs du projet suivant pour les contributions actuellement en vol.
| Projet | Repo en amont | Miroir WSLG |
|---|---|---|
| Weston | https://github.com/wayland-project/weston | https://github.com/microsoft/weston-mirror |
| Freerdp | https://github.com/freerdp/freerdp | https://github.com/microsoft/freerdp-mirror |
| Pullaudio | https://github.com/pulseaudio/pulseaudio | https://github.com/microsoft/pulsidio-mirror |
Ce qui suit est un aperçu de haut niveau des contributions actuellement en vol à chaque projet contenu dans ces miroirs.
WSLG exploite Weston en tant que compositeur Wayland Bridging the Linux et Windows Worlds en utilisant la technologie RDP pour le contenu d'application à distance entre eux. Weston avait déjà un backend RDP, mais il était limité à la répartition à un seul monitor-monitor. Nous avons considérablement amélioré ce backend RDP pour inclure des fonctionnalités avancées, telles que la prise en charge multi-moniteurs, l'intégration du presse-papiers pour la copie / la pâte et l'audio dans / out. Nous avons activé de nouveaux modes de télécommande appelés rail (application distante intégrée localement) et Vail (application virtualisée intégrée localement), où les applications individuelles, plutôt que les ordinateurs de bureau / moniteurs, sont éloignées. Ces modifications ne sont pas spécifiques à WSLG; Ils ajoutent des fonctionnalités au backend RDP existant et sont également réutilisables dans d'autres scénarios (c'est-à-dire en utilisant le nouveau backend RDP de Weston vers une application distante fonctionnant sur un Raspberry Pi vers un autre appareil exécutant un client RDP).
Pour permettre une riche intégration dans WSLG, nous avons également ajouté un petit plugin au backend RDP spécifique à WSLG. À Weston, le plugin est responsable de la connexion à la distribution de l'utilisateur et de la recherche d'applications installées (aka le fichier de bureau). Le plugin envoie l'hébergement Windows une liste de toutes les applications trouvées avec leurs commandes et icônes de lancement. Sur l'hôte Windows, une partie du plugin MSTSC open source du projet WSLG utilise ces informations pour créer des raccourcis pour ces applications Linux vers le menu de démarrage Windows.
Nous avons également corrigé plusieurs bogues ayant un impact sur diverses applications. Généralement, ce sont des problèmes qui ont eu un impact sur Weston dans tous les modes et n'étaient pas spécifiques au WSLG.
Weston utilise actuellement FreerDP pour son backend RDP. WSLG continue de tirer parti de FreerDP et nous avons ajouté la prise en charge d'un nouveau protocole / canal RDP pour activer le scénario optimisé Vail ainsi que pour le support du plugin WSLG. Nous avons également corrigé divers bogues qui ont un impact sur les interopsages avec MSTSC ou provoquant une instabilité.
Pour PulseAudio, nos contributions se sont concentrées sur un puits et un plugin source qui mélangent les données audio entre PulseAudio et le backend RDP de Weston de sorte que les données audio peuvent être intégrées sur la connexion RDP à l'hôte. Il n'y a aucun changement dans le cœur de Pulseaudio en dehors de l'ajout de ces nouveaux plugins.
Si vous souhaitez bricoler ou contribuer à WSLG, veuillez consulter notre page contributive pour plus de détails, y compris comment créer et exécuter une version privée de WSLG.
Pour les problèmes non liés à la sécurité, tels que la déclaration d'un bogue ou la suggestion pour une nouvelle fonctionnalité, veuillez utiliser le suivi des problèmes de ce projet.
Pour signaler les problèmes de sécurité avec WSLG ou tout autre produit Microsoft, veuillez suivre les instructions détaillées ici.
Ce projet peut contenir des marques ou des logos pour des projets, des produits ou des services. L'utilisation autorisée de marques ou de logos Microsoft est soumise et doit suivre les directives de marque et de marque de Microsoft. L'utilisation de marques ou de logos de Microsoft dans des versions modifiées de ce projet ne doit pas provoquer de confusion ou impliquer le parrainage de Microsoft. Toute utilisation de marques ou de logos tiers est soumis aux politiques de ces tiers.
