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 !
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:
…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)
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
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 Dring . É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.
[^] # Re: Tant qu’à traduire…
Posté par Tarnyko (site web personnel) . Évalué à 2 (+0/-0).
Oui, et je trouve que ça ringe moins 😶.
[^] # Re: Tant qu’à traduire…
Posté par thoasm . Évalué à 4 (+1/-0).
Ça ringe la clochette ?
# mais mais mais... c'est nul !
Posté par devnewton 🍺 (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 Christophe . Évalué à 5 (+3/-0).
Parce qu'elle doit être asynchrone, peut-être.
[^] # Re: mais mais mais... c'est nul !
Posté par Tarnyko (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 :
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 thoasm . É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 !
[^] # Re: mais mais mais... c'est nul !
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+3/-0). Dernière modification le 25 mars 2025 à 10:03.
Je parle de conception d'API, pas de lib précise.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: mais mais mais... c'est nul !
Posté par Tarnyko (site web personnel) . Évalué à 4 (+2/-0).
Qu'est-ce-qui te déplaît là-dedans?
Tu aurais voulu que le projet Wayland fournisse lui-même une lib "wrapper" pour des opérations courantes -comme créer des fenêtres? Un peu comme Xlib par-dessus xcb?
[^] # Re: mais mais mais... c'est nul !
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+3/-0).
Petite revue de codede https://github.com/Tarnyko/suave_code_samples/blob/master/C/wayland/wayland-04-shm_software_rendering-redraw.c :
void*: on dirait du Java en mode ProblemFactory ;J'aurais encore des critiques mineures, mais globalement l'API me laisse l'impression d'être compliqué et incomplète.
C'est peut être mieux que ce que proposait X11, mais moins bien que ce qu'on voit sur les autres OS.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: mais mais mais... c'est nul !
Posté par Tarnyko (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 26 mars 2025 à 15:31.
Haha, tu ne me décois pas, Newt' !
C'est effectivement la base de l'API 😁.
On s'abonne à un "registry" qui va nous indiquer dans un callback les interfaces qu'il suppose ; on s'abonne à celles qui nous intéressent, qui vont nous indiquer dans des callbacks ce qu'il se passe, etc…
Je trouve pas ça si horrible, moi ! L'avantage est que c'est extensible à l'infini, et négociable au runtime. Le fait est que le projet en est très fier, au point de le pousser ailleurs comme protocole IPC généraliste ;-).
PS : les conversions de void*, c'est moi qui les fait à cause du point ci-dessous.
Alors là je suis d'accord, et c'est le plus gros problème à mon sens… juste plus pour longtemps.
Quand Wayland est sorti, l'abstraction du shell (= window manager) s'appelait "wl_shell", elle était tout de suite incomplète pour éviter de prendre trop position (pas de minimisation, pas de passage de focus…) et après coup on s'est aperçus qu'elle avait pas mal de race conditions .
L'alternative nommée "xdg-shell" a passé des années en état instable, il fallait un peu la suivre, et ce n'est que récemment qu'elle est passée stable (sous le nom "xdg-wm-base", pour qu'on la repère bien).
Je les gère encore car je voulais vraiment que les exemples marchent chez tout le monde, même avec du code de 2016. Et du coup ué je convertis les types du shell en void* ;).
Mais on pourrait ne pas le faire et raccourcir tous les exemple de ~50 lignes… ou comme moi ici utiliser "libdecor" qui gère tout ça elle-même !
Alors oui c'est clivant. Le fait est que personne n'utilisait plus les API de dessin de X11 (genre "XDrawCircle") car elles étaient vieilles et aliasées, mais passait par celles des libs de toolkits (genre cairo ou Skia).
Wayland a été conçu pour supporter ce cas d'usage, et rien de plus.
[^] # Re: mais mais mais... c'est nul !
Posté par Tarnyko (site web personnel) . Évalué à 2 (+0/-0).
Les autres OS ont effectivement une direction claire, un "style par défaut", un SDK, un kit de widgets associé, etc.
Linux n'a jamais eu ça, et même la centralisation à travers X11/Xorg a toujours été une anomalie qui datait des années "consortium UNIX" propriétaires.
Les participants actuels à Wayland sont bien moins intéressés encore à fournir ça, et mettent bien plus de temps à se mettre d'accord ; d'où le côté minimaliste qui délègue ailleurs.
# J'aime pas X11 mais encore moins Wayland
Posté par David Demelier (site web personnel) . Évalué à 7 (+6/-1).
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 mahikeulbody . Évalué à 6 (+4/-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)
[^] # Re: J'aime pas X11 mais encore moins Wayland
Posté par Lutin . Évalué à 5 (+3/-0).
Les gros changements de piles prennent souvent cette direction: une réécriture un peu plus bas niveau. Dans le même esprit il y a openGL -> Vulkan.
[^] # Re: J'aime pas X11 mais encore moins Wayland
Posté par Meku (site web personnel) . Évalué à 5 (+3/-0).
Là c'est pire que ça : chaque compositeur / gestionnaire de fenêtre doit faire le travail que faisait avant Xorg pour tous.
Avec une brique logicielle centrale comme Xorg, une fois une fonction implémentée ou corrigée, tout le monde en bénéficie.
Avec wayland, chaque implémentation va avoir ses propres bugs, limitations, comportements spécifiques…
[^] # Re: J'aime pas X11 mais encore moins Wayland
Posté par Lutin . Évalué à 3 (+1/-0).
Pour Wayland cette brique logicielle c'est wlroots non ?
[^] # Re: J'aime pas X11 mais encore moins Wayland
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0).
Pour beaucoup mais pas pour tous. Je ne crois pas que Gnome et KDE utilisent wlroots par exemple.
[^] # Re: J'aime pas X11 mais encore moins Wayland
Posté par Tarnyko (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 26 mars 2025 à 13:09.
Weston (le compositeur de référence), GNOME et Enlightenment ont chacun leur propre implémentation.
À noter que :
- Weston fournit une lib réutilisable du genre de wlroots. Qu'elle n'ait pas été si utilisée indique soit ses limites, soit le manque de commu autour ;
- KDE s'appuie aujourd'hui beaucoup l'implémentation de Qt. Celle-ci est très utilisée dans d'autres contextes, notamment dans l'embarqué.
[^] # Re: J'aime pas X11 mais encore moins Wayland
Posté par David Demelier (site web personnel) . Évalué à 3 (+1/-0).
Je suis assez d'accord sur le principe.
Par contre wayland pour le coup est beaucoup trop basique. Même si les fonctionnalités ont changé il reste des choses assez génériques comme les entrées et sorties et globalement ce n'est pas prêt de changer avant un moment. Ce que je veux dire c'est que X11 a été pensé avec des besoins de l'époque dont les APIs n'ont cessé d'être remodelées et/ou remplacées pour du matériel changeant. Or, aujourd'hui on a quand même une stabilité qui nous permettrait d'avoir un minimum de support directement dans les protocols wayland plutôt que réimplémener toute la pile pour chaque compositeur (quand on veut/peut pas utiliser des bibliothèques existantes). Par exemple, on a quasiment tous un ou des écrans plutôt rectangle, un clavier et un pointeur quelconque.
Beaucoup de compositeurs sont basés sur wlroots avec les avantages et inconvénients que cela comporte. Si demain je décide de faire un compositeur de zéro je dois implémenter une grosse partie de la gestion des entrées/sorties plutôt que de me baser sur mon compositeur lui même. Et on voit le nombre de problème liés à KDE/GNOME qui implémentent eux même leur compositeur créant une fragmentation encore plus élevée dès lors qu'une application s'attend à utiliser un protocol expérimental
xyz-abc-v2que l'un ou l'autre ne supporte pas correctement ou pas du tout (n'est-ce pas xdg-decoration)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 devnewton 🍺 (site web personnel) . Évalué à 5 (+2/-0). Dernière modification le 28 mars 2025 à 11:45.
Si la réécriture "bas niveau" a des avantages pour certaines applications pointues (les moteurs 3d), c'est aussi une façon de repousser des problèmes de la pile vers les applications.
Ce qu'on gagne en performance, on le perds en fonctionnalités et en stabilité.
Bonne chance pour être prêt pour le bureau avec un bureau en pièces détachés…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: J'aime pas X11 mais encore moins Wayland
Posté par Tarnyko (site web personnel) . Évalué à 2 (+0/-0).
Du coup @devnewton, penses-tu qu'on devrait écrire une "Wlib", légère surcouche ne dépendant de rien et fournissant le strict nécessaire (apparence de synchrone, API de dessin, widgets en carton, etc…). Ou palapeine ?
[^] # Re: J'aime pas X11 mais encore moins Wayland
Posté par devnewton 🍺 (site web personnel) . Évalué à 5 (+2/-0).
Je ne sais pas trop, si je devais réinventer une pile graphique, je regarderais peut être du côté de QNX…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: J'aime pas X11 mais encore moins Wayland
Posté par Tarnyko (site web personnel) . Évalué à 6 (+4/-0). Dernière modification le 26 mars 2025 à 13:25.
Là où je donne raison à ton commentaire David : on avait un gros truc monolithique et dépassé (X11/X.org).
En passant à Wayland, on a supprimé le code dépassé, et en même temps :
- on a réinternalisé une toute petite partie de ce qui était omis par X11 (le window manager p.ex.) ;
- on s'est abstenu d'internaliser d'autres chose qui sur d'autres OS le sont depuis toujours (les widgets p.ex., largement pris en charge sous Nunux par des toolkits genre GTK/Qt);
- on a externalisé/délégué la partie initialisation bas niveau de l'affichage (qui se retrouve maintenant éclatée entre les différents compositeurs).
C'est un cas un peu unique dans le soft. D'une certaine façon, c'est très UNIXien dans le sens "modularité". Il se trouve que ça convient très bien à certains domaines comme l'embarqué, qui veulent remplacer et optimiser chaque brique facilement.
Mais ceux qui pensaient que ça aiderait le desktop ou simplifierait la partie "code commun" en sont pour leurs frais ;-).
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.