Wayland et son implémentation de référence Weston sont sortis le 20 mai en version 1.5. Au programme, pas de révolution mais beaucoup de bugs corrigés.
Au menu pour cette version :
Wayland
- Rien de particulier pour l'utilisateur lambda.
Weston
Intégration de
xdg-shell. Tout n'est pas terminé mais c'est en bonne voie et ce sera normalement finalisé pour la 1.6 et donc présent dans GNOME 3.14.La pile input de Weston a été refactorisée dans une nouvelle librairie
libinput.Nouveau serveur Xwayland. Ce nouveau serveur est plus simple et fonctionne à la manière de Xwin et Xquartz. De plus, Xwayland est dorénavant inclus dans la version officielle de Xorg.
Animation pour la fermeture des fenêtres.
Un mode plein écran pour une utilisation en kiosque.
Weston supporte différentes profondeurs de couleurs sur les différentes sorties vidéos.
Voilà pour cette version… Pour les détails je vous laisse consulter l'annonce officielle : http://lists.freedesktop.org/archives/wayland-devel/2014-May/014955.html.
# Titre
Posté par claudex . Évalué à 5.
Vu que Gnome n'utilise pas Weston, je ne comprend pas cette phrase.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Titre
Posté par reno . Évalué à 2.
C'est le protocole qu'ils mettent au point: ils essayent de faire une interface 'standardisée' pour qu'il y ai interopérabilité entre les applications et les desktop.
Qu'une appli Qt puissent fonctionner dans un desktop GNOME par exemple.
[^] # Re: Titre
Posté par claudex . Évalué à 7.
Si c'est le protocole, pourquoi c'est dans la section Weston ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Titre
Posté par Elfir3 . Évalué à 6.
Je suppose que c'est parce que Weston est l'implémentation de référence, et donc une fois dedans on peut facilement se baser dessus pour les autres implémentations sans crainte de faire son IE6.
[^] # Re: Titre
Posté par reno . Évalué à 1.
Parce que Wayland est seulement le protocole universel de "bas niveau" pour échanger des buffers.
Universel dans le sens ou il ne dépend pas d'un cas d'utilisation particulier.
Au dessus il y a plusieurs protocoles qui dépendent de la situation:
-pour un desktop xdg-shell dans Weston (et les autres compositeurs de bureau)
- je crois que l'industrie auto a un protocole au dessus de Wayland pour la centrale embarquée
etc.
[^] # Re: Titre
Posté par plietar . Évalué à 5.
Les protocoles sont développés dans weston, et une fois stables ils passent dans wayland.
C'est ce qui c'est passé pour le protocole subsurface. Ajouté ici dans wayland, retiré là dans weston.
Après certains protocoles sont vraiment spécifiques à weston et n'ont pas vocation à migrer vers wayland, mais je ne crois pas que ce soit le cas de xdg-shell. Il y a même déjà un protocole rudimentaire wl_shell que xdg-shell viendra remplacer.
[^] # Re: Titre
Posté par gnx . Évalué à 7.
Je crois que les poules auront des dents (et que ce sera l'année du desktop Linux) lorsque je comprendrai enfin qui sert à quoi dans Wayland et compagnie.
[^] # Re: Titre
Posté par Patrick Nicolas . Évalué à 8.
Wayland est le protocole ainsi qu'une bibliothèque qui l'implémente.
Il permet à une application de gérer son affichage, recevoir ses évènements clavier et souris, gérer le copier-coller et probablement d'autres choses auxquelles je ne pense pas tout de suite.
Weston est un compositeur de référence, il permet d'avoir une démonstration du fonctionnement. C'est le compositeur qui expose l'interface wayland, il utilise donc la bibliothèque wayland pour être serveur.
Pour avoir un environnement de bureau complet il faut des interfaces supplémentaires : les commandes pour gérer les fenêtres, de demandes de capture d'écran, un moyen pour faire un clavier virtuel, de l'affichage distant etc. Ces fonctionnalités ne sont pas dans wayland directement (ou pas encore), elles peuvent être implémentées dans weston pour une démonstration ou simplement comme référence.
[^] # Re: Titre
Posté par reno . Évalué à 2.
Pas dans ce cas là cf le post de (reynum)[http://linuxfr.org/nodes/102256/comments/1538894].
[^] # Re: Titre
Posté par reynum (site web personnel) . Évalué à 6.
Alors ça je trouve que c'est une bonne initiative. Je lui souhaite bonne chance.
https://wiki.tizen.org/wiki/Wayland_xdg-shell_protocol
xdg-shell, on the contrary, is supposed to be provided by the compositor. So you will find the "xdg-shell-client-protocol.h" header in the Weston source tree.
kentoc'h mervel eget bezan saotred
# NX
Posté par Sytoka Modon (site web personnel) . Évalué à 8.
Je sais que Wayland ne s'occupe pas de la tansparence réseau mais j'ai fais quelques essais sur des liaisons TRES bas débit et pas fiable.
Bref, j'ai été très décu par spice qu'on nous annonce depuis des années, j'ai trouvé qu'xpra fait beaucoup mieux. J'ai pas du faire les bons réglages… Le plus sympa me semble xpra mais x2go est largement devant tout le monde en terme de réactivité.
Si on ne veut pas que des weberies, c'est important la transparence réseau, et qui marche !
S'il y a d'autres retours, je suis preneur.
[^] # Re: NX
Posté par ZeroHeure (site web personnel) . Évalué à 2.
Tu n'as pas testé RDP ?
Tu testais avec du son ou de la vidéo ?
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: NX
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Pas fait RDP cette fois là donc c'est pour cela que je n'en ai pas parlé.
Pas fais de la vidéo ni du son (déjà avec une application locale dédiée, comme skype ou une autre, cela marche mal sur cette liaison), je veux par exemple utiliser firefox à distance ou un simple éditeur (nedit est mon préféré pour les tests) ou une saloperie de logiciel privateur pour des baies ou… Donc une IHM classique assez statique.
D'ailleurs, je ne sais pas si Firefox a un greffon pour inter-connecter deux firefox distant ? Je veux que les requêtes soit réalisées sur la machine distante.
[^] # Re: NX
Posté par ZeroHeure (site web personnel) . Évalué à 3.
J'oubliais, avec quel toolkit et quel thème as-tu testé ? ça peut faire de grosses différences. Dans un installation LTSP par exemple il vaut mieux ne pas utiliser KDE avec Oxygen.
Il y a quelques années j'avais aussi mené des tests, mais sans Spice, pour aboutir aux mêmes conclusions. Peu après j'ai du pratiquer RDP et ça m'a semblé mieux que NX.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: NX
Posté par Frédéric COIFFIER . Évalué à 3.
Je confirme que le toolkit Oxygen est également inutilisable avec NX (j'utilise QtCurve qui marche très bien et qui a l'avantage d'avoir son équivalent pour Gtk).
Avec NX, je suis également obligé de lancer KDE (ou toute application Qt) avec : QT_GRAPHICSSYSTEM=native
Cela force les applis Qt à passer par X11 pour le rendu (au lieu de faire le rendu en interne et de filer les buffers à Xorg/NX ce qui fait saturer la liaison réseau).
C'est également pour cette raison que je suis sceptique sur le fait d'avoir NX + Wayland (car si j'ai bien compris, dans Wayland, chaque application s'occupe du rendu de sa fenêtre et tout se fait en affichant des buffers graphiques).
[^] # Re: NX
Posté par reno . Évalué à 2.
Ça dépend de ce que tu appelles NX + Wayland..
Si c'est "les applis continue a appeler X et utiliser NX + XWayland pour l'accès distant à un bureau Wayland", je ne vois pas ou est le problème (enfin si je le vois, le proche futur où les devs GTK et Qt qui disent X11 c'est obsolète, on ne supporte plus).
Si tu veux dire avoir l'équivalent de NX directement sur Wayland, en théorie non ça ne devrait pas bien marcher en WAN et faible BP, en pratique il faut voir ça peut dépendre des applis, des thèmes, de la méthode de compression utilisée..
[^] # Re: NX
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Pour NX, je teste presque toujours avec XFCE car j'avais remarqué qu'il charge bien moins que les autres (GNOME, KDE) et que pour mes utilisateurs lambda, il est pas trop geek ;-)
Sinon, je fais souvent mes premiers tests avec nedit (motif) car il s'ouvre normalement instantanément, pas toutes ces merdes de dbus, gconf et autres pour éditer un fichier. Je trouve que c'est un bon cas test même si en pratique, il est de moins en moins utilisable en pratique car ne gérant pas l'UTF8.
Avec XPra et Spice, j'avais lancé directement les applications nedit et firefox.
J'ai fais cela il y a un mois environ… Je ne me souviens plus précisément du paramétrage exact. Je vais essayer de refaire des essais plus "scientifique".
La liaison a un débit très variable mais rarement élevé. Par exemple, j'ai mis 30min la semaine dernière lors d'un apt-get install icetea ! Ca coupe aussi régulièrement 5, 10 30s… MOSH résiste très bien à ces coupures mais pas ssh. Du coup, x2go plante régulièrement alors que par exemple, xpra m'a semblé plus résistant (mais plus de latence).
Bref, c'est vrai qu'il commence à y avoir plein de solution intéressante et qu'il faudra un jour une phase d'intégration / simplification.
[^] # Re: NX
Posté par claudex . Évalué à 8.
Quand on vous dit que Java c'est lent.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: NX
Posté par Wawet76 (site web personnel) . Évalué à 3.
Avec un proxy peut-être ?
[^] # Re: NX
Posté par NilugeKiWi . Évalué à 2.
Tunnel ssh + l'extension foxy proxy firefox en proxy socks sur les tunnels.
Et si la configuration et le maintien des tunnels ssh à la main est fastidieux, il y a gnome SSH Tunnel Manager (gstm): http://sourceforge.net/projects/gstm/
Testé et approuvé.
[^] # Re: NX
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
J'ai essayé le proxy sock ssh, le tunnel ssh vers un proxy squid interne… Rien n'a marché. Il s'agit d'aller sur des sites internes de l'université ayant une authentification shiboleth et il se perds dans un truc récursif. Je pense qu'il y a un soucis au niveau de la config du site web mais je n'ai pas la main sur les sites de la fac, et heureusement ;-) Ou alors, c'est la moulinette shiboleth qui foire… dans ce cas.
[^] # Re: NX
Posté par claudex . Évalué à 6.
Pour infos, qu'est-ce que tu appelle "très bas débit" ? Et pour les différents logiciels comparés, qu'elles étaient les paramètres (qualité, résolution…) ?
https://code.google.com/p/jsvnc/ :)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: NX
Posté par reno . Évalué à 3.
Je suis d'accord, mais la difficulté c'est que quand tu fais la combinatoire:
(LAN ou WAN) * (client léger ou client lourd) * (machine distante normale ou machine distante type serveur sans carte graphique/carte graphique minimale), ça fait beaucoup de cas différent et les piles graphiques qui se comportent bien dans chacun des cas sont totalement différentes.
La "solution" d'accès distant sur Wayland (envoyer les delta entre les images obtenues) devrait très bien fonctionner en LAN entre 2 machines puissantes peut-être même mieux que X, après dans les autres cas effectivement ça sera probablement pas terrible mais bon il reste X (XWayland) pour ces cas là..
[^] # Re: NX
Posté par reno . Évalué à 4.
J'oubliais: Weston a une backend RDP donc il y a déjà la "transparence réseau" dans le monde Wayland en dehors de X, enfin si et seulement si tu utilise Weston bien sûr!
Avec les compositeur Wayland de Gnome ou de KDE là..
# TRADUCTION
Posté par pseudovalide . Évalué à 1.
Pour les détails je vous laisse consulter l'annonce officielle
oui, j'aime encore mieux. Même si je ne suis pas très à l'aise avec l'anglais,
je préfère la version originale plutôt qu'un :
*la pile input a été REFACTORISÉE.
*
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.