Lors du développement d’Ubuntu 17.10, Canonical avait tenté d’utiliser le nouveau serveur d’affichage par défaut, en remplacement de X.org, qui restait bien sûr comme solution de fallback. Ce fut un échec et la société n’avait plus essayé depuis.
Avec l’arrivée d’Ubuntu 21.04, Canonical veut retenter. Dans une note, la société explique que nombre d’obstacles ont depuis été balayés, notamment avec le partage d’écran.
Ce qui ne signifie pas que la prochaine Ubuntu aura forcément Wayland par défaut. Avec une sortie prévue en avril et une bêta qui devrait arriver deux semaines avant, il reste entre deux et trois mois aux développeurs pour tester la fiabilité d’une session Wayland par défaut.
Rappelons que Fedora a fait de Wayland son serveur d’affichage par défaut depuis la version 25, sortie… en novembre 2016. La distribution a certes essuyé en partie les plâtres, mais elle n’est jamais revenue sur sa décision, chaque nouvelle mouture améliorant significativement ce support.
Commentaires (21)
#1
Ahlalalalalala … Si Ubuntu n’avait pas tant investi dans sa solution perso “Mir” qui n’arrivait pas à convaincre un seul développeur externe….
#1.1
je n’ai jamais bien compris les raison de leur entêtement sur ce point…
#1.2
Mir était un des composants d’Ubuntu Touch (et l’est toujours dans UBPorts il me semble). Donc ça + les habituelles batailles d’ego, et on a le résultat qu’on connait.
#2
Bonne nouvelle! Étant sous Fedora, j’espère que les bugs restants notamment dans les logiciels de screencasting soient pris un peu plus au sérieux grâce à ce mouvement.
#3
Wayland c’est le futur ne serait-ce que pour mise à l’échelle de tout l’écran qui était impossible simplement sous X.
#3.1
??? Je n’ai jamais rencontré ce problème avec xorg et mes drivers nvidia
#3.2
De mémoire :
Le scaling (taille 2, 3 etc.) est officiellement supporté mais ne concerne pas les fenêtres dessinées par gtk/qt etc. C’est donc la croix et la bannière d’avoir un ensemble cohérent et pas trop moche.
Le fractional scaling (taille *1,25 etc.), de + en + utilisé avec les nouveaux écrans qui ont une densité de pixel importante, n’est tout simplement pas supporté à ma connaissance.
Sous Wayland, le fractional scaling est encore expérimental mais fonctionne assez bien sur mes machines et c’est un vrai bonheur à utiliser.
#3.3
Bah je l’ai toujours eu dans les options de xorg ou via le panneaux de config. de nvidia :
https://forums.developer.nvidia.com/t/how-to-enable-gpu-scaling-on-linux/47661/6
#4
Pop Corn?…
#5
Pour le HiDPI malheureusmeent dans certains cas il faut adapter https://wiki.archlinux.org/index.php/HiDPI
#6
Sous wayland exclusivement depuis le passage en openSUSE leap 15.2 en juin 2020, sous gnome, tout fonctionne quand meme beaucoup mieux en terme de réactivité de l’interface.
Il reste 1 soucis , la gestion des autorisations de partages d’écrans/applications pour les applis de visios, teamviewer like etc… je ne sais pas si cette carence est du à gnome/mutter qui n’a pas implémenter la gestion ou si c’est propre à Wayland.
#7
Je travaille en dual screen avec des écrans qui ont des résolutions différentes, et je les mets à la même échelle avec un xrandr –scale 1.25. Je ne vois pas en quoi c’est “impossible” puisque je le fais quotidiennement.
#7.1
Voir message #7
#8
Et un équivalent du X11 forwarding, ils ont enfin pensé à mettre un peu de réseau dans leur wayland ou pas?
Sur cet aspect important, wayland ne fait pas le job et ses développeurs ne voulaient visiblement pas en entendre parler. La lenteur d’adoption suit, forcément…
#8.1
Pareil pour moi, basculer sur Wayland serait une énorme régression sans support réseau. Les développeurs Wayland parlent de VNC, mais ce que je veux, c’est une vraie intégration comme on l’obtient avec ssh -X, pas un truc bridé à la Windows. J’ai l’impression qu’ils ne se rendent pas compte que dans le monde Linux, il y a beaucoup de serveurs, et donc de connexions distantes.
En attendant, pas de Wayland pour moi.
#8.2
Est-ce qu’il y a encore beaucoup de cas d’usages demandant l’affichage déporté via ssh -X ? Quels sont-ils ?
Personnellement je n’ai pas vu ça depuis une dizaine d’années, les seuls cas d’usages que j’avais à ce niveau c’était pour faire démarrer la console TSM depuis un serveur par exemple pour restaurer des données.
Avec le fait que maintenant les logiciels ont de plus en plus des GUI Web (et le reste en CLI), j’aurais tendance à comprendre pourquoi les développeurs de Wayland ne brûlent pas de gaz dessus. A moins qu’il y ait des cas d’usages impossibles à adapter via conduite du changement qui m’échappent.
#9
Tu n’as donc pas compris mon message. Le scaling est supporté directement dans X11, donc les amis gtk et qt n’ont rien à voir avec ça. Comme c’est dans X11, c’est cohérent sur tout le bureau, peu importe le toolkit.
Et le fractionnal scaling est disponible. Comme je te le disais, je tape ce message sur un écran avec un scaling de 1.25 via X11, ce qui est à mes yeux une preuve suffisante que ça marche.
#10
Je développe en permanence avec mon emacs lancé à distance sur un serveur qui est en salle machine. Sur plusieurs différents, même.
#10.1
J’ai la même pratique, pour ça j’utilise un montage sshfs et je travaille avec mes outils locaux.
#10.2
Moi aussi je me débrouille avec sshfs pour les cas où il n’y a pas de X11, mais du coup, il manque des outils, et 20 minutes le git clone… pfiou.
#11
A titre professionnel, je trouve assez peu efficace de se passer de cela quand tu travailles sur une machine servant au développement d’un côté, d’autres en lab auxquelles sont connectées tes outils/sondes et tes cartes objet des développement… elles même sous Linux.
Ca fait juste le bureau du laptop et ceux de chaque machine à se trainer au lieu d’avoir juste ses fenêtres utiles dans un bureau unique.
Si le changement, c’est devoir se traîner ce foutoir, pas étonnant que les utilisateurs trainent les pieds… depuis plus de 10 ans. X11 construit autour du réseau, c’est vraiment un élément majeur.
A titre personnel, des machines headless n’ont aucun avantage à avoir un bureau complet et ses dépendances installées: Le raspberry PI qui gère la barraque a donc une install minimale, mais comme c’est bien utile de pouvoir lancer plusieurs terminaux ou un éditeur graphique léger (sans dépendance à tout Gnome ou KDE, genre nedit) quand on a une bricole à faire, il est installé avec un support X11 frame-buffer lui aussi très minimal via le paquet “xvfb” (et un choix d’outils graphiques simples mais suffisants, sans dépendances majeures).
Ainsi, le GPU n’est pas utlisé, minimisant la conso et la chauffe pour un truc up 24⁄7, ainsi que les besoins en batterie tampon pour assurer des heures d’autonomie sur perte d’alim (vu qu’il gère aussi l’alarme maison).
X11 combiné à SSH, c’est quand même un duo très très utilisé que Wayland a totalement négligé tout en prenant de haut ceux qui pointaient ce manque. Sur le fond et la forme, ça cloche.