Journal Wayland, l'obsession éternelle du carré blanc

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
31
23
mar.
2025

Hello nal,

Comme je reviens un peu dans le monde du rendu graphique, je me suis dit que j'allais me remettre à jour sur le système d'affichage de notre OS favori.

Ce qui m'avait frappé dans les tutoriaux X de la grande époque, c'était la simplicité du tout début. Créer un carré blanc avec une barre de titre ? Morceau de cake !

X11 window

Alors après bizarrement, dés qu'on voulait aller plus loin, ça devenait compliqué…

  • Rajouter/enlever un bouton dans la barre de titre, ou plus largement discuter avec le gestionnaire de fenêtres ? -> apprendre un pavé de 500 pages sur les Atoms ICCM X11. Et tester ça partout -car la moitié des window managers ne respectent pas la norme et le code finira rempli de "#ifdef GNOME" (vécu 😉) ;
  • Afficher des widgets ? -> choisir son toolkit. Et réaliser que ce faisant on n'aura plus jamais besoin de X11, car ses concepts sont tellement datés que le toolkit non seulement les wrappe, mais dessine sans utiliser les antiques Pixmaps, XFonts… dont le tutorial ci-dessus parle encore.

Bon là je divulgâche : la suite ne vas pas être si différente, à la fin. Mais au début si ! Car la base système d'affichage a changé, c'est désormais Wayland.

Et ce qui lui manque à lui, à mon sens, c'est la manière la plus courte d'arriver à ça:

Wayland window

…et aussi d'ajouter des choses, car les exemples ailleurs sont "atomisés" -ils sont pas directement comparables, on n'est jamais sûr que le code concerne l'autre fonctionnalité ou juste du rendu.

Eh bien justement, si j'en parle, c'est ce que j'ai le début de ce qu'il faut ici.

Ça se construit en morceau de cake:

# Debian/Ubuntu:
#sudo apt install libwayland-dev libegl-dev libgles-dev libvulkan-dev

# Fedora/RHEL:
#sudo dnf install wayland-devel libglvnd-devel vulkan-loader-devel

git clone https://github.com/Tarnyko/suave_code_samples
cd suave_code_samples/C/wayland/
make

et après par exemple:

./wayland-08-input_shell

vous donnera la zolie fenêtre ci-dessus!

(le précédent n'avait pas de barre de titre et se contentait d'afficher la position de la souris; l'anti-précédent affichait juste le carré blanc (titre!) ; et pour ajouter du drag &drop c'est l'exemple suivant… etc)

Wayland drag-and-drop

Vous avez peut-être aussi le but plus utilitaire de juste connaître les interfaces que votre compositeur supporte:

./wayland-02-list_interfaces-opengl_vulkan

Weston interface list

Ici par exemple, la conclusion est évidente: si je veux regarder mes vidéos VLC du canap', il me manque l'interface "Screenshot Inhibiter" et je dois vite installer Hyprland 😉.

J'ai prévu d'en ajouter d'autres, un tutoriel complet et de supporter des compositeurs exotiques, mais tu me connais : pour rester heureux, je ne m'engage (jamais) à rien.

(PS: Je te laisse sur une énigme : combien de lignes faut-il pour afficher un carré blanc avec toute la puissance de l'accélération Vulkan? Réponse : je vous laisse cliquer là et moi par sécurité je me barre ->[])

  • # Tant qu’à traduire…

    Posté par  . Évalué à 3 (+1/-0).

    …autant dire « morceau de gâteau », non ? Ah mais j’avoue qu’on fait alors moins facilement le lien avec l’expression anglophone.

  • # mais mais mais... c'est nul !

    Posté par  (site web personnel) . Évalué à 7 (+5/-1).

    Pourquoi l'API wayland ne ressemble pas à quelque-chose de simple et éprouvée ?

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

    • [^] # Re: mais mais mais... c'est nul !

      Posté par  . Évalué à 5 (+3/-0).

      Parce qu'elle doit être asynchrone, peut-être.

      • [^] # Re: mais mais mais... c'est nul !

        Posté par  (site web personnel) . Évalué à 8 (+6/-0). Dernière modification le 24 mars 2025 à 16:49.

        Céça !

        Mais en gros, l'API Wayland, c'est plus chose de xcb que de la Xlib.
        Un protocole plus bas niveau et asynchrone, qui expose davantage les rouages dans le but avoué du projet : éviter le tearing.

        Alors oui effectivement, une API utilisateur à la SDL va s'occuper de ça pour les devs pressés…
        …mais il faut relativiser le jugement :

        1. Le coeur du protocole est très propre AMHA (la découverte des interfaces et leurs versions !);
        2. Concrètement, la version de seulement 450 lignes utiles d'ici, -réduite à l'aide d'une lib "helper" officielle du projet- c'est pas plus long qu'une appli X11 qui essaie de fonctionner correctement sous les window managers de GNOME, KDE…et le reste du monde.

        On y a pas mal gagné sur l'existant quand même, et je trouve pas ça si compliqué !
        Juste le rendu software basé sur des concepts UNIX un peu avancés (mémoire partagée) oui ça faut l'apprivoiser.

    • [^] # Re: mais mais mais... c'est nul !

      Posté par  . Évalué à 5 (+2/-0).

      Parce que si tu veux utiliser SDL, ça fonctionne sous Wayland, pardi ! Tu veux pas t'occuper des trucs "internes" de ton système ? C'est l'API wayland qu'il te faut.

      Tu veux t'occuper des trucs internes ? C'est pas SDL. Mais là il te faut te taper des particularités des éventuels systèmes multiples supportées par Wayland si tu veux un truc équivalent, bon courage !

  • # J'aime pas X11 mais encore moins Wayland

    Posté par  (site web personnel) . Évalué à 7 (+5/-0).

    X11 ça fouette, on va pas se mentir. Ça date des années boys band et ça vient avec plein de limitations liées à notre utilisation de l'époque. On avait tous un clavier PS2 et une souris PS2, un écran et c'est tout. Puis on a eu l'USB, les écrans multiples, le hotplug et tout le tralala. Bien évidemment X11 n'était pas prêt pour ça et nous avons du ajouter une multitude de couches par dessus. Maintenant, compiler X.Org est impossible sans warning dans chacune des libx*.

    Oh wayland simplifie le tout en implémentant quasiment rien. Super, chaque compositeur doit réimplémenter la pile graphique, la gestions des entrées et des sorties. On a déplacé le problème à l'extérieur.

    Du coup on peut passer du temps à recoder une grosse partie et/ou utiliser quelques bibliothèques toutes faite mais il nous reste notre manière d'implémenter la partie visible à l'utilisateur : comment lui laisser configurer les écrans et entrées. Donc à chaque compositeur, on rajoute ce risque. Avec X.Org, il n'y a pas de problème puisque c'est géré en amont avec nos outils habituels setxkbpmap, xrandr, etc.

    En plus, aujourd'hui on a une fragmentation des bibliothèques qui ne supportent pas ou ne veulent pas supporter Wayland. Oh et bien sûr je ne parle pas des protocols Wayland en doublons qui font la même chose que les compositeurs décident d'implémenter ou non…

    Bref, c'est pas 2025 l'année du bureau sous Linux :)

    git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: J'aime pas X11 mais encore moins Wayland

      Posté par  . Évalué à 5 (+3/-0). Dernière modification le 25 mars 2025 à 10:03.

      Du coup, Mir, c'était mieux ou pas  ? (techniquement parlant, c'est-a-dire en faisant abstraction de ce qu'on peut penser de Canonical et de sa propension à créer des trucs dans son coin)

Envoyer un commentaire

Suivre le flux des commentaires

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