X.Org est mort, vive Wayland ! (3)

Posté par  (site web personnel) . Édité par Davy Defaud, Jiehong, Nÿco, palm123, Jarvis, Benoît Sibaud, Ontologia, Pierre Jarillon, bayo, Benoît, marsup, NeoX, PierreLM et claudex. Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
77
18
juil.
2013
Serveurs d’affichage

Le système graphique Wayland vient de passer une nouvelle étape. En effet, le rythme de développement de Wayland et Weston s’est accéléré depuis le passage à un cycle de publication trimestriel.

Cette version est importante, car elle met en place une gestion de version dans l’API qui permettra de passer en douceur les futures évolutions. Par ailleurs, les manœuvres sont en cours au niveau des bibliothèques graphiques (toolkits), environnements de bureau et distributions.

Pour rappel, Wayland est un protocole alternatif à X, repensé pour les usages modernes, et Weston le compositeur référence utilisant Wayland.

Wayland

Il reste néanmoins encore du chemin pour une bonne maturité du produit, alors que la concurrence devient forte surtout dans le domaine de l’embarqué avec Ubuntu Touch et Mir qui pointent à l’horizon, et, bien sûr, SurfaceFlinger utilisé dans Android.

NdM : merci à mpurple pour avoir également proposé une dépêche sur le sujet. Ces deux dépêches ont été fusionnées.

Sommaire

Avancement

Versionnage de l’API

Lorsque la 1.0 est sortie, il n’y avait pas d’API stable pour libwayland-server.so. Cela signifie que pour chaque version majeure de Wayland, les compositeurs pouvaient être cassés en ne parlant pas le même langage. Juste au niveau de Weston, ce n’était pas bien grave, mais les compositeurs externes pour Wayland apparaissant, cette instabilité de l’interface devait changer, avec une gestion de version de l’API. Une grande partie de ce travail a été réalisée par Jason Ekstrand.

Gestion des couleurs

Richard Hughes a travaillé sur la gestion des couleurs dans Wayland et a implémenté deux thèmes dans Weston : un simple greffon qui lit des profils CMS, et un greffon plus avancé qui intègre colord (un service permettant de gérer des profils de couleurs). Ceci n’est valable qu’avec le compositeur DRM.
On peut voir une capture d’écran montrant l’intégration au Centre de contrôle de GNOME.

Postes de travail multiples et gestion des entrées

La gestion des entrées est maintenant complète. Celle‐ci permet d’avoir plusieurs périphériques (claviers, souris ou écrans) sur une même unité centrale, avec un utilisateur devant chaque écran. La gestion des systèmes d’entrée est différenciée et permet de créer de nouvelles entrées à chaud.
Comme le montre la vidéo, cela nous permet de configurer de multiples sièges à Weston, à l’instar du multi‐pointeur de X, où chaque personne dispose de son propre pointeur et sa propre cible de saisie clavier (focus). Il permet aussi de fixer un système d’entrée à une sortie vidéo.

Subsurface API par Pekka Paalanen

Cette extension nous permet de construire des fenêtres d’application à partir de multiples surfaces Wayland, combinant potentiellement différents espaces colorimétriques ou types de tampons. Les lecteurs vidéo combinant interface graphique, vidéo et fenêtres utilisent typiquement ce genre de fonctionnalités.

Redimensionnement de la sortie

Le redimensionnement de la sortie est désormais possible, notamment pour les affichages à haute densité (Hi-DPI). Une explication complète est donnée par Alex Larsson sur son blogue.
Cela implique la prise en charge de fenêtres redimensionnées à divers facteurs d’échelle sur les différentes sorties, ainsi que le redimensionnement global.

backend et moteur de rendu pour le Rasperry Pi

par Collabora. Si cette impressionnante vidéo de comparaison Xorg/Wayland sur le Rasperry vous a donné envie d’en savoir plus, voilà quelques articles qui valent d’être lus :

Multi‐tâche

La version précédente était plus qu’instable. En effet, il était impossible de dessiner un tampon dans un fil d’exécution et demander à un autre de gérer les événements. Il fallait passer par un autre mécanisme pour synchroniser les deux fils d’exécution. Une des limites de la bibliothèque du côté client est que Wayland supposait, de manière « optimiste », que les bibliothèques graphiques (toolkits) ou les applications fourniraient un « fil d’exécution principal ». Désormais, une tâche principale transmet les événements aux autres qui peuvent gérer l’affichage ou les événements d’entrée.

Un nouveau client d’exemple

Pour illustrer une application qui compose des tampons avant d’obtenir un rendu final, un nouveau client d’exemple a fait son apparition.

Désactivation de libxkbcommon

L’utilisation de libxkbcommon n’est plus obligatoire lorsqu’un clavier complet n’est pas utile, ce qui est surtout valable pour les systèmes embarqués (le tableau de bord d’une voiture, par exemple).

Applications et environnements de bureau

Bibliothèques et logiciels

Plusieurs bibliothèques graphiques et environnements sont maintenant compatibles avec Wayland :

  • Clutter ;
  • EFL ;
  • Qt 5 ;
  • GTK+ 3.8 ;
  • SDL.

Une application se basant sur une de ces cinq technologies et ne faisant pas d’appels directs à Xlib devrait, en théorie, être compatible nativement avec Wayland. Dans la pratique, la prise en charge des applications est encore incomplète, mais en progression, comme on peut le voir sur une liste d’applications GNOME en test. Les problèmes viennent parfois des dépendances, comme WebKitGTK+, qui vient d’être corrigé.

Les applications qui n’auront pas migré seront néanmoins pleinement utilisables dans un environnement Wayland, grâce à la couche de compatibilité XWayland (et parfois seront même plus performantes qu’avec un serveur X).

Environnements de bureau

Comme l’évoque Martin Gräßlin (développeur de Kwin), si se baser sur une des bibliothèques prenant en charge Wayland comme Qt 5 résout 99 % des soucis, les environnements de bureau sont clairement impactés par le pourcent restant, car les gestionnaires de fenêtres (au sens large) et autres gadgets de bureau ont été pensés pour X. Le travail est donc plus lourd à ce niveau.

Par ordre de maturité vis‐à‐vis de Wayland, et de sortie probable :

Enlightenment

Enlightenment semble très avancé concernant une prise en charge à 100 % de Wayland avec le développement d’un compositeur correspondant.

GNOME

Pour GNOME 3.10 (septembre 2013), X restera par défaut. Néanmoins, en mode Wayland, GNOME Shell agira en compositeur Wayland, le serveur GTK+ sera utilisable et les applications non migrées utiliseront la compatibilité X (XWayland) de manière transparente.

Pour GNOME 3.12 (mars 2014), le portage sera normalement fini (bureau et applications). Les applications éventuellement non migrées fonctionneront toujours grâce à XWayland, en attendant leur tour. Il n’est en revanche pas garanti que le bureau GNOME 3.12 puisse continuer à fonctionner avec X.Org seul, à cause d’incompatibilités envisagées par les développeurs.

KDE

La communauté KDE, grâce au passage à Qt 5, cherche à éviter un big bang comme celui qui eut lieu entre KDE 3 et KDE 4, ou celui entre GNOME 2 et GNOME 3. Les bibliothèques, le bureau et les applications suivent des cycles séparés et il n’y aura donc pas de KDE 5 à une date fixée qui prendra en charge Wayland. L’adoption sera progressive, avec un stade où il sera pris en charge par le bureau, puis par les applications au moment de leur passage individuel à Qt 5.

Pour KDE SC 4.11 (août 2013) :

  • les bibliothèques (KDE Frameworks) sont maintenant engagées sur Qt 5 ;
  • le bureau finira bientôt sa migration vers QML ;
  • un prototype Wayland sera livré en option, permettant une exécution non optimale.

Pour la suite :

  • un compositeur compatible Wayland et X va enrichir KWin. Martin Graeßlin a entamé le travail, et il a d’ailleurs indiqué que Wayland apporte de nouvelles possibilités dans ce domaine : un plantage de Wayland à cause d’un mauvais pilote graphique pourrait être détecté et récupéré, sans impact sur les applications lancées. Peut‐être une option possible dès KDE SC 4.12 ;
  • le développement de Plasma s’arrête avec la 4.11, et plasma 2 sera développé avec KDE Frameworks 5.

Distributions

Rebecca Black OS

Cette distribution, qui n’est pas forcément connue de tous, est un disque amorçable de démonstration de Wayland. À noter que si vous utilisez GRUB 2, vous pouvez lancer directement l’image ISO à partir de GRUB et de votre disque dur, pour de meilleures performances.

Rebecca Black OS, qui vient d’être mis à jour en version 1.2, est maintenu par un passionné, sur une base de Kubuntu. Il ne faut donc pas s’attendre à un niveau de finition exemplaire, mais plutôt à une bonne opportunité de tester la prise en charge des bibliothèques graphiques (EFL, GTK+, Qt) en mode Wayland « pur » ou avec une couche de compatibilité X, ou encore d’être impressionné(e) par les performances de redimensionnement de fenêtres.
→ http://sourceforge.net/projects/rebeccablackos/?source=dlp

Kubuntu

Kubuntu, ainsi que les autres distributions basées sur Ubuntu, subissent la décision de Canonical d’avoir un serveur d’affichage, Mir, conçu pour ne fonctionner correctement qu’avec Unity ou un mode de compatibilité X. Devant l’impossibilité de trouver une solution satisfaisante pour les développeurs Kubuntu, Jonathan Riddell a annoncé que l’avenir de Kubuntu passera par Wayland, avec les 13.10 et 14.04 LTS qui resteront basées sur X par défaut.
→ http://blogs.kde.org/2013/06/26/kubuntu-wont-be-switching-mir-or-xmir

Une solution de mise en commun de l’empaquetage graphique est à envisager avec les autres distributions qui se retrouvent dans la même situation, comme Ubuntu GNOME ou Linux Mint.

Aller plus loin

  • # Changement de pilote

    Posté par  . Évalué à 8.

    un plantage de Wayland à cause d'un mauvais pilote GPU pourrait être détecté et récupéré sans impact sur les applications lancées

    Cela voudrait-il dire qu'il serait possible de changer de pilote à chaud. Cela permettrait par exemple de changer des pilotes libres vers les pilotes propriétaires (quand ils prendront en charge Wayland) pour pouvoir jouer.

    « 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: Changement de pilote

      Posté par  (site web personnel) . Évalué à 9.

      Ou de switcher d'une carte graphique peu consommatrice et peu performante vers l'une qui est plus puissantes quand c'est nécessaire.

      • [^] # Re: Changement de pilote

        Posté par  . Évalué à 5.

        Ça, si j'ai bien compris, ce n'est pas le problème de Wayland mais des applications qui utilisent ce qu'elles veulent pour rendre leur buffer (une carte consommatrice ou une autre). C'est donc ces dernières qui devront gérer de manière intelligente.

        « 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: Changement de pilote

          Posté par  (site web personnel) . Évalué à 10.

          Exactement. Voilà l'extension qui devra être utilisée par les applications: https://www.opengl.org/registry/specs/ARB/robustness.txt

          Il suffira qu'une application ne supporte pas un changement de contexte pour que l'on ne puisse pas éteindre un GPU. Cela dit, on pourra toujours lancer une appli sur le GPU de son choix.

        • [^] # Re: Changement de pilote

          Posté par  (site web personnel) . Évalué à 3.

          Et si le dev ne fait rien de particulier, on aura un bon comportement par défaut?

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: Changement de pilote

            Posté par  . Évalué à 3.

            Ça dépendra des bibliothèques utilisées.

            « 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: Changement de pilote

              Posté par  . Évalué à 2.

              Concretement si une appli utilise uniquement GTK+, Qt ou autres toolkits graphiques, et rien d'exotique pour faire son rendu graphique (pas de webkit embarque par exemple), est-ce que le changement des pilotes a chaud ou le swicth de carte graphique seront supportes out of the box, sans aucune intervention du mainteneur de l'appli?

              • [^] # Re: Changement de pilote

                Posté par  . Évalué à 4.

                Pour l'instant, c'est trop tôt pour le savoir, il faut déjà que ces toolkits fonctionnent sur Wayland avant d'avoir des fonctionnalités supplémentaires. On peut imaginer que ce sera le cas mais pas d'assurance.

                « 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: Changement de pilote

                  Posté par  . Évalué à 2.

                  Apparemment d'apres le post de Martin Peres ci-dessus ca depend du support par une application (donc la lib graphique dans mon cas) de l'extension OpenGL ARB robustness.

                  En gros, en theorie, oui ce sera possible. Reste a voir si quelqu'un l'implementera dans la pratique pour chaque toolkit.

              • [^] # Re: Changement de pilote

                Posté par  . Évalué à 2.

                J'ai quand meme bien un doute sur l'interet d'un tel mode. A part si on code un editeur 3D ou un jeu, une carte Intel est largement suffisante pour n'importe quel application et pour un editeur 3d ou un jeu, il vaut mieux tout mettre sur une grosse carte 3d des le debut a mon avis. Mais bon, si tu as une explication de l'interet.

                • [^] # Re: Changement de pilote

                  Posté par  . Évalué à 4.

                  Le premier exemple qui me vient en tête, c'est le navigateur Web, pas besoin d'avoir une carte puissante la plupart du temps mais si on démarre un jeu avec WebGL,ça vaut peut être la peine de lancer la carte puissante.

                  « 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: Changement de pilote

          Posté par  (site web personnel) . Évalué à 2.

          J'avoue que c'est un domaine de programmation que je ne connais pas mais je suis surpris quand même. Pour moi le propre du serveur d'affichage c'était justement de gérer l'affichage, et donc s'adresser à la carte graphique (d'autant plus avec la transparence réseau). Je comprend qu'il y ait des accès relativement direct avec opengl et quelques primitives, mais je ne comprends pas pourquoi on s'adresse à une carte particulière.

          Si on gère le tracé dans l'appli (via le toolkit) et l'appel directement à la carte, il reste quoi dans le serveur d'affichage ?

          • [^] # Re: Changement de pilote

            Posté par  . Évalué à 6.

            C'est le principe du compositeur, l'application se débrouille pour envoyer un tableau de pixel à afficher au compositeur et ce dernier se débrouille pour afficher une image qui contient les tableaux de pixels des différentes applications. En plus de ça, le compositeur doit gérer les entrées pour les envoyer à la bonne applications et quelques cas particuliers comme les popups ou l'écran de verrouillage.

            « 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: Changement de pilote

      Posté par  . Évalué à 8.

      Cela voudrait-il dire qu'il serait possible de changer de pilote à chaud. Cela permettrait par exemple de changer des pilotes libres vers les pilotes propriétaires (quand ils prendront en charge Wayland) pour pouvoir jouer.

      Comme le fait Windows depuis 2009 (sortie de Windows 7), genre lors d'une mise à jour du pilote, ou un redémarrage du pilote graphique quand il plante sans fermer la session ni les applications ?

      Cool !

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Changement de pilote

        Posté par  . Évalué à -10.

        Ouais, comme le fait dos
        J'imagine que la différence, c'est le non-besoin de reboot..

        • [^] # Re: Changement de pilote

          Posté par  . Évalué à 9.

          Ça fait quelques années que j'ai pas rebooté windows (malgré par ailleurs ses quelques défauts non négligeables) pour une mise à jour de driver graphique. C'est pas en racontant n'importe quoi sur windows qu'on fera avancer linux et le libre en général.

    • [^] # Re: Changement de pilote

      Posté par  . Évalué à 2.

      C'était pareil avec X je crois mais les toolkit ne supportaient pas ça, j'ignore s'ils vont ajouter ce qu'il faut pour Wayland alors qu'ils n'ont pas fait le travail pour X.

      Sinon une regarde pour ce qui est des performances: XMir baisse les performances de 10% par rapport à du X pur(benchmarké par Phoronix), XMir étant en gros un clone d'XWayland j'ai un gros doute sur cette potentielle amélioration des perfs d'XWayland par rapport à du X pur.

      • [^] # Re: Changement de pilote

        Posté par  . Évalué à 6.

        Oui, mais non, XWayland est aujourd'hui plus performant dans certain cas et identique dans les autres que X. La raison des lenteurs de XMir etant le manque d'un certain nombre de fast path assez obligatoire.

        • [^] # Re: Changement de pilote

          Posté par  (site web personnel) . Évalué à 6.

          Tu peux oublier les doutes, Wayland peut être plus rapide malgré une couche de compatibilité X.

          En 2D
          http://openbenchmarking.org/result/1306302-UT-MERGE572853

          Avec Cairo
          http://openbenchmarking.org/result/1306306-UT-MERGE610023

          Je ne me souviens trop plus la raison qui avait été donnée.

          • [^] # Re: Changement de pilote

            Posté par  . Évalué à 2.

            Merci pour les chiffres, je suis surpris: c'est rare que d'ajouter une couche augmente les performances..

            • [^] # Re: Changement de pilote

              Posté par  (site web personnel, Mastodon) . Évalué à 6.

              La couche doit être faite intelligemment mais surtout, tout le code sous la couche est totalement différent.

            • [^] # Re: Changement de pilote

              Posté par  . Évalué à 10.

              D'après ce que j'ai pu comprendre, XWayland est plus performant que X car les applications sont exécutées séparément et en "rootless". En gros chaque application est en fullscreen sur son propre X server ce qui évite pas mal de choses inutiles do coté X comme le Compositing et le fait de gérer plusieurs clients en même temps vu que c'est le Compositeur Wayland qui fera ça.
              XMir par contre lance des bureaux entiers sur un seul X server, puis transmet l'image finale à Mir, ce qui en plus de n'éliminer aucun des inconvénients de Xorg (notamment le gros du Compositing fait du côté de X et non de Mir) ne fait que rajouter une couche inutile à l'ensemble.

              • [^] # Re: Changement de pilote

                Posté par  (site web personnel, Mastodon) . Évalué à 2.

                Ah oui, je comprends mieux. Merci.

                Donc finalement Mir utilisera à peu près la même solution que Bumblebee : utiliser deux serveurs graphiques distincts et tout renvoyer sur le même écran.

                Ce que je ne comprends pas, c'est comment Mir fera pour que la carte graphique ne se mélange pas les pinceaux pour envoyer les images au bon serveur ? En effet, pour Bumblebee, il n'y a pas de soucis, puisqu'il y a deux cartes qui ont deux jobs séparés.

            • [^] # Re: Changement de pilote

              Posté par  (site web personnel) . Évalué à 10.

              Tu te mélanges les pinceaux avec ces histoires de couches et surcouches :
              _X + un layer de compatibilité quelconque sera plus lent qu'X seul
              _Wayland + un layer de compatibilité pour X sera plus lent que Wayland seul, mais pas forcément plus lent qu'X (si Wayland est plus rapide qu'X)

            • [^] # Re: Changement de pilote

              Posté par  . Évalué à 2.

              N'oublie pas qu'X.org se tartine beaucoup (vraiment vraiment beaucoup) de code pour des raisons historiques de compatibilite qui ne sont pas ou peu utilisees, ou sous optimales pour les memes raisons de compatibilite. Tout ce code inutile peut ralentir la machine.

              Weston a fait table rase de ce passe et peux donc etre plus performant grace a ca.

              • [^] # Re: Changement de pilote

                Posté par  . Évalué à 0.

                Tout ce code inutile peut ralentir la machine.

                Bof, moi j'aurais tendance à dire que du code non inutilisé a un impact très faible sur les performances.

    • [^] # Re: Changement de pilote

      Posté par  . Évalué à 7.

      plantage de wayland

      Ça n'a pas de sens si j'ai bien suivi, wayland n'étant que le protocole/la lib de communication avec le compositeur.
      Crash du compositeur plutôt ?

      • [^] # Re: Changement de pilote

        Posté par  . Évalué à 2.

        Yep c'est un abus de langage.

        Il aurait ete correct de parler de plantage du compositeur (Weston dans ce cas).

  • # Typo

    Posté par  (site web personnel) . Évalué à 2.

    Jonathan Riddell a annoncé que l'avenir de Kubuntu passera par Wayland, avec les 13.10 et 14.04 TLS qui resteront basés sur X par défaut.

    C'est LTS (Long-Term Support) et non pas TLS.

    • [^] # Re: Typo

      Posté par  (site web personnel) . Évalué à 2.

      Corrigé, merci.

      • [^] # Re: Typo

        Posté par  (site web personnel) . Évalué à 2.

        Il y a aussi des alinéas inopinés dans le chapitre Avancement :

        Subsurface API par Pekka Paalanen : Cette extension nous permet de
        construire des fenêtres d'application à partir de multiples surfaces Wayland,
        combinant potentiellement différents espaces colorimétriques ou
        types de tampons. Les lecteurs vidéos combinant interface graphique, vidéo et fenêtres utilisent typiquement ce genre de fonctionnalités ;

        ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

        Subsurface API par Pekka Paalanen : Cette extension nous permet de construire des fenêtres d'application à partir de multiples surfaces Wayland, combinant potentiellement différents espaces colorimétriques ou types de tampons. Les lecteurs vidéos combinant interface graphique, vidéo et fenêtres utilisent typiquement ce genre de fonctionnalités ;

        ce commentaire est sous licence cc by 4 et précédentes

  • # Enlightenment

    Posté par  . Évalué à 10.

    Petite precision concernant Enlightenment. La version git actuel supporte les clients Wayland. Il est donc possible d'utiliser des applications uniquement ecrite pour Wayland depuis une session X avec Enlightenment 18. Ce mode est utile pour tester le protocol, mais aussi absolument necessaire pour supporter les drivers proprietaires qui ne fournissent pas ce qu'il faut pour faire une implementation Wayland sans X.

    Les travaux sont en cour pour faire de Enlightenment un compositeur Wayland sans avoir besoin de X pour les drivers libre. Cela ne sera disponible que dans Enlightenment 19. La sortie de Enlightenment 18 devant arriver d'ici quelques mois, une fois les EFL 1.8 release. Si tout se passe comme prevu, on devrait avoir un support complet de Wayland et avoir une experience similaire a celle que l'on a avec X pour le debut de l'annee prochaine.

    Si l'experience est identique, il faut bien voir que Wayland ouvre un certain nombre de possibilite non negligeable a terme et c'est bien la raison pour laquelle tous les desktops libre s'y mettent. Meilleur performance, meilleur securite, meilleur portabilite (surtout dans l'embarque) et plus grande versabilite.

    • [^] # Re: Enlightenment

      Posté par  . Évalué à 4.

      J'avais pas pensé aux EFL. S'ils rendent les petits WMs pas trop compliqués à implémenter sur leur compositeur, avec la réputation de légèreté des EFL il y a clairement une bonne carte à jouer pour Enlightenment dans le nouvel écosystème:

      Give me your tired, your poor,
      Your huddled masses yearning to breathe free,
      The wretched refuse of your teeming shore.
      Send these, the homeless, tempest-tost to me,
      I lift my lamp beside the golden door!

    • [^] # Re: Enlightenment

      Posté par  . Évalué à -8.

      Meilleur performance,

      Meilleur performance en local, pour le distant ça reste à voir.

      • [^] # Re: Enlightenment

        Posté par  . Évalué à 10.

        Tu vas pas nous la refaire celle la ! A part Xterm, il n'y a aucun toolkit qui utilise encore les primitives de X aujourd'hui. Faire de la compression sur des deltas comme on fait de la video sera plus performant que X. D'ailleur, c'est ce que fait NX pour rendre X utilisable… Je dis ca, je dis rien !

        • [^] # Re: Enlightenment

          Posté par  . Évalué à 9.

          il n'y a aucun toolkit qui utilise encore les primitives de X aujourd'hui.

          Si: Tout les vieux machins, genre tcl/tk/athena, qui sont utilisés par des applis plus ou moins récentes et qui survivent généralement parce que ces applications servent à faire des choses utiles, genre bosser. Comme ceux qui utilise l'affichage déporté sous X sont généralement des gens qui bossent, ça pose pas trop de problème de préférer des applis moches si elles sont fonctionnelles.

          Et je veux bien voir ta compression de delta sur des connexions à 512/1024 kbit. M'est avis que c'est encore plus moche que des applications tcl/tk.

          • [^] # Re: Enlightenment

            Posté par  (site web personnel) . Évalué à 6.

            ces applications servent à faire des choses utiles, genre bosser.

            Tu veux dire qu'il y a réellement des gens qui écrivent des applications qui servent à quelque chose ? Enfin je veux dire quelque chose d'autre que mouler au travail ? o_O

      • [^] # Re: Enlightenment

        Posté par  (site web personnel) . Évalué à 6.

        La différence entre le protocole X et le streaming vidéo à la NX c'est que X propose des primitives d'affichage haut niveau.

        C'était certainement une très bonne idée il y a 20 ans où le débit réseau était limité et les interfaces fenêtrées constituée de bêtes assemblage de carrés colorés.
        Or, aujourd'hui, ce n'est plus le cas : dessiner des interfaces super jolis, supers détaillés et complexes avec de tel primitives, ça devient galère, c'est d'ailleurs pour ça que les primitives ne sont plus beaucoup utilisée.
        Avec des processeurs qui contiennent des encodeurs 1080p consommant 1W, je pense pas que ça va devenir un problème..

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

        • [^] # Re: Enlightenment

          Posté par  (site web personnel) . Évalué à 7.

          Pourtant, dans le monde Windows, RDP ainsi qu'ICA sont basés en gros sur le modèle X (primitives GDI au lieu de X). C'est d'ailleurs pour cela que l'interface Windows en RDP est le style « Windows 2000 » quand le débit est faible et non les nouveaux styles avec dégradés & tutti quanti.

        • [^] # Re: Enlightenment

          Posté par  . Évalué à 2.

          Windows 8 n'a pas 20 ans, je me trompe ?

          ok, je sors ---------->[] par la fenêtre

  • # Waylands et Mir ?

    Posté par  . Évalué à 5.

    Une chose me trouble depuis quelques temps.

    Pour avoir suivi les discussions autours de Mir et Kubuntu, le truc qui en ressortait c'était « Ubuntu passe à Mir, ce qui n'empêche certes pas les dérivés d'utiliser Wayland. Par contre le truc absolument horrible c'est qu'on va perdre la possibilité de switcher de bureau depuis l'écran de login. Brûlons Canonical pour cette hérésie ! »

    Seulement voila, Wayland n'est qu'un protocole et, que je sache, chaque gestionnaire de bureau implémente son propre compositeur en utilisant ses propres extensions.
    Il me semble que KDE et Gnome ont eux aussi prévu d'utiliser un compositeur système pour gérer les sessions, ce qui implique de lancer le compositeur en question bien avant l'écran de login.

    Du coup je doute fortement que les compositeurs seront (ou resteront) suffisamment compatibles entre eux pour permettre le switch des environnements de bureau.

    Pour cette raison, entre autre, j'ai du mal comprendre pourquoi Wayland demande à tout le monde de ré-implémenter son propre compositeur.
    De ce point de vue, l'approche Mir qui consiste à séparer l'implémentation du bureau du serveur d'affichage avec une couche de glue entre les deux me parait être conceptuellement plus intelligente.
    C'est certes plus proche de l'infrastructure X actuelle, mais ça permet de factoriser beaucoup de code entre les DE (car oui, Mir en lui même n'est absolument pas spécifique à Unity, Canonical à même proposé son aide pour porter les autres shells).

    Par exemple, si je ne m'abuse, quand les pilotes proprios vont supporter Mir, c'est bien chaque compositeur Wayland qui va devoir se rendre compatible indépendamment.
    Bonjour les bugs entre les différentes implémentations. Et qu'est-ce qui nous dit qu'une appli Gnome continuera de fonctionner aussi bien sous Kwin si l'appli en question a été codée en suivant les spécificités de l'implémentation de Wayland faite par Gnome-Shell ?

    Bref, je suis assez pessimiste sur l'avenir de tout ça et j'ai besoin d'être rassuré par des gens qui s'y connaissent.
    À votre bon cœur messieurs dames !

    • [^] # Re: Waylands et Mir ?

      Posté par  . Évalué à 7.

      De ce que j'ai compris, Wayland réemploie les pilotes de Xorg:

      Why duplicate all this work?

      Wayland is not really duplicating much work. Where possible, Wayland reuses existing drivers and infrastructure. One of the reasons this project is feasible at all is that Wayland reuses the DRI drivers, the kernel side GEM scheduler and kernel mode setting. Wayland doesn't have to compete with other projects for drivers and driver developers, it lives within the X.org, mesa and drm community and benefits from all the hardware enablement and driver development happening there.

      Ça ne devrait donc rien changer pour ce qui est des pilotes proprios.

      • [^] # Re: Waylands et Mir ?

        Posté par  . Évalué à 1. Dernière modification le 18 juillet 2013 à 15:23.

        Merci, tu mets le doigt sur ce que je disais en fait.

        Sauf si je fais fausse route, cette FAQ est inexacte. Wayland ne réutilise pas les drivers ni l'infrastructure existante, Wayland n'est qu'un protocole, pas un morceau de code.
        Weston, UNE implémentation, (qui était certes probablement unique à l'époque) réutilise en effet la pile graphique libre.

        Ce que je veux dire c'est que l'ensemble des compositeurs Wayland ne semblent pas partager de code à ce niveau (l'interface) et que c'est selon moi extrêmement casse gueule.

        Ça ne devrait donc rien changer pour ce qui est des pilotes proprios.

        De ce que je sais les pilotes proprios ont besoin d'une interface spécifique car ils ne peuvent pas s'intégrer dans KMS/GEM &co pour des raisons de licence.
        Ce qui va se passer selon moi c'est qu'un beau jour Canonical va publier un communiqué disant « on s'est mis d'accord avec AMD et Nvidia sur le support d'une API dans leurs drivers. Voici le header en question. ».

        J'imagine déjà le bordel entre toutes les implémentations de Wayland.
        (notez que la situation serait exactement la même si Canonical avait décider de faire son propre compositeur Wayland plutôt que Mir)

        • [^] # Re: Waylands et Mir ?

          Posté par  . Évalué à 2. Dernière modification le 18 juillet 2013 à 15:49.

          Wayland ne réutilise pas les drivers ni l'infrastructure existante, Wayland n'est qu'un protocole, pas un morceau de code.

          Bien sûr que si c'est du code, tout comme X est à la fois un protocole et une implémentation de référence.

          • [^] # Re: Waylands et Mir ?

            Posté par  . Évalué à 1.

            Sauf que sous l'ère X tout le monde utilise l'implémentation de référence tandis que tout porte à croire que personne n'utilisera Weston en pratique.

            Je ne connais pas les tréfonds de la "libwayland-server" donc si tu me dis qu'elle définie suffisamment de code commun pour éviter tous les problèmes que j'évoque, je veux bien te croire.
            Mais j'avais plutôt l'impression qu'elle se concentrait sur l'implémentation d'un système d'IPC tout en faisant l'impasse sur un modèle de driver (encore une fois, je me trompe peut-être).

            • [^] # Re: Waylands et Mir ?

              Posté par  . Évalué à 3.

              C'est vrai que c'est pas évident (je ne suis pas du tout un spécialiste des histoires de piles graphiques)… De ce que je comprends néanmoins, c'est via openGL que les compositeurs communiquent avec le matériel:

              Wayland Rendering

              One of the details I left out in the above overview is how clients actually render under wayland. By removing the X server from the picture we also removed the mechanism by which X clients typically render. But there's another mechanism that we're already using with DRI2 under X: direct rendering. With direct rendering, the client and the server share a video memory buffer. The client links to a rendering library such as OpenGL that knows how to program the hardware and renders directly into the buffer. The compositor in turn can take the buffer and use it as a texture when it composites the desktop. After the initial setup, the client only needs to tell the compositor which buffer to use and when and where it has rendered new content into it.

              Ça colle avec ce que j'avais par ailleurs lu quand je m'étais penché sur l'avenir des WMs. Donc tu aurais à moitié raison, c'est bien au compositeur de communiquer avec le matos, mais via un standard qui est openGL, et qui est visiblement impliqué dans la communication avec Wayland, si j'en crois les deux dernières entrées de la FAQ:

              How can I replace Wayland's Window Manager?

              The Wayland architecture integrates the display server, window manager and compositor into one process. You can think of Wayland as a toolkit for creating clients and compositors. It is not a specific single compositor or window manager. If you want a different window manager, you can write a new one.

              This may sound like a lot of work, but one of the key points about Wayland is that the boilerplate code to a Wayland compositor is comparable or less than the X boilerplate involved in becoming an X window manager and compositor. Bringing up EGL and GLES2 on the Linux KMS framebuffer and reading input from evdev can be done in less than a thousand lines of code. The Wayland server side library provides the protocol implementation and makes it easy to put the pieces together.

              Why does Wayland use EGL and GLES2?

              EGL is the only GL binding API that lets us avoid dependencies on existing window systems, in particular X. GLX obviously pulls in X dependencies and only lets us set up GL on X drawables. The alternative is to write a Wayland specific GL binding API, say, WaylandGL.

              A more subtle point is that libGL.so includes the GLX symbols, so linking to that library will pull in all the X dependencies. This means that we can't link to full GL without pulling in the client side of X, so we're using GLES2 for now. Longer term, we'll need a way to use full GL under Wayland.

              • [^] # Re: Waylands et Mir ?

                Posté par  . Évalué à 6.

                Ça colle avec ce que j'avais par ailleurs lu quand je m'étais penché sur l'avenir des WMs. Donc tu aurais à moitié raison, c'est bien au compositeur de
                communiquer avec le matos, mais via un standard qui est openGL, et qui est visiblement impliqué dans la communication avec Wayland, si j'en crois les deux
                dernières entrées de la FAQ:

                Le compositeur utilise libGL pour communiquer directement avec le matériel, et le client aussi.
                Il n'est donc pas beaucoup plus dur d'écrire un compositeur pour Wayland que pour X11.

                Par contre, puisqu'il n'y a plus séparation du processus du gestionnaire de fenêtre et du serveur, un bogue dans celui-là va faire planter tout le système, alors que sous X11, on a l'habitude des gestionnaires de fenêtres bogués qui plantent et redémarrent souvent (par exemple Xfwm4).

                En gros, le code de X.org a beau être gros, il correspond a une qualité bien supérieure à un gestionnaire de fenêtre et est beaucoup plus fiable.

          • [^] # Re: Waylands et Mir ?

            Posté par  . Évalué à -2.

            Oui Wayland contient du code, mais ne connait rien à l'affichage. En gros Wayland un protocol IPC et rien d'autre.
            En effet la conception de wayland laisse la porte ouverte à plein de choses.
            Rapidement le compositeur annonce aux clients ces capacités et les interfaces qu'il possède. Aux clients d'utiliser ou non ces interfaces. C'est beau comme çà mais soit le client se limite à une API de base, soit il implémente les extensions du compositeur (weston, lipstick, kwin, gnome…), soit il crashe.
            Actuellement l'équipe de wayland étoffe son API pour qu'un grand nombre de clients puissent tourner sur tous les compositeurs (et surtout sur weston). Mais déjà les compositeurs commencent à bien varier en effet certains vont définir des extensions pour implémenter des WM alors que par défaut wayland veut que chaque client gère tout son look & feeld même sa barre de titre et ses boutons de dimensionnement.

            A ce que j'ai compris Canonical vise ubuntu touch en priorité pour MIR. Et donc ne tombe pas encore en concurrence avec wayland car les perfs de wayland en embarqué sont lamentables. Je ne connais pas l'implémentation de MIR mais cela ne peut pas être pire que wayland (DirectFB a encore de longs jours devant lui).

            Pour ce qui est de SurfaceFlinger celui-ci est aussi dédié à l'embarqué, du moins dans les premières versions d'Android. Il est dommage que Google nous refait le jeu de Microsoft et demande toujours plus de puissance, car l'implémentation de SurfaceFlinger était bien. Maintenant il faut à tout prix de l'accélération 3D, et à part sur les PCphones, il est plus possible de l'utiliser. Et puis il était trop lié à Android.

            • [^] # Re: Waylands et Mir ?

              Posté par  . Évalué à 1.

              Ce serait donc Weston qui serait lié à openGL et non Wayland ? C'est vrai que j'ai l'impression que la FAQ parle de Wayland pour parler de Wayland+Weston (la question du "Gestionnaire de fenêtre de Wayland", m'a fait tiqué, dans la mesure où le WM est un morceau de Weston)…

            • [^] # Re: Waylands et Mir ?

              Posté par  . Évalué à 8.

              Et donc ne tombe pas encore en concurrence avec wayland car les perfs de wayland en embarqué sont lamentables.

              Belle déclaration péremptoir, non wayland n'a pas des performances lamentables montrent moi un benchmark une étude qui dise ça. Pour preuve du contraire regarde la technologie démo de wayland sur raspberry pi. Et wayland est bien plus efficace que X ne le pourra jamais être sur les plateformes embarquées (utilisation des overlayer|layer par exemple).

            • [^] # Re: Waylands et Mir ?

              Posté par  . Évalué à 10.

              A ce que j'ai compris Canonical vise ubuntu touch en priorité pour MIR. Et donc ne tombe pas encore en concurrence avec wayland car les perfs de wayland en embarqué sont lamentables. Je ne connais pas l'implémentation de MIR mais cela ne peut pas être pire que wayland (DirectFB a encore de longs jours devant lui).

              Serieux ! Faut se documenter avant de dire de si grosse betise ! Wayland est aujourd'hui plus performant que Mir et utilise depuis longtemps dans l'embarque. La difficulte est de supporter toutes les extentions necessaire a une experience desktop complete. Je ne sais pas d'ou tu sors cette idee que les perfs de Wayland en embarque sont lamentable, mais techniquement le modele de rendu de Wayland vise a minimiser les phases de rendu en mode composite pour privilegie les rendu fullscreen et par layer. C'est la combinaison ideal pour obtenir le maximum de performance du hardware. En gros, Wayland permet d'atteindre les performances maximum du hardware, ce que ne permet pas encore Mir.

              Quand a DirectFB, a part sur des set top box completement ferme, personne ne l'utilise pour une bonne raison, ca n'apporte pas de solution propre et efficace pour resoudre les problemes graphiques rencontre par Linux. D'ailleur dans la pratique DirectFB est maintenant plus lent que pas mal d'alternative, c'est pour ca que le backend DirectFB des EFL est abandonne.

              Pour ce qui est de SurfaceFlinger celui-ci est aussi dédié à l'embarqué, du moins dans les premières versions d'Android. [..] Maintenant il faut à tout prix de l'accélération 3D, et à part sur les PCphones, il est plus possible de l'utiliser.

              A ma connaissance SurfaceFlinger ne necessite pas de l'acceleration 3d, mais juste un minimum d'acceleration 2d. C'est une des raisons pour lesquel la plus part des chipset ARM aujourd'hui arrive avec des unites dedies basse consomation pour le compositing. Et c'est une bonne chose, car cela ouvre un chemin d'optimisation supplementaire sur ces hardware la. Et faire du compositing en soft, c'est drole qu'en on est sur des basses resolutions, mais en HD, tu vas juste tuer ta batterie !

              Apres Android a ete ecris par des gens qui ne connaissait pas Linux et n'ont jamais interagit avec la communaute. Wayland est techniquement plus performant que SurfaceFlinger. La preuve en est que le developpement par les methodes du logiciel libre donne sur le long terme de meilleur resultat technique, par contre sur le court terme prendre des raccourcis aide a arriver sur le marche plus vite. Et SurfaceFlinger est dedie au haut de gamme de l'embarque pour permettre a Google de prendre la main rapidement et avant tout le monde sur tous les marches ou il peut afficher de la pub.

              • [^] # Re: Waylands et Mir ?

                Posté par  . Évalué à 7.

                La preuve en est que le developpement par les methodes du logiciel libre donne sur le long terme de meilleur resultat technique […]

                Tu as un lien vers cette preuve ? Autant je suis d'accord que quand ça se passe bien c'est le cas autant je n'en vois pas de preuve.

                Et SurfaceFlinger est dedie au haut de gamme de l'embarque pour permettre a Google de prendre la main rapidement et avant tout le monde sur tous les marches ou il peut afficher de la pub.

                Bouh ! Le grand méchant ! Pour qu'Android puisse exister (face à iOS qui était déjà très présent), il fallait qu'il arrive sur le marché rapidement Google à fait ce qu'il faut pour. Affirmer que ce sont des gens qui ne connaissaient pas Linux me semble bien péremptoire (à croire que tout ceux qui font un serveur d'affichage autre que Wayland/Weston sont insultés de la même façon).

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Waylands et Mir ?

                Posté par  . Évalué à 4.

                Merci, je me demandais ce quel feu je mettrais au poudre :-)

                Mais nous n'avons pas du tout la même vision de l'embarqué… Je crois que n'étant pas sur la même base, il n'est pas possible de se comprendre. Un CPU à 1.2GHz quadricore avec un GPU et 1GB de mémoire n'est pas de l'embarqué selon ma vision personnelle. Mais je vous l'accorde Wayland est plus performant que X, ce n'était pas difficile.

                Dire que les settopbox n'est que un petit monde est très restrictif quand on compte le nombre d'entre elles. Mais je ne pense pas que cela soit de l'embarqué non plus.

                Il faut regarder aussi du coté de l'industrie et du militaire. Un grand nombres d'appareils qui possèdent un écran pour afficher des infos, n'ont pas besoin de 3D, de HD ou décodeur vidéo. Par contre ils ont besoin de fenêtrage, d'accès aux évènements matériels. Et pour eux il n'y a pas grand chose que DirectFB sur Linux.

                Actuellement SurfaceFlinger passe par la 3D, le rendu 2D n'est plus supporté par Google, seul les fabriquants remettent en place celui-ci pour des raisons de coûts de développement. Les premières versions de SurfaceFlinger pouvaient tourner correctement sur un CPU à 400MHz avec 256MB de RAM et rien d'autre.

                Dire que Wayland est mieux par ce que c'est développé par d'autres que Google, c'est tiré par les cheveux. Wayland est un gros mangeur de ressources et surtout de batterie, pas besoin de benchmark il suffit de regarder la gestion du flip des images dans le code. Ou encore de voir qu'en mode SHM (seul mode disponible sur des petits processeurs), il est impossible d'accéder directement à la mémoire vidéo et donc d'avoir des copies de mémoire. Je sais que c'est pour des raisons de sécurité, mais des fois il faut chercher d'autres solutions.

                • [^] # Re: Waylands et Mir ?

                  Posté par  . Évalué à 6.

                  Wayland est un gros mangeur de ressources et surtout de batterie

                  Je suppose qu'il faut lire Weston ? Parce que dans ce cas, je pense que pour l'embarqué dans le sens matos sans puce graphique, il est plus approprié d'écrire un compositeur dédié plutôt que de tout vouloir faire avec un seul.

                  « 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: Waylands et Mir ?

                  Posté par  . Évalué à 7.

                  Actuellement SurfaceFlinger passe par la 3D, le rendu 2D n'est plus supporté par Google, seul les fabriquants remettent en place celui-ci pour des raisons de coûts de développement.

                  Pas pour des questions de cout de developpement, pour des questions d'economies de batterie. L'accelerateur 2d consomme un ordre de grandeur moins que l'accelerateur 3d. Sans compter que etant une unite separe celui-ci n'impacte pas les performances lorsque le compositing fonctionne. Son absence peut se remarquer assez facilement, car le telephone se met a lagguer des qu'il y a un layer transparent au dessus. Exemple probable, le dernier LG permet de prendre des notes en transparence sur les applications. Mais des que tu as ce layer transparent, le telephone ne tiens plus du tout les 60fps. C'est donc assez flagrant comme probleme, meme sur les telephones de derniere generation.

                  Dire que Wayland est mieux par ce que c'est développé par d'autres que Google, c'est tiré par les cheveux. Wayland est un gros mangeur de ressources et surtout de batterie, pas besoin de benchmark il suffit de regarder la gestion du flip des images dans le code. Ou encore de voir qu'en mode SHM (seul mode disponible sur des petits processeurs), il est impossible d'accéder directement à la mémoire vidéo et donc d'avoir des copies de mémoire. Je sais que c'est pour des raisons de sécurité, mais des fois il faut chercher d'autres solutions.

                  Non, je dis que Wayland est developpe par un certain nombre d'individu travaillant pour un large eventail de societe avec des objectifs divers. Cela conduit forcement a realiser quelque de chose de plus efficace et generique.

                  Alors le role d'un compositeur, que ce soit X ou Wayland ou quelqu'il soit dont le but est de faire du multi-application ne peut pas se permettre de donner acces directement a la memoire. Si tu veux acceder directement a la memoire, tu fais ton application sur le frame buffer.

                  Maintenant ton hardware n'est pas si limite. 400Mhz et 256MB, c'est plutot dans la categorie luxueux pour moi ! On est pas loin de pouvoir faire tourner un desktop complet avec tout ca ;-) Je suis meme pres a parie que tu as une unite d'acceleration 2D ou au moins la gestion de plusieurs plan graphique. Largement de quoi faire tourner un Wayland. Il te manque probablement un driver KMS/DRM pour l'allocation des buffers. Et il n'y a rien qui force dans Wayland a avoir une implementation 3D pour travailler sur des buffers video. Tu peux alors directement alouer des buffer hardware et faire une implementation derriere en soft. La derniere fois que j'avais regarde ce scenario, on devait pouvoir s'en sortir en reutilisant une toute petite partie de EGL. Enfin tout depend apres du nombre d'application a gerer, mais tu dois pas en avoir beaucoup en simultanee vu le materiel, donc laisser Wayland leur donner a chacune un layer graphique doit etre le plus efficace.

                  Au final, le plus couteux sera la vitesse du backend software de ton toolkit graphique et DirectFB n'est pas bon de ce cote la. Bien entendu, si tu ne veux pas faire du multi application, mais juste avoir des fenetres dans une seule application. Pas la peine de t'ennuyer avec tout ca. Tu prend juste le framebuffer et roule avec les EFL. Peut etre un backend specifique pour tirer partie de l'acceleration 2D, si elle est un minimum utile. Et la, tu auras la solution la plus efficace et versatile.

          • [^] # Re: Waylands et Mir ?

            Posté par  . Évalué à 4.

            Bien sûr que si c'est du code, tout comme X est à la fois un protocole et une implémentation de référence.

            Ah non!

            X c'est le protocole. L'implementation de references est X.org. D'ailleurs Xfree existait (existe?).

            Wayland c'est le protocole et les API C implementant le protocole uniquement, mais surtout l'implementation de reference est Weston.

            La preuve sur http://wayland.freedesktop.org/ :

            Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol.
            Part of the Wayland project is also the Weston reference implementation of a Wayland compositor.

        • [^] # Re: Waylands et Mir ?

          Posté par  (site web personnel) . Évalué à 6.

          Sauf si je fais fausse route, cette FAQ est inexacte. Wayland ne réutilise pas les drivers ni l'infrastructure existante, Wayland n'est qu'un protocole, pas un morceau de code.

          Wayland est un protocole avec une implémentation de référence sous forme de bibliothèque.

          Weston, UNE implémentation, (qui était certes probablement unique à l'époque) réutilise en effet la pile graphique libre.

          Et pas que la pile graphique libre puisque Weston fonctionne aussi sur le Raspberry Pi, qui ne dispose pas de drivers réellement libres, ou sur des téléphones "Android" sans drivers libres non plus.

          Il faut se rappeler que Wayland/Weston est développé en partie par des employés de chez Intel, qui ne sont donc pas payés pour supporter tous les drivers exotiques qui existent. Cela n'empêche bien sûr personne de le faire.

          Ce que je veux dire c'est que l'ensemble des compositeurs Wayland ne semblent pas partager de code à ce niveau (l'interface) et que c'est selon moi extrêmement casse gueule.

          Dans le modèle actuel, il n'y a pas plus de partage de code au niveau de l'interface. Aucun changement à ce niveau.
          Si l'on parle de l'interface entre les applications et le compositeur et bien c'est la libwayland. Avant on avait la Xlib ou XCB. Tout cela est bien entendu utilisé/masqué par les toolkits (Qt, GTK+…).

          (notez que la situation serait exactement la même si Canonical avait décider de faire son propre compositeur Wayland plutôt que Mir)

          Désolé mais non, parce que l'ajout de Mir implique des modifications dans d'autres projets, comme celles nécessaires à l'ajout de Wayland : Mesa, tous les toolkits…
          Si ils avaient décidé de faire un compositeur Wayland, rien de tout cela ne serait nécessaire.

          • [^] # Re: Waylands et Mir ?

            Posté par  . Évalué à 1.

            Désolé mais non, parce que l'ajout de Mir implique des modifications dans d'autres projets, comme celles nécessaires à l'ajout de Wayland : Mesa, tous les toolkits…

            Je ne parlais pas du côté client mais plutôt de la partie entre le compositeur et le matériel (le driver model).
            Cette partie n'ai apparemment pas définie dans libwayland-server, ce qui implique que chaque compositeur en fera sa propre implémentation.

            Techniquement, il est possible de développer un nouveau frontend pour Mir qui lui permette de parler Wayland à ses clients (cf. la doc de Mir). ce qui ferait de Mir un compositeur Wayland comme un autre.
            Ce qui n'apporterai pas magiquement le support des pilotes Mir (libres, Android, bientôt proprio) aux autres compositeurs Wayland.

            Quand des boites comme Jolla disent avoir porté Wayland pour qu'il utilise les drivers Android, ça veut juste dire qu'ils ont codé un compositeur spécifique (forké en l’occurrence).

            Pour en revenir à mon point initial, l'idée du « chacun son implémentation » va pour moi poser plus de problèmes qu'autre chose.
            Il aurait mieux fallut rendre Weston plus flexible pour que les différents shells viennent s'y implémenter en tant que plugins.

            Même si Mir a été annoncé (trop ?) tard et avec une maladresse incroyable, il me parait techniquement mieux architecturé. On a un serveur qui fourni une API (pas un protocole) et le shell qui vient se brancher dessus (via une couche d'abstraction, ou pas).
            C'est certes beaucoup plus restrictif, mais ça limite les risques de divisions.

            On verra bien ce que tout ça donnera !

            • [^] # Re: Waylands et Mir ?

              Posté par  (site web personnel) . Évalué à 7.

              le support des pilotes Mir

              Mais qu'est-ce qu'un "pilote Mir" ? Seul Canonical le sait. En attendant que ça sorte, je vois mal comment on pourrait dire que cela va ou pas marcher. Il est totalement vain de continuer de discuter sur ce sujet et encore plus de dire que cela sera mieux parce que cela n'existe pas !

              Quand des boites comme Jolla disent avoir porté Wayland pour qu'il utilise les drivers Android, ça veut juste dire qu'ils ont codé un compositeur spécifique (forké en l’occurrence).

              Là encore, on n'en sait absolument rien ! Qu'est-ce qui dit qu'ils ne vont pas reverser entièrement leur compositeur comme un module pour Weston ? Et même dans le cas où ce serait un fork de Weston, ce ne serait pas le premier fork de logiciel réalisé par une entreprise pour l'adapter à un besoin spécifique (Ubuntu/Canonical ?) !

              Pour en revenir à mon point initial, l'idée du « chacun son implémentation » va pour moi poser plus de problèmes qu'autre chose.

              On a déjà plusieurs toolkits, rien d'insurmontable. Le monde du logiciel libre n'est pas connu pour l'unicité de ses implémentations/outils.

              Il aurait mieux fallut rendre Weston plus flexible pour que les différents shells viennent s'y implémenter en tant que plugins.

              Est-ce que tu crois vraiment que l'on pourrait merger Compiz et Kwin ou Mutter ? L'idée de vouloir un compositor pour tout le monde part d'une bonne intention mais ne reflète pas la réalité (Webkit/Bink ? il y a des tonnes d'exemples).

    • [^] # Re: Waylands et Mir ?

      Posté par  . Évalué à 3.

      Du coup je doute fortement que les compositeurs seront (ou resteront) suffisamment compatibles entre eux pour permettre le switch des environnements de bureau.

      Pas sûr, il y a déjà le problème de l'intégration des applis KDE, Gnome, etc, ça n'est pas magiquement fourni par X11, c'est plutôt que les devs se sont concertés, ce que tu cite est juste une "extension du problème", donc si les dev veulent que ça soit compatible ça le sera..

      Pour cette raison, entre autre, j'ai du mal comprendre pourquoi Wayland demande à tout le monde de ré-implémenter son propre compositeur.

      Probablement parce que c'est un truc assez compliqué ou il peut y avoir des divergences de point de vue: par exemple Weston impose la gestion des décorations cotés clients mais le dev principal de KWin veut lui la gestion des décorations cotés serveur.

      • [^] # Re: Waylands et Mir ?

        Posté par  . Évalué à 7.

        Weston impose la gestion des décorations cotés clients mais le dev principal de KWin veut lui la gestion des décorations cotés serveur.

        Et heureusement car gerer l' homogeneite du bureau sans cela ca va etre coton et avoir des fenetres gnome qui ont de gueules de fenetere gnome dans KDE c'est … pas top. Bon ok Weston est gnome-centriste et il semblerait que les gnomeux considerent que tu ne dois utiliser QUE des applis gnome donc ils en ont rien a faire (ils n'y a jamais eu le moindre effort de leur part dans ce sens la, le boulot a ete fait uniquement par KDE et dans les deux sens KDE/QT <-> Gnome/GTK).

        • [^] # Re: Waylands et Mir ?

          Posté par  . Évalué à 0. Dernière modification le 18 juillet 2013 à 19:49.

          Et heureusement car gerer l' homogeneite du bureau sans cela ca va etre coton

          L'homogénéité du bureau c'est loin de concerner seulement la barre des titres, du coup la déplacer coté serveur pour cette raison est très discutable.

          Ou alors il faut déplacer tous les widgets coté serveur pour la même raison.

    • [^] # Re: Waylands et Mir ?

      Posté par  . Évalué à 1. Dernière modification le 18 juillet 2013 à 17:05.

      Je dois d'abord avouer mon incompétence sur le sujet, mais à vous lire une chose me saute au visage ;-)

      Plus sur Gnu/Linux que sur d'autres systèmes, il existe sur Gnu/linux des écosystèmes différents.

      En général tout le monde s'en contente et les choses suivent leurs petits trains-trains habituel…

      Moi c'est ce qui me plait, mais c'est sans doute aussi une des raisons principales de la non adoption de Gnu/linux par un plus large public.

      Pour moi Waylands ou Mir qu'importe, seul celui qui m'apportera rapidité, stabilité et compatibilité avec mon matériel vaincra !

      On y retrouve un peu de la La Cathédrale et le Bazar d’Eric Raymond

      mon approche vous parait elle stupide ?

      http://lsm2013.out.airtime.pro:8000/lsm2013.ogg Ecoutez Radio RMLL !

      • [^] # Re: Waylands et Mir ?

        Posté par  . Évalué à 4.

        Quand j'ai débuté sous GNU/Linux je ne connaissait rien aux divers distrib, j'ai simplement pris celle qui avait une communauté actif, était stable, marchait bien …..
        par la suite je suis devenu un défendeur du libre, et depuis ces problèmes comme wayland/mir me concerne et j'essaye d'y participer. Cependant, je pense que côté utilisateur (celui qui n'y connaît rien en informatique), que cette discussion ait lieu ou non, ça ne lui changera pas sa vie.
        En effet, à entendre et wayland et mir, les simples utilisateurs n'auront rien à faire.

        En revanche deux choses sont je pense bénéfiques lors de ces "querelles":
        1- Le meilleur l'emporte … : Si Mir ou Wayland est mieux que l'autre, il sera utilisé par les distributions grand public, ainsi celui-ci aura ce qu'il y a de mieux.
        2- … les autres choix restent disponibles: Ceux qui préfèrent celui / ceux qui n'ont pas "gagnés" peuvent toujours se tourner vers d'autres distrib, qui l'utiliseront.
        3- Mais ils sont développé par des bénévoles (ou presque): On ne peut pas demander à des bénévoles de travailler gratuitement et ce sans qu'ils aient leur mot à dire.

        Je dirait que le meilleur exemple est la variété de distributions.
        Il existe des centaines de distributions connues, des milliers inconnues. Il y a des dizaines de milliers (voir plus) de bénévoles qui travaillent pour faire des paquets installables automatiquement.
        Maintenant imaginons qu'il y ait une seule distribution Linux, cette distribution aurait 2 000 000 de paquets ou plus ? (Ça fait rêver).

        Mais est-ce que tous ces développeurs seraient tous d'accord sur la politique que doit suivre la distribution ? Non. ils créent alors d'autres distributions (plus ou moins proches) qui permettent aux différents utilisateurs de trouver leur bonheur (Debian et Ubuntu, bien que très proches ont une politique différente. Debian se veut libre et appartenir à sa communauté, tandis que Ubuntu (canonical) veut avoir un maximum d'utilisateurs pour gagner de l'argent)

        En tout cas je ne trouve pas ton approche stupide (j'avais et je doit avouer que par moment il m'arrive de l'avoir) ;)

    • [^] # Re: Waylands et Mir ?

      Posté par  (site web personnel) . Évalué à 4.

      Il me semble que KDE et Gnome ont eux aussi prévu d'utiliser un compositeur système pour gérer les sessions, ce qui implique de lancer le compositeur en question bien avant l'écran de login.

      Du coup je doute fortement que les compositeurs seront (ou resteront) suffisamment compatibles entre eux pour permettre le switch des environnements de bureau.

      En ce moment il y a les logins manager et les environnements de bureau et cela ne pose aucun soucis. Certes un system compositor ferait plus de chose que le login manager, mais il n'y a pas de raison que les environnements deviennent incompatibles. Le but du system compositor est principalement d'assurer le changement d'utilisateur et d'environnement justement (Chapter 2. Types of Compositors). L'avantage avec Wayland justement c'est que l'on peut imbriquer tout ça sans trop de soucis puisque l'imbrication est justement supportée (nested compositing).

      Pour cette raison, entre autre, j'ai du mal comprendre pourquoi Wayland demande à tout le monde de ré-implémenter son propre compositeur.

      Personne n'est obligé de ré-implémenter son propre compositeur, il est tout à fait possible d'utiliser Weston et de coder juste la partie qui gère les fenêtres ou autre dans un module pour weston. Le mainteneur de Kwin veut faire son propre compositeur parce qu'il ne veut tout simplement pas jeter tout le code de Kwin à la poubelle et qu'il pense pouvoir garder une grande base commune entre le support de X.org et Wayland (la gestion des fenêtre, le rendu des bordure, les thèmes…).

      De ce point de vue, l'approche Mir qui consiste à séparer l'implémentation du bureau du serveur d'affichage avec une couche de glue entre les deux me parait être conceptuellement plus intelligente.

      L'approche de Mir semble plutôt être de vouloir tout gluer ensemble (https://wiki.ubuntu.com/Mir/Spec?action=AttachFile&do=get&target=mir-scope.png). Je ne comprend pas trop ce qu'il faudrait séparer entre le bureau et le compositeur. Il faut se rappeler que dans le cas de Wayland, ce sont les applications qui font le rendu de leur contenu et le compositeur se charge juste de l'afficher à l'écran et de gérer les fenêtres. Je vois mal comment on pourrait séparer celui qui affiche les fenêtres de celui qui les gère.

      (car oui, Mir en lui même n'est absolument pas spécifique à Unity, Canonical à même proposé son aide pour porter les autres shells).

      Quelle vaste blague, je pense que l'on peut attendre longtemps l'aide de Cannonical sur ce point. Si ils veulent que les autres shells marchent, ils peuvent tout à fait les porter, on n'attends que ça. J'ai comme l'impression que cela ne vas pas se produire.

      Par exemple, si je ne m'abuse, quand les pilotes proprios vont supporter Mir, c'est bien chaque compositeur Wayland qui va devoir se rendre compatible indépendamment.

      Toujours pareil, on aimerait bien voir ces fameux drivers avec le support pour Mir. Dans la situation actuelle, principalement sur les téléphones mobiles, il y a libhybris, qui peut être exploitée par Wayland/Weston (http://en.wikipedia.org/wiki/Hybris_%28software%29). Je doute très fortement que Cannonical arrivera à obtenir autre chose que ce "standard" implicite obtenu avec les drivers propriétaires pour Android. Dans le cas ou ils y arriveraient, qu'est-ce qui empêcherait les compositeurs Wayland de supporter aussi cette nouvelle librairie spéciale Mir ?

      Bonjour les bugs entre les différentes implémentations. Et qu'est-ce qui nous dit qu'une appli Gnome continuera de fonctionner aussi bien sous Kwin si l'appli en question a été codée en suivant les spécificités de l'implémentation de Wayland faite par Gnome-Shell ?

      Il ne faut pas confondre le travail du compositeur avec celui des applications qui ne font que du rendu, en utilisant en grande partie un version d'OpenGL ou du rendu software sur le CPU. Même les drivers propriétaires sont obligés de fournir une librairie 'libgl' si ils veulent que les applications marchent avec leur driver. Coder une application avec des "spécificités de l'implémentation de Wayland faite par Gnome-Shell" est un non-sens. Le protocole est fixé, versionné, et les extensions sont ajoutées dans Wayland, pas par les compositeurs qui vont "remplacer" Weston.

      • [^] # Re: Waylands et Mir ?

        Posté par  . Évalué à 1.

        En ce moment il y a les logins manager et les environnements de bureau et cela ne pose aucun soucis. Certes un system compositor ferait plus de chose que le login manager, mais il n'y a pas de raison que les environnements deviennent incompatibles. Le but du system compositor est principalement d'assurer le changement d'utilisateur et d'environnement justement (Chapter 2. Types of Compositors). L'avantage avec Wayland justement c'est que l'on peut imbriquer tout ça sans trop de soucis puisque l'imbrication est justement supportée (nested compositing).

        S'ils ont bien pris soin de standardiser cette partie et que les extensions customs de chaque DE ne se marchent pas dessus, ça peut en effet marcher.

        Personne n'est obligé de ré-implémenter son propre compositeur, il est tout à fait possible d'utiliser Weston et de coder juste la partie qui gère les fenêtres ou autre dans un module pour weston

        Tout à fait. Mais en pratique personne ne le fait.
        C'est là que le bât blesse selon moi, je n'aurais rien à redire si tout le monde avait étendu Weston plutôt que de refaire son propre truc.

        L'approche de Mir semble plutôt être de vouloir tout gluer ensemble

        Mir en lui même est indépendant et n'a pas besoin de Unity (cf les exemples fournis dans les sources).
        Les deux bases de codes sont développées séparément, avec un couche de compatibilité entre les deux (Mir étant développé en C++ tandis que Unity 8 est développé en QML).

        [Mir is a] general purpose display server that other distributions, desktops, and other upstreams can use

        (http://www.jonobacon.org/2013/07/10/mir-for-everyone/)

        Ce n'est pas non plus ce que j'avais compris lors de l'annonce initiale, mais il semble que Canonical ne cherche plus à restreindre Mir aux besoins de Unity.
        (tant mieux mais trop tard ?)

        Quelle vaste blague, je pense que l'on peut attendre longtemps l'aide de Cannonical sur ce point. Si ils veulent que les autres shells marchent, ils peuvent tout à fait les porter, on n'attends que ça. J'ai comme l'impression que cela ne vas pas se produire.

        Sachant qu'ils ce sont pris un vent et que personne ne c'est montré intéressé, ça risque de prendre du temps en effet.
        Et il est clair qu'ils ne vont pas s'amuser à porter un DE si c'est pour que le patch ne soit pas accepté upstream après.

        Il ne faut pas confondre le travail du compositeur avec celui des applications qui ne font que du rendu, en utilisant en grande partie un version d'OpenGL ou du rendu software sur le CPU. Même les drivers propriétaires sont obligés de fournir une librairie 'libgl' si ils veulent que les applications marchent avec leur driver. Coder une application avec des "spécificités de l'implémentation de Wayland faite par Gnome-Shell" est un non-sens. Le protocole est fixé, versionné, et les extensions sont ajoutées dans Wayland, pas par les compositeurs qui vont "remplacer" Weston.

        http://wayland.freedesktop.org/docs/html/sect-Protocol-Interfaces.html :

        Specific compositor implementations may have their own interfaces provided as extensions

        C'est ça qui me fait peur.
        Xorg aussi utilise des extensions par rapport aux specs X11, mais vu que tout le monde l'utilise la question de la compatibilité entre les implémentation ne se pose pas.

        • [^] # Re: Waylands et Mir ?

          Posté par  . Évalué à 3.

          Sachant qu'ils ce sont pris un vent et que personne ne c'est montré intéressé, ça risque de prendre du temps en effet.
          Et il est clair qu'ils ne vont pas s'amuser à porter un DE si c'est pour que le patch ne soit pas accepté upstream après.

          Ouhais enfin Canonical, d'apres ce que j'ai pu lire, developpe Unity avec QML en faisant des extensions a celui ci mais sans faire les remonter upstream…

          si ils veulent que Mir soit utilise par d'autre DE c'est a eux et a eux seul de faire le port. Ce sont eux qui ont forke c'est a eux d'assumer.

          • [^] # Re: Waylands et Mir ?

            Posté par  . Évalué à 1.

            si ils veulent que Mir soit utilise par d'autre DE c'est a eux et a eux seul de faire le port. Ce sont eux qui ont forke c'est a eux d'assumer.

            C'est tout le problème de Mir : il a été annoncé de façon totalement désastreuse.
            Tout le monde s'est braqué et je vois mal les grands acteurs comme Gnome ou KDE changer d'opinion à son sujet avant plusieurs longs mois (le temps qu'on puisse tirer un premier bilan de la mise en production des premiers Waylands et de Mir).

        • [^] # Re: Waylands et Mir ?

          Posté par  (site web personnel) . Évalué à 2.

          Tout à fait. Mais en pratique personne ne le fait.
          C'est là que le bât blesse selon moi, je n'aurais rien à redire si tout le monde avait étendu Weston plutôt que de refaire son propre truc.

          Je crois bien me souvenir qu'il y a des gens qui le font chez Intel. De plus ceux qui ont fait les premiers essais de tilling window manager ont modifié aussi Weston et ne sont pas parti de zéro. Weston était prévu à l'origine pour être un exemple, c'est tout. Il est logique que les gens fassent leur propre implémentation.

          (Citations suivantes issues d'un autre commentaire)

          Même si Mir a été annoncé (trop ?) tard et avec une maladresse incroyable, il me parait techniquement mieux architecturé.

          C'est étonnamment pas du tout l'avis de tous les gens que l'on pourrait juger techniquement compétents sur le sujet : les développeurs de la stack graphique sous Linux, qui sont étrangement aussi plus ou moins liés à Wayland/Weston.

          On a un serveur qui fourni une API (pas un protocole) et le shell qui vient se brancher dessus (via une couche d'abstraction, ou pas). C'est certes beaucoup plus restrictif, mais ça limite les risques de divisions.

          La différence entre un protocole et une API est extrêmement mince ici vu qu'il y une implémentation du protocole Wayland sous forme de bibliothèque. Je vois mal l'avantage que pourrait avoir l'un sur l'autre, si ce n'est que Canonical a clairement annoncé qu'ils ne comptaient pas faire attention à la compatibilité alors que l'objectif de Wayland est justement d'y faire très attention.

          Specific compositor implementations may have their own interfaces provided as extensions
          C'est ça qui me fait peur. Xorg aussi utilise des extensions par rapport aux specs X11, mais vu que tout le monde l'utilise la question de la compatibilité entre les implémentation ne se pose pas.

          Rien ici n'est obligatoire et ce n'est pas la voie qui est envisagée par les environnements de bureau actuels. Ces extensions sont là pour palier aux cas qui ne peuvent pas être prévus actuellement. Tout dans Wayland est fait pour prévoir le futur pour éviter de reproduire la situation avec Xorg.

          • [^] # Re: Waylands et Mir ?

            Posté par  . Évalué à 2.

            Je crois bien me souvenir qu'il y a des gens qui le font chez Intel. De plus ceux qui ont fait les premiers essais de tilling window manager ont modifié aussi Weston et ne sont pas parti de zéro. Weston était prévu à l'origine pour être un exemple, c'est tout. Il est logique que les gens fassent leur propre implémentation.

            Que je sache, il s'agit toujours de forks et non de plugins. Si ces projets vivent, ils vont probablement continuer de diverger.
            D'où l'intérêt de l'approche plugin.

            Au fait, ma mauvaise opinion sur « les Waylands » vient principalement de cet article + commentaires : http://smspillaz.wordpress.com/2012/12/24/sideways/
            (il travaillait chez Canonical à l'époque, Mir était un POC en interne et son adoption n'avait pas encore été décidée)
            Le fait que le scénario du pire (les Waylands donc) ce soit réalisé est celon moi l'une des raison qui ont fait perdre la foi en Wayland chez Canonical. C'est pour ça que j'essaye de comprendre.

            C'est étonnamment pas du tout l'avis de tous les gens que l'on pourrait juger techniquement compétents sur le sujet : les développeurs de la stack graphique sous Linux, qui sont étrangement aussi plus ou moins liés à Wayland/Weston.

            La présomption d'incompétence chez tous les autres n'est pas forcément légitime non plus ;)
            Le débat Mir/Wayland n'est actuellement pas objectif. Vu la façon dont Canonical a sortit Mir de son chapeau, il est parfaitement compréhensible que les promoteurs de Wayland ce soient tous braqués.
            Canonical a fait des efforts (et continue d'en faire) pour ouvrir d'avantage Mir. Mais le mal a été fait. Reste à espérer que le temps rapprochera tout ce beau monde.

            • [^] # Re: Waylands et Mir ?

              Posté par  (site web personnel) . Évalué à 9.

              Au fait, ma mauvaise opinion sur « les Waylands » vient principalement de cet article + commentaires : http://smspillaz.wordpress.com/2012/12/24/sideways/ (il travaillait chez Canonical à l'époque, Mir était un POC en interne et son adoption n'avait pas encore été décidée). Le fait que le scénario du pire (les Waylands donc) ce soit réalisé est celon moi l'une des raison qui ont fait perdre la foi en Wayland chez Canonical. C'est pour ça que j'essaye de comprendre.

              Je ne vois pas bien où est-ce qu'il a perdu la foi vu qu'il recommande justement de tout mettre dans Weston. C'est très bien, personne n'as dit que si Weston était suffisant pour la plupart des gens alors il fallait nécessairement coder un autre compositeur. Si Weston est assez complet ou personnalisable il deviendra le compositeur par défaut.

              Il n'as pas envie de porter compiz pour Wayland parce qu'il trouve que Weston fait déjà le boulot. Tout le monde est content !

              Encore une fois, le compositeur alternatif dont on parle le plus est Kwin, et il a plusieurs très bonnes raisons d'exister :
              - Tout le code de gestion de fenêtre et de composition est déjà là. La partie jugée difficile par le mainteneur de compiz n'est justement pas mise à la poubelle, elle est réutilisée pour Wayland.
              - L'objectif est de conserver une seule base de code au niveau du compositeur/gestionnaire de fenêtre entre Xorg et Wayland. Encore un objectif louable, on pourra tester les deux versions sur une même machine, changer si l'un plante pour une raison ou une autre.

              En ce qu'il s'agit de GNOME, je crois que le travail des développeurs parle de lui même (http://lwn.net/Articles/558879/) : ils intègrent leurs outils progressivement. Je n'ai pas encore entendu parlé d'un compositeur spécial GNOME même si des POC on été réalisés (https://wiki.gnome.org/Wayland/GnomeShell).

              Pour Enlightenment, ils vont faire leur propre compositeur apparemment. Position que l'on peut tout à fait comprendre puisque leur objectif annoncé est l'embarqué. Ils n'ont donc pas nécessairement besoin de tout ce qui est dans Weston. Je ne connais pas l'état d'avancement du projet.

              Le débat Mir/Wayland n'est actuellement pas objectif.

              Le débat sur les licences est des plus objectifs selon moi : http://mjg59.dreamwidth.org/25376.html. Tant que l'on aura ce genre de comportement on pourra difficilement parler d'ouverture.

              La description des avantages techniques de Wayland le semble aussi : http://blog.martin-graesslin.com/blog/2013/05/mir-in-kubuntu/ && http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=1. Si ces liens contenant majoritairement des arguments techniques ne sont pas "objectifs", je ne sais pas ce qu'y l'est.

              Je n'ai pas encore trouvé un seul article techniquement pertinent sur les avantages de Mir. Toute la communication de Mark Shuttleworth est basée sur des "buzz word". Toutes les remarques "techniques" des développeurs de Mir se sont fait sévèrement critiquées, et la première chose que l'on a appris lorsque Mir a été annoncé, c'est que ses développeurs ne comprenaient pas comment marchait Wayland. C'est donc un bon début pour le critiquer…

    • [^] # Re: Waylands et Mir ?

      Posté par  . Évalué à 7.

      Il me semble que KDE et Gnome ont eux aussi prévu d'utiliser un compositeur système pour gérer les sessions, ce qui implique de lancer le compositeur en question bien avant l'écran de login.

      Le compositeur systeme est quelque chose encore en debat. Il introduit des problemes de performance qu'on ne sait pas encore comment resoudre. Le principal probleme etant sur les inputs. Toutes les entrees/sorties devant etre controle par le compositeur systeme. Ca rajoute un process qui doit etre reveille et traverse avant, soit de pouvoir envoyer une action d'un peripherique vers le compositeur du desktop en cour, soit de pouvoir envoyer un buffer a l'ecran. Cela a un impact non negligeable et pas forcement utile au final. Pourquoi faut-il payer le prix chere pour si peu ?

      Pour plus de lecture sur le sujet, je conseille cet excellent blog : https://dvdhrm.wordpress.com/2013/07/08/thoughts-on-linux-system-compositors/ .

      Pour cette raison, entre autre, j'ai du mal comprendre pourquoi Wayland demande à tout le monde de ré-implémenter son propre compositeur. De ce point de vue, l'approche Mir qui consiste à séparer l'implémentation du bureau du serveur d'affichage avec une couche de glue entre les deux me parait être conceptuellement plus intelligente. C'est certes plus proche de l'infrastructure X actuelle, mais ça permet de factoriser beaucoup de code entre les DE (car oui, Mir en lui même n'est absolument pas spécifique à Unity, Canonical à même proposé son aide pour porter les autres shells).

      Tout le monde reimplemente deja son propre compositeur. KWin, Compiz, Enlightenment, … Tous les desktops un peu moderne ont deja se code. Et pour certain sont plus rapide que le code du compositeur se trouvant dans X ! Chacun utilise aussi un toolkit different et donc il n'y a que tres peu de code factorisable.

      Le but de Weston est de fournir une implementation de reference pour Wayland, mais aussi de fournir un ensemble de bibliotheque agnostique du compositeur et de les maintenir pour le benefice de tout le monde. L'approche de Wayland permet d'avoir le maximum de performance possible tout en factorisant le code qui peut l'etre.

      Mir de son cote ne travaillant pas du tout avec la communaute, il n'y a aucun travail reel de factorisation. C'est juste un decoupage arbitraire entre Unity et Mir qui est mis en place. Sans compter que je ne pense pas qu'ils ont les connaissance de l'ensemble de la communaute travaillant sur Wayland pour faire un compositeur aussi performant.

      Par exemple, si je ne m'abuse, quand les pilotes proprios vont supporter Mir, c'est bien chaque compositeur Wayland qui va devoir se rendre compatible indépendamment.

      Euh non, Wayland s'appuie sur KMS/DRM, rien de folklo la dedans, rien de specifique pour des pilotes proprios. Il est apres possible d'utiliser des implementations differente pour contourner des drivers proprio ou mal goupille, RPi et Android principalement, mais Mir fait exactement la meme chose. Aucune difference technique entre les deux de ce cote la.

      Bref, je suis assez pessimiste sur l'avenir de tout ça et j'ai besoin d'être rassuré par des gens qui s'y connaissent.

      T'inquiete pas. Oublie Mir. Change de distro si tu utilises Ubuntu, car ils ne travaillent pas avec la communaute et essaye de construire leur propre ecosysteme controle comme Android. Ils sont en marche pour faire un Ubuntu/Linux… sans grand interet pour la communaute !

      • [^] # Re: Waylands et Mir ?

        Posté par  . Évalué à 1.

        Euh non, Wayland s'appuie sur KMS/DRM, rien de folklo la dedans, rien de specifique pour des pilotes proprios.

        Tu n'as pas compris ce que je voulais dire.

        Il est apres possible d'utiliser des implementations differente pour contourner des drivers proprio ou mal goupille, RPi et Android principalement

        Ces implémentations vont devoir être faites. Ceux qui espèrent encore pouvoir fournir un compositeur Wayland sans support des pilotes proprios ne souhaitent simplement pas toucher le grand public.
        Ma question était : est-ce que ce support devra être implémenté séparément dans chaque compositeurs Wayland ?

        Si oui, je persiste à dire que c'est ultra casse gueule.

        Mir fait exactement la meme chose. Aucune difference technique entre les deux de ce cote la.

        Il y a un compositeur Mir que tout le monde est sensé utilisé en rajoutant juste la partie Shell.
        Il y a une multitude de compositeurs Waylands qui semblent chacun réinventer une partie de la roue.

        T'inquiete pas. Oublie Mir. Change de distro si tu utilises Ubuntu, car ils ne travaillent pas avec la communaute et essaye de construire leur propre ecosysteme controle comme Android. Ils sont en marche pour faire un Ubuntu/Linux… sans grand interet pour la communaute !

        Tu devrais t'intéresser à la communauté Ubuntu avant de porter de tels jugements ;)
        (ok, c'est trolldi, donc tu es pardonné)

        • [^] # Re: Waylands et Mir ?

          Posté par  . Évalué à 6.

          Ma question était : est-ce que ce support devra être implémenté séparément dans chaque compositeurs Wayland ?

          Il y a des rumeurs qui disent que nvidia va sortir une interface EGL à son pilote proprio, comme ça ça sera la même interface que les pilotes libres.

          Il y a un compositeur Mir que tout le monde est sensé utilisé en rajoutant juste la partie Shell.

          Et si l'architecture est pourrie ? Par exemple, je doute que chez Enlightment, ils trouvent que ça corresponde à leurs standard. Si ça utilise Qt ou GTK, ça ne va pas plaire aux développeurs KDE/Gnome et si ça ne les utilise pas, c'est dommage de réinventer la roue.

          Et s'il manque des fonctionnalités ? Par exemple, les développeur de Kwin on prévu des extension pour des trucs spécifique KDE (tout en permettant d'utiliser un autre compositeur Wayland avec des fonctionnalités en moins)

          De plus, il me semble que la partie compositeur est assez légère et comme plusieurs bibliothèques de Weston peuvent être partagée, la partie « réinvention de la roue » est assez réduite.

          « 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: Waylands et Mir ?

            Posté par  . Évalué à 0.

            Il y a des rumeurs qui disent que nvidia va sortir une interface EGL à son pilote proprio, comme ça ça sera la même interface que les pilotes libres.

            EGL est une condition nécessaire mais pas suffisante.
            La preuve, les pilotes Android fournissent aussi une interface EGL et il est pourtant impossible de faire fonctionner un Weston de base dessus (et Mir a dû implémenter une interface spécifique).

            Je m'avoue volontiers incompétent dans ce domaine, mais une chose est sûr : les divers compositeurs Wayland devront être adaptés pour supporter les pilotes proprios.
            S'il est possible de factoriser ce support dans la libwayland-server, tant mieux. Mais je n'ai pas l'impression que ça soit l'objectif.

            Et si l'architecture est pourrie ? Et s'il manque des fonctionnalités ?

            En effet, je ne parle que de théorie.
            Comme je l'ai dit plus haut, Canonical a lancé des efforts pour ouvrir le développement de Mir et donc pour permettre aux développeurs concernés de communiquer leurs besoins (oui, ça peut paraître ironique mais c'est bel et bien le cas).
            Je ne sais pas si ça va donner quelque chose. Probablement rien à court terme.

        • [^] # Re: Waylands et Mir ?

          Posté par  . Évalué à 4.

          Ces implémentations vont devoir être faites. Ceux qui espèrent encore pouvoir fournir un compositeur Wayland sans support des pilotes proprios ne souhaitent simplement pas toucher le grand public.
          Ma question était : est-ce que ce support devra être implémenté séparément dans chaque compositeurs Wayland ?

          Bah ça va aller dans la libwayland et puis basta ça fonctionne pour tout le monde.

          Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: Waylands et Mir ?

          Posté par  . Évalué à 8.

          Ma question était : est-ce que ce support devra être implémenté séparément dans chaque compositeurs Wayland ?

          Le support de ces divers drivers proprio n'est pas un code aussi complexe que tu le laisses entendre et encore moins un gros morceau de code. C'est juste de l'allocation de buffer et configuration des sorties, that's it ! Ca finira probablement dans une bibliotheque commune tout de meme, parce que les developpeurs sont faineant, mais pas vraiment parce que c'est un code complique ou toolkit dependant.

          Il y a un compositeur Mir que tout le monde est sensé utilisé en rajoutant juste la partie Shell.

          Mais biensur ! Donc je vais creer plein de fenetre supplementaire qui ne serve a rien pour mes menus, mon shelf et tout ce qui compose mon desktop. En terme d'optimisation, on repassera. La plus part des toolkits moderne ont deja un scenegraph et son capable de mettre toutes ces ressources graphiques dans le meme scenegraph au lieu d'etre force dans des fenetres separees. Bien entendu, ca aide…

          Sans compter que l'optimisation d'un scene graph, ca prend du temps et demande beaucoup d'experience avant d'avoir le niveau de performance necessaire. C'est sur on peut tout balancer a OpenGL et croire au pere noel. Mais si on veut des perfs, vaut mieux faire un peu de boulot avant. Je peux te prendre le paris que le scenegraph de Mir se fait juste enterrer par celui d'Enlightenment (meme probablement celui de Weston aussi) et maintenant va donc me justifier que je fairais mieux de l'utiliser.

          Contrairement a ce que tu penses les roues sont deja en place. C'est une competition de Formule 1 ou Wayland decrit les contraintes des voitures. Il n'y a pas de reinvention, juste un assemblage de piece deja existante et en general ce nouvel assemblage aide aussi a pousser a l'optimisation de la version X. D'ailleur Mir utilise les meme pieces de maniere general, sauf qu'il ne respecte pas les regles et a une approche aggressive envers la communaute.

          Tu devrais t'intéresser à la communauté Ubuntu avant de porter de tels jugements ;)

          Je parlais de la communaute des developpeurs, pas des trolleurs ! ;-)

          • [^] # Re: Waylands et Mir ?

            Posté par  . Évalué à 2. Dernière modification le 19 juillet 2013 à 13:43.

            Intéressant, merci.

            Tu sembles mieux t'y connaître que moi donc je ne vais pas te suivre dans ton pari. On aura bien vite l'occasion de comparer les benchs.

            De ce que j'ai cru comprendre, Mir implémente (ou va implémenter ?) un scenegraph générique en interne pour les shells basiques tout en fournissant une interface pour permettre au shell d'implémenter son propre scenegraph s'il le souhaite (ce qui sera le cas avec Unity 8). Je ne sais pas si ça peut t'aider dans ta réflexion :-)

            édit : c'est justement en cours de discussion sur mir-devel. Malheureusement l'archive web n'a pas l'air d'être à jour, du coup je ne peux pas te donner de lien.

            D'ailleur Mir utilise les meme pieces de maniere general, sauf qu'il ne respecte pas les regles et a une approche aggressive envers la communaute.

            avait une approche agressive ;)
            Depuis l'annonce on voit bien qu'ils ont essayé d'arrondir les angles. Trop tard ou pas, c'est un autre sujet.

            • [^] # Re: Waylands et Mir ?

              Posté par  . Évalué à 4.

              De ce que j'ai cru comprendre, Mir implémente (ou va implémenter ?) un scenegraph générique en interne pour les shells basiques tout en fournissant une interface pour permettre au shell d'implémenter son propre scenegraph s'il le souhaite (ce qui sera le cas avec Unity 8). Je ne sais pas si ça peut t'aider dans ta réflexion :-)

              Vu les differences entre les API des scenegraph de Qt et des EFL, j'ai bien du mal a voir comment ils vont pouvoir faire un truc generique de ce cote la. Semble etre une approche bien complique.

              avait une approche agressive ;)
              Depuis l'annonce on voit bien qu'ils ont essayé d'arrondir les angles. Trop tard ou pas, c'est un autre sujet.

              Je considere agressif une approche qui consiste a faire :
              - un code dump
              - calomnier des projets developpes par la communaute
              - forcer les developpeurs a ceder leur droit pour leur permettre de faire du proprio
              - faire des declarations peremtoires en lieu et place des developpeurs de logiciel libre dans lesquel Ubuntu ne contribue pas
              - faire croire que ce qui est fait, est fait pour des raisons techniques et ne pas etre franc sur ses objectifs reels (aka controle complet d'une stack Linux comme Android)

              Je ne vois pas trop ce qui s'est ameliore depuis le lancement public du projet, a part peut etre la correction des idioties concernant Wayland dans leur Wiki.

              • [^] # Re: Waylands et Mir ?

                Posté par  (site web personnel) . Évalué à 10.

                Je complète un peu un peu: La communauté des développeurs au sens large (X, Gnome, KDE, E, les differents "buntu"…) a compris que l'objectif de Mir est de rendre Ubuntu incompatible avec les autres distributions et/ou de les rendre marginale.
                par exemple:
                - Un stream compilé pour Mir sera incompatible avec les autres distributions. En faisant un travail de partenariat et d'exclusivité, ils marginalisent les autres.
                - Le duo attribution/GPL3 fait qu'un éditeur voulant éditer du propriétaire pour Ubuntu devra obtenir une licence spéciale de Mir: Il auront la main pour faire payer ou négocier une exclusivité.

                Après, pour pas trop passer pour des salauds, on fait de l'enrobage marketo-communautaire. Ex:
                - Justifications techniques foireuses démonté directement (pouquoi n'ont t'il pas vérifié aupres des développeurs wayland? pas un mail en 6 mois de développement sous le manteau?)
                - Des discutions avec la team Kubuntu qui cherche une solution et les développeurs Mir qui ne proposent aucune solutions réaliste ou acceptable.

                (presque) personne n'est dupe. Bientôt même ce sera Ubuntu les victimes pour les fanboys, on croit rêver…. C'est comme Apple, plus c'est gros, plus ça passe.

                Après, on peut dire que la communauté du dev libre voit le mal partout… mais il serait assez facile pour Ubuntu de démontrer qu'il n'ont pas cette volonté de contrôle… pas par des paroles creuse comme cette pseudo "aide" envers Kubuntu qui était d'un cynisme absolu, mais par des ACTES:

                • Fin de l'attribution des commits extérieur à Ubuntu
                • Pas de GPLV3 uniquement, afin d'être compatible avec les autres environnement
                • Travail/contribution upstream des patchs pour Qt, Gtk, … avec détection au runtime, afin qu'un soft Qt/Gtk/EFL déjà compilé puisse tourner sous Wayland ou Mir.
                • Dans la même veine, développement d'un WaylandMir et d'un MirWayland
                • Mise en place d'un protocole pour pas qu'un compositeur différent d'Unity soit cassé tout les quatre matins à chaque mise à jour système.

                Mais les actes, on est pas prêt de les voir… les faux semblant par contre, c'est pas fini… Et quand viendront les problèmes, je suis certain qu'il rejetteront la faute sur les autres pour se dédouaner.

                Après, on peut penser que c'est une bonne chose qu'il ne reste qu'un seul bureau libre (Unity) et qu'une seule distrib (Ubuntu) sur le marché du desktop. Le tout avec un store payant comme Android.
                Mais prendre autant les gens pour des cons [dont les dev qui fabriquent l'essentiel de la logithèque du "store"], c'est vraiment énervant.

                • [^] # Re: Waylands et Mir ?

                  Posté par  . Évalué à -1.

                  Fin de l'attribution des commits extérieur à Ubuntu

                  On ne va pas refaire ce débat, mais j'imagine que tu sais qu'il y a du pour et du contre sur cette mesure.

                  Pas de GPLV3 uniquement, afin d'être compatible avec les autres environnement

                  Mir a aussi du code LGPL (part qui est amenée à grossir vu le futur besoin de supporter les pilotes proprio).

                  Travail/contribution upstream des patchs pour Qt, Gtk, … avec détection au runtime, afin qu'un soft Qt/Gtk/EFL déjà compilé puisse tourner sous Wayland ou Mir.

                  Vu que l'ensemble est encore en développement, j'imagine qu'il ne faut pas s'attendre à ce que les patchs soient proposés avant la stabilisation des API en octobre.

                  Dans la même veine, développement d'un WaylandMir et d'un MirWayland

                  Quel intérêt ? Il restera toujours X en point commun entre les deux.

                  Mise en place d'un protocole pour pas qu'un compositeur différent d'Unity soit cassé tout les quatre matins à chaque mise à jour système.

                  La compatibilité de l'API de la libmirserver sera maintenue à partir d'octobre (première version de Mir en production).

                  Après, on peut dire que la communauté du dev libre voit le mal partout

                  C'est entièrement de la faute de Canonical si Mir est parti sur un si mauvais pied vis à vis de la communauté.
                  Maintenant il faut aussi essayer d'analyser la situation plus pragmatiquement sans sombrer dans la paranoïa.

                  Objectivement, Canonical a fait des pas dans la bonne direction en offrant de la documentation et en tentant d'ouvrir des discussions constructives avec les personnes potentiellement concernées par Mir (il y a un type de chez Fedora qui passe de temps en temps pour demander de rajouter des trucs dans la doc, il y a des paquets Mir dans Arch Linux…)

                  Ni Mir ni Wayland ne vont disparaître avant un bon bout de temps. Qu'on se le dise.
                  Maintenant il faut apprendre à coexister pour éviter les problèmes de compatibilités que tu évoques et que personne ne souhaite.

                  • [^] # Re: Waylands et Mir ?

                    Posté par  (site web personnel) . Évalué à 6.

                    Plutôt que de traiter la communauté Gnome/KDE/… et moi même de paranoïaque, tu n'aura qu'a ressortir mon message dans 5 ans (et on verra au passage, si dans 5 ans, les applications Mir pourront s'exécuter dans Wayland via XWayland de manière fiable). On verra bien si l'incompatibilité n'est pas voulu.

                • [^] # Re: Waylands et Mir ?

                  Posté par  . Évalué à 4.

                  Le tout avec un store payant comme Android.

                  La grande majorité des applications ne sont pas payantes, et Libre ne veut pas dire gratuit.

                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                • [^] # Re: Waylands et Mir ?

                  Posté par  . Évalué à 5.

                  Travail/contribution upstream des patchs pour Qt, Gtk, … avec détection au runtime, afin qu'un soft Qt/Gtk/EFL déjà compilé puisse tourner sous Wayland ou Mir.

                  GTK et Qt sont calculés pour supporter plusieurs backend sans avoir à recompiler les programme. A priori, on aura pas à recompiler les programmes pour faire tourner sous Wayland, X11 ou même Mir.

                  Dans la même veine, développement d'un WaylandMir et d'un MirWayland

                  Ce n'est pas exclu, mais pas gagné non plus:

                  However, Wayland support could be added either by providing a Wayland-specific frontend implementation for our display server or by providing a
                  client-side implementation of libwayland that ultimately talks to Mir.

                  Référence: https://wiki.ubuntu.com/Mir/Spec

                  Même s'il est possible d'obtenir une relative compatibilité entre les environnements, ça me semble en beaucoup d'énergie dépensée pour rien.

                  • [^] # Re: Waylands et Mir ?

                    Posté par  . Évalué à 10.

                    Travail/contribution upstream des patchs pour Qt, Gtk, … avec détection au runtime, afin qu'un soft Qt/Gtk/EFL déjà compilé puisse tourner sous Wayland ou Mir.

                    GTK et Qt sont calculés pour supporter plusieurs backend sans avoir à recompiler les programme. A priori, on aura pas à recompiler les programmes pour faire tourner sous Wayland, X11 ou même Mir.

                    Je ne vais parler que pour les EFL, car c'est ce que je connais. Les porter sur un nouveau backend, se fait tres rapidement. En une semaine, tu as un truc qui pousse des pixels a l'ecran (Le port initial de Wayland a literalement pris 2 jours pour avoir une fenetre qui s'affiche a l'ecran avec le bon contenu).

                    Mais et c'est la que commence les joyeusetes, si tu veux un port efficace, tu dois rajouter de plus en plus de chose. Support du double et triple buffer, mise a jour partiel de l'ecran, support des sub-surface, minimisation des discussion entre le client et le serveur, suivit des changements upstream, … Et ca, c'est de la maintenance qui occupe une personne presque a plein temps depuis un an ou deux (Pour X, meme apres 10 ans, le backend EFL recoit toujours des ameliorations). Ca, ca a un cout. Et il faut soit des personnes motives, soit qu'une societe paye une personne pour le faire.

                    Une strategie de fire and forget permet d'avoir une demo rapidement qui marche, mais ne permet pas du tout d'avoir une solution competitive. Cela veut dire que les toolkits utilisaient sur une tel plateforme seront plus lent, plus lourd et plus consommateur d'energie que si ils etaient utilise dans un environnement ou l'upstream fait la maintenance.

            • [^] # Re: Waylands et Mir ?

              Posté par  . Évalué à 2.

              avait une approche agressive ;)
              Depuis l'annonce on voit bien qu'ils ont essayé d'arrondir les angles. Trop tard ou pas, c'est un autre sujet.

              (Mark Shuttleworth, 11 Juil.) Finally, yes, I think Wayland is repeating the mistakes of X, and I would like to have a fast, lean, clean option that does not.
              http://www.markshuttleworth.com/archives/1269#comment-402807

              Tu disais ?

              C'est assez marrant sachant que Mir reprend entre autres l'une des plus grosses tares de X qui est l'allocation des buffers côté serveur. Je n'arrive pas à retrouver le lien d'un dev Xorg qui en parle justement…

              • [^] # Re: Waylands et Mir ?

                Posté par  . Évalué à 2.

                Et bien techniquement moi je ne comprends pas comment ça peut marcher l'allocation des buffers côté client:un buffer c'est forcément gérer de manière centralisée non?

                • [^] # Re: Waylands et Mir ?

                  Posté par  . Évalué à 6.

                  Pourquoi pas ? Où est le problème à ce qu'une application crée son propre buffer graphique et dessine sa fenêtre tout seule comme une grande puis passe le pointer au Compositor ?
                  L'un des soucis majeurs de l'allocation côté serveur c'est le nombre de roundtrips inutiles client-serveur vu que l'application doit sans cesse demander un nouveau buffer de telle taille au serveur. Je te laisse imaginer le nombre d'IPCs à chaque redimensionnement de fenêtre en plus du fait que le client doit toujours attendre la réponse du server avant de pouvoir dessiner. Un problème autre que la lenteur c'est que X ne peut jamais savoir quelle taille la fenêtre du client sera à t+1, et devra attendre la requête du client pour le savoir, et le temps que le client obtienne son buffer il est souvent déjà invalidé. C'est la source des soucis de corruption/clignotement dans les fenêtres lors de redimensionnements par exemple…

                  En résumé ça fait 30 ans que les devs X se pètent les dents là dessus; Windows et OSX ayant définitivement enterré l'idée y'a très longtemps aussi. Ça avait peut être du sens quand X se chargeait lui-même de dessiner les fenêtres, mais maintenant à part les rares applis en Motif et xterm toutes les applis/toolkits font leur rendu localement. X est aussi sur cette voie vu que DRI2 autorise déjà partiellement le client-side allocation. DRI3000 va plus loin dans ce sens en étant full client-side ( http://keithp.com/blogs/dri3k_first_steps/ ).

                  Après, le client-side à ses défauts aussi comme un moindre contrôle sur les buffers (genre on peut plus désallouer aussi facilement un buffer pour une appli qui est minimisée pour libérer de la mémoire) et donc une consommation en RAM plus conséquente, ce qui peut être une contrainte sur les mobiles/tablettes. C'est la justification de Canonical en tout cas, bien que à mon avis fallacieuse vu que Wayland ne force pas l'allocation client (y'avait même un Weston expérimental en server-side), et que la quantité de RAM des mobiles ne cesse d'augmenter…

                  Maintenant Mir heureusement fait les choses un peu différemment de X et évite quelques allers-retours inutiles ( http://blog.cooperteam.net/2013/03/server-allocated-buffers-in-mir.html ), mais techniquement il y aura toujours un avantage au client-side niveau vitesse en tout cas.

                  • [^] # Re: Waylands et Mir ?

                    Posté par  . Évalué à -3.

                    Wayland ne force pas l'allocation client (y'avait même un Weston expérimental en server-side)

                    Si je ne m'abuse, ça réclame des changements dans la libwayland-client.
                    D'où risque d'incompatibilité entre les implémentations (si Kwin avait décidé de faire du server side et Gnome-shell du client side ?)

                    Dans ce cas, on est plutôt content que Mir ai sa propre plateforme plutôt qu'ils en aient fait un compositeur Wayland, non ?

                    • [^] # Re: Waylands et Mir ?

                      Posté par  . Évalué à 7. Dernière modification le 20 juillet 2013 à 11:53.

                      00:35 daniels: fwiw, i've got a wayland backend for arm hardware which does server-side allocation right now. didn't require one single change to any of the clients, or even compositors. it's all internal to the egl stack.

                      Donc non.
                      Et puis Mir fragmente tout l'écosystème (toolkits, compositors, drivers…), pas seulement quelques "implémentations", tout ça pour aucune raison technique valable mis à part le contrôle complet du stack…

                • [^] # Re: Waylands et Mir ?

                  Posté par  . Évalué à 3.

                  Oui, sauf qu'avec GEM (Graphics Execution Manager) c'est le noyau qui centralise la gestion de l'allocation.
                  Pour l'appli utilisant libwayland-client, elle n'a pas à savoir si l'allocation est server-side ou client-side et on pourrait donc étendre le protocole Wayland pour autoriser l'allocation client-side sans avoir à modifier les appli.

              • [^] # Re: Waylands et Mir ?

                Posté par  . Évalué à 3.

                L'avis personnel de Mark n'est pas représentatif de l'ensemble de la communauté Ubuntu.

                • [^] # Re: Waylands et Mir ?

                  Posté par  . Évalué à 5. Dernière modification le 20 juillet 2013 à 10:31.

                  C'est pas faux. Malheureusement c'est pas "l'ensemble de la communauté Ubuntu" qui prend les décisions à propos de Mir ou des relations avec l'upstream/Wayland…

                  • [^] # Re: Waylands et Mir ?

                    Posté par  . Évalué à 0.

                    Et, comme expliqué précédemment, ce n'est pas faute de tendre la main (tardivement, certes).

                    • [^] # Re: Waylands et Mir ?

                      Posté par  . Évalué à 3.

                      Et, comme expliqué précédemment, ce n'est pas faute de tendre la main (tardivement, certes).

                      Tu devrais lire la mailing list d'Ubuntu au sujet du support des non-Unity histoire de revoir ta définition de "tendre la main".
                      En résumé ça donne ça :
                      "Bon ben voilà soit vous acceptez que KDE/XFCE/etc… soit exécuté sur une couche XMir sur Mir avec toute la lenteur, les bugs que ça apporte et le gain non-existent soit démerdez-vous, car nous notre stack Mesa/EGL et les drivers seront patchés uniquement pour Mir et on a aucunement l'intention de supporter Wayland sur Ubuntu."

                      • [^] # Re: Waylands et Mir ?

                        Posté par  . Évalué à 1.

                        Je t'invite à relire cette discussion car ce n'est pas ça qui a été dit.

                        Ubuntu contiendra toujours Mesa et tout ce qui en découle. Ce qui veut dire que les API nécessaires à tout compositeur Wayland seront présentes dans Ubuntu tels quelles sont fournies par upstream.

                        Ce qui a été dit c'est que Canonical va progressivement arrêter de développer des patchs pour X et que, à terme, leur but est de juste synchroniser X depuis Debian.
                        Au passage, ils doivent être content les gens de Debian de voir le peu d’enthousiasme que cette perspective donne aux gens de Kubuntu. D'ailleurs ils se contredisent puisque dans les échanges sur la mailing-list ils se plaignent de la mauvaise qualité des patchs de Canonical (tout en étant strictement incapable de citer le moindre rapport de bug pour appuyer leurs dires).

                        Avant, Canonical faisait le nécessaire pour que X fonctionne bien sur une large palette de matériel. Les autres DE pouvaient juste installer leurs paquets au dessus et ça marchait.
                        Ce ne sera plus le cas avec Mir. Et, encore une fois, je ne suis pas certain que la situation aurait été bien différente pour eux si Mir parlait Wayland.

                        Donc voila.
                        Sachant que les dérivés veulent toujours profiter du travail fait dans Ubuntu, les développeurs ont proposé deux choses :

                        • On aide les dérivés intéressés à passer sur Xmir, ce qui permet de profiter de tout le support matériel fournis par Canonical sans avoir besoin de modifier le code de leur DE
                        • On aide les Upstream qui le souhaite à rendre leur DE compatible Mir « nativement » (projet à plus long terme, mais qui permet toujours de se reposer sur le travail de Canonical tout en se passant de X)

                        Rien n'empêche les dérivés de continuer d'utiliser un X nature ou d'utiliser Wayland. La libwayland est dans la section main d'Ubuntu, GTK+ est compilé avec le support Wayland depuis un certain temps…

                        C'est juste qu'ils ne peuvent pas avoir le beurre et l'argent du beurre.

                        Il faut vraiment arrêter de voir Canonical comme le grand méchant dont le seul but dans la vie est de détruire la communauté. Ça ne résiste simplement pas aux faits.

  • # Et compiz ?

    Posté par  . Évalué à 2.

    Je suis un peu perdu sur Wayland/Weston, malgré les nombreux articles et les efforts pour expliquer les avancées de ces projets.

    Je n'utilise que Compiz comme compositeur et gestionnaire de fenêtre (emerald) - ni Gnome, ni surtout KDE.

    De ce que je comprends Wayland va réutiliser les driver DRI d'Xorg, donc question performance il y a de bonnes chances que ce soit strictement identique à ce que j'avais avec Xorg. Puisque ce sont surtout des drivers graphiques que dépend la performance du compositeur - et d'ailleurs c'est ce que j'en déduis du bricolage de Collabora sur le Raspberry Pi : si le videocore avait eu un driver libre le problème n'aurait pas existé… ( David Braben si tu nous lis sache que la boîte de Frontier Elite est sous cadre et vénérée comme une idole chez moi, je ne peux donc pas dire du mal du Pi, mais quand même ce videocore… argh… ).

    Je ne sais pas si Compiz supportera Wayland, mais de ce que j'en comprends c'est Weston qui semble être le compositeur autonome appelé à remplacer Compiz puisqu'il a la bonne idée d'avoir un gestionnaire de fenêtre intégré ( j'ai longtemps eu un gros doute à ce sujet ). Je me doute bien que Weston doit être à l'heure actuelle à des années lumières de la richesse de configuration de Compiz.

    J'ai bon ?

    • [^] # Re: Et compiz ?

      Posté par  . Évalué à 3.

      De ce que je comprends Wayland va réutiliser les driver DRI d'Xorg, donc question performance il y a de bonnes chances que ce soit strictement identique à ce que j'avais avec Xorg.

      Il y a un peu moins d'IPC car le serveur d'affichage intègre plus de truc et est moins modulaire donc il devrait y avoir un léger gain de ce coté là en local, mais sinon oui.

      Après pour ce qui est de la performance perçue, il y aura quelques changements:
      -avec Weston pas de tearing, mais un lag au cas ou l'application est lente a redimensionner la fenêtre
      -déplacer une fenêtre devrait être très fluide (faite uniquement dans le serveur).

      Je ne sais pas si Compiz supportera Wayland,

      Je crois que non.

      de ce que j'en comprends c'est Weston qui semble être le compositeur autonome

      Pas sûr, Weston est vu pour le moment comme un prototype..

      • [^] # Re: Et compiz ?

        Posté par  . Évalué à 2.

        Merci, c'est à peu près la conclusion à laquelle j'étais arrivé : Weston n'est en aucune mesure au niveau de Compiz-fusion en terme de fonctionnalités et de stabilité, Wayland n'apporte quasiment pas de progrès au niveau de la composition 3D et Compiz-fusion ne supporte pas Wayland.

        Il est par conséquent urgent d'attendre :-)

        • [^] # Re: Et compiz ?

          Posté par  . Évalué à 3.

          Merci, c'est à peu près la conclusion à laquelle j'étais arrivé : Weston n'est en aucune mesure au niveau de Compiz-fusion en terme de fonctionnalités et de stabilité,

          En même Weston c'est juste un code d'exemple qui n'a absolument rien à voir avec Compiz.

          Wayland n'apporte quasiment pas de progrès au niveau de la composition 3D

          Plus de performances.

          et Compiz-fusion ne supporte pas Wayland.

          Et il ne le supportera jamais d'après ce que j'ai lu (mais ça fonctionnera très bien avec XWayland).

          Il est par conséquent urgent d'attendre :-)

          En même temps vu qu'il n'est déployé null part t'as pas trop le choix… :)

          Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: Et compiz ?

            Posté par  . Évalué à 1.

            Plus de performances.

            Mouais… et encore pas certain… pour l'instant les benchmarks plus haut parlent de 2D, pas d'OpenGL/OpenCL/Gallium3D etc etc…

            Je demande à voir les %CPU et %GPU lors de l'affichage et à vérifier que Wayland utilise massivement moins le CPU et massivement plus le(s) GPU(s).

            • [^] # Re: Et compiz ?

              Posté par  . Évalué à 1.

              J’avoue je n’ai pas de valeurs. Mais de la façon dont Wayland est conçu, il est plus performant que X.org. L’avenir nous dira à quel point.

              Écrit en Bépo selon l’orthographe de 1990

            • [^] # Re: Et compiz ?

              Posté par  . Évalué à 4.

              Mouais… et encore pas certain… pour l'instant les benchmarks plus haut parlent de 2D, pas d'OpenGL/OpenCL/Gallium3D etc etc…

              Pourquoi différencier la 2D et OpenGL ? OpenGL, peut très bien être utilisé pour accélérer la 2D, c'est d'ailleurs très utilisé pour ça par les compositeurs sous X.

              « 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: Et compiz ?

                Posté par  . Évalué à -1.

                Tout à fait. Et c'est le cas sur compiz-fusion il me semble.

                En fait la seule chose que je reproche à Xorg actuellement, même en utilisant compiz-fusion, c'est d'exploiter encore beaucoup trop le CPU. Pour moi TOUT l'affichage ne devrait faire intervenir QUE le GPU.

                Je n'ai pas l'impression que Wayland fasse un grand pas en avant dans cette direction.

                En fait à moins de lancer un calcul de tableau croisés dynamique sous Excel ou une compilation en C mon CPU devrait être à… 0%.

                Et d'ailleurs même pour les tableurs ce n'est plus si sûr…

                • [^] # Re: Et compiz ?

                  Posté par  . Évalué à 3.

                  Je n'ai pas l'impression que Wayland fasse un grand pas en avant dans cette direction.

                  Ah? Pourtant pour moi justement Wayland vise à maximiser l'utilisation possible du GPU..

              • [^] # Re: Et compiz ?

                Posté par  . Évalué à 4.

                OpenGL, peut très bien être utilisé pour accélérer la 2D, c'est d'ailleurs très utilisé pour ça par les compositeurs sous X.

                C'est bien parce qu'on n'a pas le choix. Mais on torture franchement cette API et son modele de rendu pour faire de la 2D efficace avec. C'est a la limite du supplice chinois, j'aimerais pas etre a sa place !

            • [^] # Re: Et compiz ?

              Posté par  . Évalué à 1.

              OpenCL ! c'est quoi le rapport avec un système graphique ?

        • [^] # Re: Et compiz ?

          Posté par  . Évalué à 9.

          Wayland n'apporte quasiment pas de progrès au niveau de la composition 3D

          Oh que si, et énormément. Le compositing sous X est probablement l'une des pires choses qui soit.
          Tu n'imagines même pas le nombre de roundtrips et context switches à la con il faut just pour redimensionner une fenêtre sous X. Car depuis l'avènement des Compositeurs, et le fait que de plus en plus de fonctions de X sont déléguées au Compositeur ou vers le noyau (KMS, evdev…), X ne sert quasiment plus à rien et n'est qu'un boulet inutile entre le Compositeur et les applications. Sous Wayland, le Compositeur gère directement les fenêtres et le GPU sans intermédiaire inutile ce qui fait gagner un temps fou et évite les copies inutiles.
          Je te conseille de voir cette excellente conférence de Daniel Stone pour vraiment te rendre compte à quel point X est complètement obsolète et surtout du temps de la Composition notamment : http://www.youtube.com/watch?v=RIctzAQOe44

  • # Clavier / xkb

    Posté par  . Évalué à 5. Dernière modification le 18 juillet 2013 à 17:09.

    • Wayland fonctionne avec libxkbcommon. Est-ce que cela signifie que Wayland sera compatible avec les outils de configuration xkb pour X.org ?

    • Quelle sera la liste des keysyms reconnue par Wayland ? Actuellement X.org (et xmodmap) reconnaissent une certaine liste de keysyms. Cette liste est certes longue mais très lacunaire par rapport aux standards modernes (unicode). Est-ce que Wayland offre la compatibilité des caractères de x.org, ou bien est-ce qu'il permet d'assigner n'importe quel caractère unicode à une touche du clavier ?

    • [^] # Re: Clavier / xkb

      Posté par  . Évalué à 6.

      Wayland fonctionne avec libxkbcommon. Est-ce que cela signifie que Wayland sera compatible avec les outils de configuration xkb pour X.org ?

      Normalement oui, ils ne refont que la partie serveur d’affichage et tout ça.

      Quelle sera la liste des keysyms reconnue par Wayland ? Actuellement X.org (et xmodmap) reconnaissent une certaine liste de keysyms. Cette liste est certes longue mais très lacunaire par rapport aux standards modernes (unicode). Est-ce que Wayland offre la compatibilité des caractères de x.org, ou bien est-ce qu'il permet d'assigner n'importe quel caractère unicode à une touche du clavier ?

      Ça non plus ça ne devrait pas changer mais il est possible de mettre n’importe quel symbole Unicode en mettant U suivie du code du caractère.

      Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: Clavier / xkb

      Posté par  . Évalué à 4.

      Actuellement X.org (et xmodmap) reconnaissent une certaine liste de keysyms. Cette liste est certes longue mais très lacunaire par rapport aux standards modernes (unicode). Est-ce que Wayland offre la compatibilité des caractères de x.org, ou bien est-ce qu'il permet d'assigner n'importe quel caractère unicode à une touche du clavier ?

      Avec xkb sous Xorg on peut déjà assigner n'importe quel caractère unicode à une touche de clavier. Voici un extrait de la configuration xkb de mon clavier :
      key {
      [ U0924, U0925, U091F, U0920 ]
      };

      UXXXX représente bien entendu le caractère unicode U+XXXX.

      • [^] # Re: Clavier / xkb

        Posté par  . Évalué à 4.

        Merci beaucoup, je ne savais pas et je luttais avec la liste fixe que je connaissais.

  • # Multipostes

    Posté par  . Évalué à 3.

    Postes de travail multiples et gestion des entrées: La gestion des entrées est maintenant complète. Celle-ci permet d'avoir plusieurs périphériques (claviers, souris ou écrans) sur une même unité centrale, avec un utilisateur devant chaque écran. La gestion des systèmes d'entrée sont différenciées et permet de créer de nouvelles entrées à chaud.

    Youhou !!!! Ça fait un moment que je suis utilisateur de ce type de solution et avec X ce n'est pas forcement la joie tous les jours. Donc je suis preneur de tout amélioration dans ce domaine. Je pense que je vais me monter une petite machine virtuelle pour me faire la main dessus avant de passer aux choses sérieuses

  • # Rebecca Black OS

    Posté par  (site web personnel) . Évalué à 1.

    J'ai testé le dernier live-CD de Rebecca Black OS, et j'ai l'impression qu'il ne fonctionne pas comme prévu chez moi…

    Au boot, j'arrive sur un écran avec une barre en haut, et les boutons « Login », « Switch User » et « Shutdown ».

    Et à part ça, je ne peux rien faire, rien lancer d'autre. Lorsque j'ouvre une session, je reviens sur cet écran (comme si ça avait crashé).

    Est-ce que quelqu'un a essayé et a une autre expérience que moi ? J'ai une carte intel intégrée (i945 GM).

    • [^] # Re: Rebecca Black OS

      Posté par  (site web personnel) . Évalué à 3.

      La version du 13 Juillet faisait ça systématiquement. La suivante corrige cela mais cela dépend du matériel/driver.
      Tu es sensé avoir un bouton menu et des raccourcis d'applis en haut (une fois la session ouverte).

      Perso, c'est nickel avec une Intel HD3000 (Core i5) mais toi tu dois avoir un problème avec tes drivers, ou lié à l'intégration de la distrib qui est très artisanale (j'ai prévenu dans la news ;).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.