Cher journal,
Une question me turlupine! Nous avons tous gueulé sur Canonical et son délire Mir et ses mais en attendant, ce dernier fait des progrès assez étonnant comme le montre la petite nvideo
Wayland se veut plus généraliste certes et je ne doute pas de son "design", mais à part des démos de GLXgears, une confirmation du support des EFL que personnes n'utilisent encore (troll in) ou du support RaspBerry Pi super utile sur le desktop (troll²), on a (…)
L’activité du projet Wayland, projet visant à remplacer le vieillissant X.Org, a été très importante ces derniers mois. En voici les principaux faits marquants.
Merci à bayo, Nÿco et antistress pour leur contribution.
En marge de son gestionnaire de fenêtres sorti en décembre dernier, le projet Enlightenment s’est attelé à ajouter un élément à son édifice : un émulateur de terminal. Son développement a commencé il y a un peu moins d’un an, initié par Carsten Haitzler. Terminology est donc une écriture from scratch d’un terminal bénéficiant de fonctionnalités visuellement très impressionnantes.
Wayland est un protocole pour serveur graphique qui se veut, à long terme, le remplaçant de X. Il est récemment sorti en version 1.0 et continue son développement. Le développement de Wayland est accompagné du développement du compositeur de référence (implémentant le protocole), Weston.
Une des grandes critiques de Wayland était que le compositeur par défaut nécessitait des pilotes graphiques prenant en charge les opérations 3D, ce qui limitait le nombre de cartes graphiques pouvant être utilisées. C'est une critique en train de devenir obsolète, un patch récent permet d'utiliser Weston dans un serveur X, sans ces pilotes 3D, mais en utilisant une bibliothèque ne nécessitant qu'un CPU. Et ce code va être adapté pour qu'il soit utilisable en natif, sans serveur X.
Le développeur principal de Compiz a annoncé qu'il ne migrera pas son compositeur vers Wayland, non pas parce qu'il trouve que c'est un mauvais projet mais parce qu'il pense qu'il vaut mieux implémenter les fonctionnalités de Compiz dans Weston plutôt que de fragmenter encore plus le monde des compositeurs Wayland et d'augmenter la complexité de Compiz en le rendant compatible avec Wayland. Il continuera toutefois à maintenir Compiz pour X.
Petit à petit, de plus en plus d'applications sont nativement compatibles avec Wayland, voici par exemple un backend Wayland pour mplayer2. Attention si vous voulez l'essayer, il requiert une version assez récente de FFMPEG, n'oubliez de lire les instructions.
La version de Wayland pour Android n'est pas oubliée avec le développement de wayland-java : une interface entre la bibliothèque d'arrière-plan libwayland et le langage Java. Il est donc maintenant possible de développer des applications Java pour Wayland. Ce développement est encore récent et jugé expérimental.
NdA : merci à Nÿco, reno, Jarvis et fravashyo pour leurs contributions à cette dépêche.
Eh oui les amis, ça y est, le jour tant attendu est arrivé : Wayland 1.0 est enfin là !
À ce jour, sur tous les ordinateurs de bureau et portables sous GNU/Linux, *BSD ou Solaris de la planète, l’interface graphique — que ce soit KDE, GNOME ou autre — est gérée par X Window System ou X11, dont X.Org est une implémentation (dérivée de XFree86).
Fait tout aussi notable : dans le monde mobile (Android) ou de l’embarqué où GNU/Linux est largement diffusé, X.Org est la plupart du temps absent.
X a été conçu au MIT en 1984 — il y a presque 30 ans ! —, sa version 11 datant, elle, de 1987, ce qui est très vieux pour du code gérant du matériel ayant subi de nombreuses (r)évolutions, avec pour corollaire que X.Org est devenu très difficile à maintenir.
De plus, avec l’avènement des compositeurs (permettant des effets de transparence, d’ombre portée, etc.), le fonctionnement de X.Org pour la gestion graphique ne semble plus optimal, car il constitue une étape supplémentaire entre l’application et le compositeur ainsi qu’entre le compositeur et le matériel.
Plusieurs tentatives pour remplacer X ont eu lieu : Y Window System, Fresco/Berlin… Aucune n’a rencontré le succès escompté.
En 2008, le Danois Kristian Høgsberg a décidé de créer un nouveau serveur d’affichage, à la fois plus moderne et plus simple à maintenir : le projet Wayland était né.
C’est donc finalement le W de Wayland qui succèdera à X !
Pour se donner une petite idée de leurs différences, l’interface de programmation (API) de Wayland est environ 15 fois plus petite que celle de X…
Du côté utilisateur, on nous promet quelques bénéfices immédiats : une plus grande fluidité, un affichage sans cisaillements (tear‐free) quand la décoration est gérée par le client…
Notons enfin que Wayland n’est pas développé contre X.Org, mais avec le plein appui des développeurs de ce dernier qui voient bien l’intérêt de simplifier la maintenance. D’ailleurs, la Fondation X.Org vient de réviser ses statuts en incluant Wayland dans les logiciels qu’elle soutient.
Participants à la rédaction de cette dépêche : reno, antistress, Xavier Claude, Davy Defaud, Patrick_g, Benoît.
Salut nal,
je ne sais pas si cela aurait mieux valu un post dans le forum ou pas de post du tout, mais bon voilà: j'ai écris plusieurs message sur W2 (Wayland&Weston) où j'indiquais que l'architecture (décoration gérée par le client) ne me semblait pas fameuse car déplacer/redimensionner des fenêtres pouvait être saccadé si l'application est lente à répondre, or c'est faux pour le déplacement des fenêtres avec Weston!
En fait, les décorations sont bien gérées par le client, mais (…)
Dans la lignée de mon journal sur le sandboxing dans Chrome et surtout le troll sur le modèle de sécurité de l'Apple Store, je pense que les lecteurs et lectrices de LinuxFR qui aiment les questions de conception sécurisée des applications seront intéressé-e-s par cet article de Linux Weekly News:
XDC2012: Graphics Stack Security
Martin Peres and Timothée Ravier's session on day one of XDC2012 looked at security in the graphics stack. They considered user expectations around security in (…)
Cher journal,
Je sais que tu ne dors plus depuis qu'on a annoncé que Wayland était un successeur probable à Xorg et qu'il ne proposait pas de transparence réseau. Rassure-toi, je viens de lire sur The H online que, lors de la récente conférence du serveur X, Kristian Høgsberg (pratique le copier-coller) a présenté les débuts de la transparence réseau avec le compositeur de référence de Wayland, Weston.
Et pour ceux qui font en tty et qui ne sont donc (…)
Est-ce que l'évolution de GNU/Linux doit se faire au détriment de BSD ? Voyons un peu :
Bonsoir,
Kristian Høgsberg a annoncé hier la sortie de la version 0.95 de Wayland, le probable remplaçant de X.Org. C'est une version de développement. La version stable devrait sortir pour noël 2012.
Cette version n'est pas encore figée mais il n'y a plus d'ajout de fonctionnalités pour la version 1.0 :
Voici une dépêche pour expliquer le fonctionnement de Wayland et pourquoi les développeurs pensent que le X Window System, l'environnement graphique historique du monde Linux, n'est plus adapté à l'utilisation actuelle. Elle est basée, entre autres, sur la présentation de Kristian Høgsberg, le créateur de Wayland, au Fosdem dont la vidéo est disponible.
NdA : merci à Nÿco, reno, baud123, Yves Bourguignon, Jarvis, Hell Pé, Stéphane Aulery et Benoît pour leur aide lors de la rédaction de cette dépêche.
Sur le blog de Martin Gräßlin (qui contient un lien vers sa présentation de KDE sur Wayland au Desktop Summit), on apprend que KDE conservera l'actuel système de "server side décoration"(*), même sur Wayland, au lieu d'utiliser le (probable) comportement de Wayland par défaut(**) où les applications dessinent elles-mêmes le bord de leur fenêtre.
Donc à priori, on devrait éviter les applications figées ainsi que le "Cette application ne répond plus, voulez-vous la fermer?" sur KDE/Wayland(***), ouf!
*: le (…)
Ces derniers temps ont été très riches en événements dans le monde graphique libre.
Une première phase du remodelage intégral de la pile graphique de nos systèmes libres avait commencé par DRI2, apportant notamment la possibilité à un compositeur tel que Compiz de rediriger le rendu OpenGL d’une fenêtre (Redirected Direct Rendering), puis le Kernel Mode Setting (KMS) permettant de transférer la gestion des modes vidéo et de la mémoire vidéo du pilote graphique X.Org (DDX) vers le noyau, et enfin, Gallium3D, le cadriciel de Tungsten Graphics, permettant la mise en commun de nombreuses fonctionnalités auparavant implémentées dans chaque pilote graphique.
Très récemment, le noyau 2.6.38 a apporté le kernel page flipping, permettant l’arrivée du futur serveur d’affichage Wayland développé par Kristian Høgsberg (également auteur de DRI2 et de AIGLX) et popularisé par Mark Shuttleworth (qui souhaite son adoption dans Ubuntu dès l’année prochaine). Les bibliothèques graphiques GTK+ 3 et Qt 4 ont déjà des back-ends permettant le fonctionnement expérimental des applications GNOME 3 ou KDE 4 sous Wayland…
Parmi les plus récents événements, de nombreux étudiants ont proposé des projets en lien avec la pile graphique libre utilisée par GNU/Linux à l’occasion de l’édition 2011 du Google Summer of Code (GSoC). Ces projets sont plus précisément des « state trackers » pour Gallium3D :
un étudiant belge du nom de Denis Steckelmacher (alias steckdenis), a proposé rien de moins qu’un state tracker OpenGL 4.1, entièrement récrit. Ce projet ayant été jugé bien trop ambitieux par les développeurs Mesa / Gallium3D dans le cadre du GSoC, ces derniers lui ont proposé de travailler sur le remplacement des représentations intermédiaires propres à Gallium3D (Mesa IR) par une sémantique [GLSL] plus standard. Après coup, cette idée n’a pas fait non plus l’unanimité au sein des développeurs, avec notamment deux sociétés, Intel et LunarG travaillant actuellement sur ces fameuses représentations intermédiaires. Denis Steckelmacher a finalement décidé de travailler sur Clover, le state tracker OpenCL, permettant d’exploiter la puissance des GPU pour le calcul intensif, avec pour objectif obtenir un state tracker fonctionnel réalisant, dans un premier temps, les calculs OpenCL sur le processeur en utilisant LLVMpipe, un moteur de « rendu OpenGL » logiciel basé sur LLVM (Low Level Virtual Machine).
un étudiant français, Émeric Grange (alias Emeric_), participerait également au GSoC 2011, avec pour projet le développement d’un décodeur vidéo WebM / VP8 accéléré via les [[shaders]] des processeurs graphiques. Tout cela serait placé dans un state tracker Gallium3D, qui exposerait ses fonctions aux lecteurs multimédias comme VLC, MPlayer et Totem (via un greffon GStreamer) à travers l’API VDPAU de NVIDIA.
Ce state tracker pourrait constituer un bon point de départ pour la prise en charge générique du décodage matériel d’autres formats vidéo, tels que le MPEG 4 ASP (DIVX < 7) et MPEG 4 AVC (H.264) ou le MPEG 2 (déjà pris en charge par le state tracker XvMC). À noter que, comme pour la gestion des textures compressées S3TC, la gestion de ces formats devra faire l’objet d’une analyse des brevets / licences impliqués.
Certes, tout n’est pas rose du côté de la pile graphique Linux, mais au moins ça bouge et ça avance plutôt dans le bon sens. Voir ci-dessous pour les détails.