Sommaire
- Installer notre compositeur : labwc
- Outils pour notre compositeur
- Se lancer : remplacer GNOME par labwc
Salut nal',
C'est l'ère du bureau Wayland avec le retrait de X11 natif par :
- l'édition GNOME de Fedora 43 et RHEL 10 ;
- Ubuntu 25.10 et donc probablement sa future LTS.
Toutes ces distributions fournissent des environnements de bureau bien gras, un saint duopole de l'interface graphique libre ; qui, annonçons-le après 10 ans de prototypage, fonctionne plutôt bien (même avec une carte NVIDIA, c'est dire !).
Mais une telle installation ne convient pas à tout le monde ni à tous les cas :
- quid de l'embarqué ?
- remémorons-nous nos premières années… on installait le serveur X, un gestionnaire de fenêtres parmi une floppée et nos applis. Notre bureau était fait sur mesure, il était modulaire… (je remontre une telle installation ici d'ailleurs).
Le projet Wayland fournit un compositeur de référence : Weston.
Étant écrit à 90% par des gens de l'embarqué, il remplit haut la main le premier critère ! Et fournit plein de fonctions : un lanceur, deux gestionnaires de fenêtres, du rendu logiciel ou accéléré 3D (avec Vulkan depuis peu), un enregistreur vidéo, un serveur RDP…
En vrai si tu es dans l'embarqué, tu devrais vraiment considérer Weston ; en suivant p.ex. son excellente documentation. Mais il n'est pas vraiment modulaire : c'est-à-dire que peu écrivent des modules pour Weston (j'étais l'un des rares, et reprendrai peut-être bientôt 😉…).
C'est pourquoi je vais présenter ici…. l'autre famille.
Installer notre compositeur : labwc
wlroots est une bibliothèque permettant à chacun d'écrire son propre compositeur en abstrayant le code redondant (initialisation du GPU, gestion des entrées…).
Il permet en fait de revenir à une logique de "gestionnaire de fenêtres" sous Wayland ; ce wiki en liste plein !
labwc est mon petit chouchou parmi ceux-ci : il est traditionnel, léger et maintenu. Il dit s'inspirer d'un certain OpenBox (que je t'avoue ne pas avoir utilisé).
Nous allons installer sa dernière version nous-mêmes.
Prérequis
Debian 13 "Trixie"/Ubuntu 25.04 "Plucky Puffin"
sudo apt install libxml2-dev libpng-dev librsvg2-dev liblcms2-dev libcairo2-dev libpango1.0-dev libsystemd-dev
sudo apt install wayland-protocols libwayland-dev libxkbcommon-dev libdrm-dev libgbm-dev libvulkan-dev
sudo apt install xwayland libxcb-render-util0-dev libxcb-errors-dev libxcb-icccm4-dev libxcb-ewmh-dev
sudo apt install libx11-xcb-dev libxcb1-dev libxcb-image0-dev libxcb-composite0-dev libxcb-shm0-dev libxcb-dri3-dev libxcb-present-dev libxcb-res0-dev libxcb-xinput-dev
sudo apt install glslang-tools hwdata libcap-dev libegl-dev libegl1-mesa-dev libgles2-mesa-dev
sudo apt install libinput-dev libseat-dev libdisplay-info-dev libsfdo-dev libliftoff-dev
sudo apt install git meson
Vérifiez que vous avez bien au moins Wayland 1.23.1 :
pkg-config --modversion wayland-client
# 1.23.1
Fedora 42 (mise à jour)
sudo dnf install libxml2-devel libpng-devel librsvg2-devel lcms2-devel cairo-devel pango-devel systemd-devel
sudo dnf install wayland-devel wayland-protocols-devel libxkbcommon-devel libdrm-devel mesa-libgbm-devel vulkan-loader-devel
sudo dnf install xorg-x11-server-Xwayland-devel xcb-util-renderutil-devel xcb-util-errors-devel xcb-util-wm-devel
sudo dnf install libinput-devel libseat-devel libdisplay-info-devel libsfdo-devel libliftoff-devel
sudo dnf install wlroots-devel git mesonVérifiez que vous avez bien wlroots 0.19 :
pkg-config --modversion wlroots-0.19
# 0.19.2Installer
Debian et Ubuntu ont encore une étape supplémentaire (que Fedora peut sauter) :
Compiler wlroots 0.19.2
git clone https://gitlab.freedesktop.org/wlroots/wlroots --branch 0.19.2
cd wlroots/
meson setup build/ --wrap-mode=nodownload
meson compile -C build/
sudo meson install -C build/ --skip-subprojects
Vérifiez que vous avez bien wlroots 0.19 :
pkg-config --modversion wlroots-0.19
# 0.19.2
Compiler labwc 0.9.2
git clone https://github.com/labwc/labwc --branch 0.9.2
cd labwc/
meson setup build/ --wrap-mode=nodownload
meson compile -C build/
sudo meson install -C build/ --skip-subprojects
Verifier
Nous pouvons maintenant préparer la configuration du clavier français :
mkdir ~/.config/labwc
echo "XKB_DEFAULT_LAYOUT=fr" > ~/.config/labwc/environment
et tester :
labwc
Un fond noir que rien ne permet de changer, un menu avec une seule application au clic-droit, aucune fonction apparente… c'est spartiate !
C'est parce labwc n'est pas conçu pour fonctionner seul mais avec un écosystème d'outils qui, tous, utilisent le protocole wlr-layer-shell de wlroots. Une liste quasi-intégrale de ceux-ci est fournie ici ; je vais vous présenter les indispensables.
Outils pour notre compositeur
Terminal : foot
foot est un digne remplaçant du vénérable xterm, qui ne dépend d'aucun toolkit ni même de X11 : il est pur Wayland.
Sa fonction reprise de xterm qui me fait craquer : il supporte les images au format Sixel de DEC :flushed:.
curl -O https://raw.githubusercontent.com/saitoha/libsixel/master/images/snake.six
cat snake.six
# Fedora
sudo dnf install foot
# Debian/Ubuntu
sudo apt install foot
Pour l'avoir par défaut dans labwc, il suffit de le positionner en haut dans /usr/local/bin/lab-sensible-terminal :
terminals="\
foot \
x-terminal-emulator \
Lanceurs : LavaLauncher (statique) - Cairo-Dock (dynamique)
LavaLauncher est une barre de lancement statique, comme celle de Weston.
# Fedora
sudo dnf install breeze-icon-theme lava-launcher
# Debian/Ubuntu
sudo apt install breeze-icon-theme
# (doit compiler)
git clone https://git.sr.ht/~leon_plickat/lavalauncher
cd lavalauncher/
sed -i "/^subdir('doc')\$/s/^/#/" meson.build
meson setup build/ --wrap-mode=nodownload
meson compile -C build/
sudo meson install -C build/ --skip-subprojects
Configurez-la p.ex. avec ce lavalauncher.conf que je fournis :
mkdir ~/.config/lavalauncher
curl https://tarnyko.net/repo/labwc/lavalauncher.conf > ~/.config/lavalauncher/lavalauncher.conf
Pour la lancer au démarrage de labwc :
echo "lavalauncher &" > ~/.config/labwc/autostart
Cairo-Dock est une superbe alternative dynamique qui auto-découvre vos lanceurs d'applications ; sa version Ubuntu/Debian stable est un peu ancienne et cassée ici, mais la 3.6.1 de Fedora 42 fonctionne à merveille sur labwc :
sudo dnf install cairo-dock-core
echo "cairo-dock -c &" > ~/.config/labwc/autostart
Fond et verrouillage d'écran : swaybg - swaylock
Ces 2 outils liés au compositeur Sway nous fourniront l'essentiel :
# Fedora
sudo dnf install swaybg swaylock
# Debian/Ubuntu
sudo apt install swaybg swaylock
Définissons un fond d'écran au démarrage avec swaybg (l'image doit exister ; elle vient ici du paquet "weston") :
echo "swaybg -m stretch -i /usr/share/weston/background.png" >> ~/.config/labwc/autostart
De plus, vous avez peut-être remarqué mon icône de cadenas sur LavaLauncher ; swaylock verrouillera sans chichis :
Capture et enregistrement d'écran : grim & slurp - wf-recorder
grim prend des captutes d'écran, et slurp peut lui indiquer une région d'écran cliquée interactivement par l'utilisateur :
# Fedora
sudo dnf install grim slurp wl-clipboard
# Debian/Ubuntu
sudo apt install grim slurp wl-clipboard
Ils seront notre première occasion de définir des raccourcis clavier globaux via le fichier rc.xml (que je fournis) :
curl https://tarnyko.net/repo/labwc/rc.xml > ~/.config/labwc/rc.xml
echo 'grim - | wl-copy' | sudo tee /usr/local/bin/grim-screen.sh
echo 'grim -g "$(slurp)" - | wl-copy' | sudo tee /usr/local/bin/grim-region.sh
sudo chmod a+x /usr/local/bin/grim-*.sh
Nous pouvons dorénavant utiliser [Impr.Écran] et [Super]+[Impr.Écran] pour copier tout ou partie de l'écran dans le presse-papiers, et coller dans n'importe quelle application.
Pour enregistrer l'écran, wf-recorder est la référence. Attention : il tire FFmpeg et je ne lui ai pas encore trouvé de meilleure interface qu'un SIGHUP :wink:.
# Fedora
sudo dnf install wf-recorder
# Debian/Ubuntu
sudo apt install wf-recorder
wf-recorder -f record.mkv
Clavier virtuel : wvkbd
wvkbd est une semblance du vénérable xvkbd fournissant un clavier virtuel ; idéal pour l'embarqué !
# Fedora
curl -O https://download.copr.fedorainfracloud.org/results/fed500/wvkbd/fedora-42-x86_64/08982658-wvkbd/wvkbd-0.16-1.fc42.x86_64.rpm
sudo rpm -ivh wvkbd*.rpm
# Debian/Ubuntu
sudo apt install wvkkb
Une fois installé, on peut le faire apparaître et disparaître à volonté :
wvkbd-mobintl -H 200 --hidden &
# faire apparaître
killall -SIGUSR2 wvkbd-mobintl
# faire disparaître
killall -SIGUSR1 wvkbd-mobintl
Pour le démarrer automatiquement et le faire surgir d'un raccourci clavier, vous savez désormais comment faire 😉.
Bureau distant VNC : wayvnc
Rien ne vaut WayVNC pour le contrôle distant via le protocole VNC :
# Fedora
sudo dnf install wavnc
# Debian/Ubuntu
sudo apt install wayvnc
Faisons-le écouter en clair sans mot de passe (pour la démo) :
wayvnc 0.0.0.0
Pour chiffrer et utiliser un mot de passe, il faut forcément créer une clé TLS ; je vous laisse lire la documentation :wink:.
Configuration d'écrans : wlr-randr - wdisplays
wlr-randr reprend partiellement la classique syntaxe XRandR :
# Fedora
sudo dnf install wlr-randr wdisplays
# Debian/Ubuntu
sudo apt install wlr-randr wdisplays
pour une configuration facile de vos écrans :
wlr-randr --output WL-1 --mode 1024x768
# pivoter l'écran
wlr-randr --output WL-1 --transform 90
wlr-randr --output WL-1 --transform normal
# positionner l'écran 1 à droite de l'écran 2
wlr-randr --output WL-1 --right-of WL-2
(remplacez éventuellement "WL-1" par le résultat de : wlr-randr | head -n 1 | cut -d' ' -f1)
Si vous préférez un outil graphique, wdisplays est un outil GTK3 ne dépendant donc pas du bureau GNOME :
Résumé
Bravo : après tous ces efforts, on est maintenant iso-fonctionnels avec Weston ! Eh oui, on n'a pas plus de fonctions, on a surtout échangé le serveur RDP pour VNC ; mais pu sélectionner chaque composant individuel 😉.
Se lancer : remplacer GNOME par labwc
Vous avez probablement utilisé toutes les commandes ci-dessus depuis un bureau pré-existant ; à ce moment, le compositeur se lance comme une fenêtre, et c'est parfait pour prototyper :smiley:.
Il est temps de démarrer avec labwc en bureau principal !
Désactivez GNOME, l'écran devient noir…
sudo systemctl disable gdm --now
Si vous avez une carte NVIDIA avec le driver propriétaire, assurez-vous d'avoir au moins sa version 555.42 et faites :
echo "options nvidia-drm modeset=1" | sudo tee /etc/modprobe.d/nvidia.conf
sudo reboot
Une pression sur [Ctrl]+[Alt]+[F2] nous amènera sur un login en mode texte, où après connexion nous n'aurons plus qu'à faire :
labwc
Et voilà !
P.S. : si les applications X11 ne se lancent pas, c'est possiblement parce que les capacités du GPU ne conviennent pas à Xwayland. Dans ce cas, passer en rendu logiciel :
echo "WLR_RENDERER=pixman" >> ~/.config/labwc/environment
# Rha, coquille !
Posté par Tarnyko (site web personnel) . Évalué à 2 (+0/-0).
Aux modérateurs, cette section:
Fedora 42 (mise à jour)
Vérifiez que vous avez bien wlroots 0.19 :
devrait en fait être :
Fedora 42 (mise à jour)
Vérifiez que vous avez bien wlroots 0.19 :
Merki 😀
[^] # Re: Rha, coquille !
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+1/-0).
Corrigé, merci.
# wlr-randr
Posté par Meku (site web personnel) . Évalué à 6 (+4/-0).
J'ai parcouru le journal puis quand j'ai vu la commande wlr-randr, j'ai vite installé ça sur ma machine pour la tester. Ça fait des mois que je cherche un moyen pratique en ligne de commande pour gérer l'affichage.
Et puis :
ಥ﹏ಥ
(Je suis sous Gnome 49.2)
J'ai vu que ça marchait avec Cosmic Desktop.
[^] # Re: wlr-randr
Posté par Tarnyko (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 14 décembre 2025 à 18:23.
Hello Meku ; alors :
C'est attendu, et tristement prévisible : comme son nom l'indique un petit peu, wlr-randr ne supporte que les compositeurs exposant la famille de protocoles wlr
(c'est-à-dire ceux basé sur la lib wlroots ; dont labwc de cet article… et COSMIC apparemment, tu me l'apprends !).
Comme ça à vue de nez, je peux prédire que ça ne marchera pas non plus sous KDE Plasma ni Weston.
Ceux-ci gèrent eux-mêmes leurs réglages vidéos, avec ou sans protocole externe pour interagir avec. Techniquement, ils pourraient le supporter (via un module ?) mais ne le font pas de base, et personne n'a jugé bon d'écrire un tel module on dirait…
Rien à voir mais : GNOME ne propose pas un truc par D-Bus ?
[^] # Re: wlr-randr
Posté par Meku (site web personnel) . Évalué à 4 (+2/-0).
Si mais je cherchais une commande plus universelle et indépendante de l'environnement de bureau, à la xrandr. C'est pour ça que wlr-randr m'a tout de suite intéressé.
Sinon, l'interface wlr-output-management-unstable-v1 est encore expérimentale, ce qui peut expliquer la non implémentation par Gnome et d'autres.
Sur https://wayland.app/protocols/wlr-output-management-unstable-v1 tout en bas on peut avoir l'état d'implémentation de cette interface par compositeur.
KWin et Gamescope ne l'implémentent pas non plus.
[^] # Re: wlr-randr
Posté par Tarnyko (site web personnel) . Évalué à 2 (+0/-0).
Ils ne l'implémenteront probablement pas eux-mêmes : ce n'est pas "dans la famille", pour ainsi dire.
Si on voulait le faire léger et hors de Mutter (leur compositeur), on pourrait imaginer un petit processus indépendant qui expose le protocole et lance les commandes D-Bus qu'il attend. Ce serait un chouette projet pas trop gros !
[^] # Re: wlr-randr
Posté par Meku (site web personnel) . Évalué à 3 (+1/-0).
Oui mais j'espère qu'un jour ce genre d'interface « migre » dans le core wayland.
Le contrôle de Mutter via D-Bus, si c'est dans une commande généraliste qui encapsule les interfaces des autres Desktops, ok, mais si c'est une commande propre à Gnome, c'est moins top car pas portable (toujours mieux que rien mais bon).
[^] # Re: wlr-randr
Posté par Tarnyko (site web personnel) . Évalué à 2 (+0/-0).
C'est l'idée (enfin normalement) !
Le protocole Wayland n'a pas voulu définir ces aspects côté serveur, alors chacun a fait à sa sauce.
L'encapsulation ne va objectivement pas dans wlr-randr, éventuellement dans GNOME… mais ils l'accepteront pas tel quel ; pour ça je suggérais un module indépendant. À la fin le protocole le plus utilisé "gagnera" logiquement.
[^] # Re: wlr-randr
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
C’est marrant je pensais à faire un journal sur ce sujet de « randr sous Wayland » ces jours-ci.
Ne pas avoir d’équivalent à
xrandrest un grave problème qui rend Wayland inadapté à mon flux de travail.Je n’ai rien contre Wayland sur le principe et je suis convaincu qu’il apporte de bonnes choses, mais Wayland ne répond pas à mes besoins et n’est pas prêt pour mon activité.
Bon je ferai peut-être un journal pour détailler ce flux de travail qui rend
xrandrvital, et qui requiert que Wayland se dote d’un outil universel qui fonctionne sur tous les compositeurs Wayland, et que si ça existe déjà, que tous les compositeurs l’implémentent.ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: wlr-randr
Posté par Tarnyko (site web personnel) . Évalué à 2 (+0/-0).
Ce n'est donc un problème que si tu utilises des compositeurs qui ne le supportent pas 😶.
Plus sérieusement, quel est donc le dit flux de travail ? Testage de distributions à la chaîne, bureau mobile…. ?
[^] # Re: wlr-randr
Posté par Psychofox (Mastodon) . Évalué à 3 (+1/-1). Dernière modification le 15 décembre 2025 à 00:55.
J'ai honnêtement du mal à comprendre le "workflow" en question.
Tant que tu peux changer ta config d'écran en cas de besoin, tu t'en branles que ce soit fait avec randr ou autre outil non?
[^] # Re: wlr-randr
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 5 (+2/-0).
Je ne veux pas avoir à me lever pour aller changer la résolution à la main sur la machine. J’utilise xrandr à travers SSH sur des machines sur le réseau.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: wlr-randr
Posté par Tarnyko (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 15 décembre 2025 à 10:19.
Ah je vois ! Tu te connectes par SSH, avec la redirection X11 pour disposer de son socket (ou au pire ça se fait bien à la main).
Par Wayland "seul", avec les compositeurs wlroots et la commande
wlr-randr, ça se fait bien aussi en définissantWAYLAND_DISPLAY(l'équivalent de la variableDISPLAYsous X11).Mais je vois le problème potentiel avec GNOME : il s'attend à du D-Bus. Quand tu te logges en interactif sur la machine,
systemddémarre un démon D-Bus personnel… mais pas forcément en SSH, où c'est paramétré via PAM, typiquement dans/etc/pam.d/sshd. Et la config par défaut SSH/PAM considère que tu n'as pas besoin de D-Bus car ce n'est pas un usage "desktop".Maintenant ça se rajoute sans problème dans la config. D'ailleurs, le wrapper que j'évoque plus haut en aurait aussi besoin, vu qu'il fait du D-Bus… est-ce que ça résoudrait ton souci, ou tu trouves que ça vaut pas le coup (parce que tu as une config hétérogène = GNOME pas partout)?
[^] # Re: wlr-randr
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 15 décembre 2025 à 16:11.
Oui
wlr-randretWAYLAND_DISPLAYsont architecturés commexrandretDISPLAY, sauf que comme tu le dis,wlr-randrn’est pas universel à Wayland contrairement àxrandrqui est universel à X11.C’est un banc de test, et le fait que la configuration soit hétérogène fait partie du cahier des charges.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: wlr-randr
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0).
Je ne vois toujours pas le rapport, si c'est un autre outil tu peux aussi y accéder depuis ssh.
[^] # Re: wlr-randr
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 5 (+2/-0).
Je cherche une commande unique, au pire une commande pour X11 et une commande pour Wayland.
De toute façon mon cas d’usage spécifique que je détaillerai plus tard n’est pas le seul.
Ce problème concerne la plupart des jeux vidéos qui ont un mode plein écran. Dès que tu passes à Wayland, tu as de très forte chance que si ton jeu est en plein écran et que tu réduises la résolution dans le jeu, le jeu s’affiche en petit dans le coin haut gauche de l’écran et que le reste de l’écran reste noir ou affiche des données aléatoires. C’est parce que le jeu réduit alors la taille de son framebuffer mais que la résolution de l’écran reste inchangée. C’est la conséquence du fait qu’il n’y a pas de méthode standard pour changer la résolution de l’écran.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: wlr-randr
Posté par Tarnyko (site web personnel) . Évalué à 2 (+0/-0).
Ah oui j'ai vu j'ai vu le problème sur certains émulateurs !
Ceux qui savent scaler à une taille arbitraire : no pb. Les autres par contre, ils clignotent et restent tous petits.
C'est vrai qu'après avoir demandé une fois la permission à l'utilisateur, un protocole universel ce serait bien…
[^] # Re: wlr-randr
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0).
Il n'y a pas non plus 100000 compositeurs wayland, globalement un gros morceau basé sur wlroots, mutter et kwin. Le reste c'est quand même hyper anecdotique (hyprland, enlightenment, weston…), du coup ça doit être assez facile de faire un wrapper qui supporte randr, wlr-randr, kwin et gnome tout en laissant tomber le reste.
[^] # Commentaire supprimé
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 16 décembre 2025 à 06:51.
Ce commentaire a été supprimé par l’équipe de modération.
# Et pour les utilisateurs de KiCad ?
Posté par flavien75 . Évalué à 4 (+3/-0).
Ça va être chaud pour les utilisateurs de KiCad.
Même si dans la pratique il tourne sous Wayland (testé avec Debian 13), officiellement les mainteneurs ne le supporte pas et ne veulent pas en entendre parler.
page de téléchargement
En gros les bugs liés à Wayland ne seront pas investigués.
Les vrais naviguent en -42
[^] # Re: Et pour les utilisateurs de KiCad ?
Posté par Tarnyko (site web personnel) . Évalué à 3 (+1/-0).
C'est leur droit, c'est une philosophie…
C'est-à-dire : quand bien même tu viens d'indiquer que le soft y marche, ils ne veulent pas de bugs rapportés depuis cet environnement… c'est-à-dire qu'ils ne le "supportent" pas, pour ne pas traiter des bugs dont ils ne se sentent pas redevables (un peu comme si ton soft était conçu pour OpenBSD, et qu'on te rapportait des bugs depuis Linux).
C'est (toujours) légitime du point du vue des dévs, qui font ce qu'ils veulent… mais est-ce raisonnable ?
Aujourd'hui sans doute encore, mais on peut supposer que les utilisateurs du couple Wayland/Xwayland sont déjà nombreux, et qu'ils le seront de plus en plus (cf. intro du journal).
Exiger des utilisateurs impliqués qu'ils réinstallent Xorg (plus officiellement supporté sur RHEL p.ex.) est donc une barrière qu'ils leur mettent, vouée à grandir avec le temps. Je pense que c'est comme ça qu'il faut le voir : comme un "deal" entre une équipe de dév avec sa commu, pas un attentat contre le progrès !
[^] # Re: Et pour les utilisateurs de KiCad ?
Posté par Luc-Skywalker . Évalué à 5 (+3/-0).
Les explications de l'équipe dans le blog de KiCAD à ce sujet.
J'utilise X11, mais j'imagine que si KiCAD ne fonctionne pas très bien avec Wayland, ça devrait être le cas pour d'autres applications aussi.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Et pour les utilisateurs de KiCad ?
Posté par Tarnyko (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 15 décembre 2025 à 17:06.
C'est vrai… mais je suis d'accord avec la base de ce design.
Je m'explique.
Avec X11 ou ces autres APIs, une application peut demander : "positionne-moi au centre de l'écran, en premier plan" et spammer. Gênant, et c'est une technique connue pour intercepter des frappes clavier etc.
Le protocole Wayland considère qu'une application n'a pas à savoir où elle se situe sur l'écran (profilage) ni à s'auto-déplacer, ni à se remettre au 1er plan… et je suis d'accord.
Mais il existe des cas légitimes pour la position : GIMP avec ses multiples fenêtres d'outils p.ex., dont on aimerait pouvoir sauvegarder la position de session en session.
Dans ce cas, la logique serait plutôt : "j'aimerais sauvegarder ma position actuelle et la restaurer la prochaine fois. Demande à l'utilisateur et, s'il est d'accord, le compositeur s'occupera de ça lui-même".
Un tel protocole est à l'étude je crois (avec eux ou ceux d'une autre appli similaire).
Du coup je comprends la frustration des gens de KiCAD de pas l'avoir là, tout de suite. Mais vouloir positionner sa fenêtre d'autorité, ça ne devrait pas être une API publique que tout le monde peut utiliser.
Et déplacer la souris sans action utilisateur… j'ai vraiment besoin d'expliquer ?
[^] # Re: Et pour les utilisateurs de KiCad ?
Posté par Luc-Skywalker . Évalué à 3 (+1/-0).
Je comprends ton point de vue, je comprends le point de vue de Kicad, mais comme je comprends à peu prés rien à la pile graphique de Linux …
Dans le blog, on a la liste de ce qui coince et on y retrouve les pbs de GIMP.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Et pour les utilisateurs de KiCad ?
Posté par Tarnyko (site web personnel) . Évalué à 3 (+1/-0).
Ah oui effectivement : cités avec le bon vocabulaire.
Ils utilisent wxWidgets ? Ça m'a toujours intéressé (plutôt sur l'aspect cross-platform que sous Linux où je crois que ça wrappe GTK).
Ils ont visiblement bien investigué. C'est loin d'être aussi noir et blanc que j'aurais cru : ils veulent bien supporter le truc, mais sans faire de cercles.
Après pour un utilisateur KiCad quotidien, c'est aussi rédhibitoire ?
[^] # Re: Et pour les utilisateurs de KiCad ?
Posté par Luc-Skywalker . Évalué à 3 (+1/-0). Dernière modification le 15 décembre 2025 à 19:15.
Kicad, Gimp et sans doute d'autres. Je ne connais pas trop la solution (j'espère qu'elle ne tardera pas trop à venir, sans doute un truc en plus dans le stack graphique ;) et j'imagine que ça peut être problématique au quotidien pour l'utilisateur (je suis sous X11, je n'ai jamais utilisé Wayland).
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Et pour les utilisateurs de KiCad ?
Posté par Tarnyko (site web personnel) . Évalué à 4 (+2/-0).
Alors tu peux tester facile avec mon tuto (attendu que t'aies les bonnes distros ;) ).
Bah le protocole de position est en cours de taf on dirait. Les autres points je sais pas… Moi j'ai des trucs prévus -le tuto est pas innocent- mais rien de ça n'en fait partie…
[^] # Re: Et pour les utilisateurs de KiCad ?
Posté par Luc-Skywalker . Évalué à 3 (+1/-0).
oui je les ai
mais non
https://www.raspberrypi.com/news/a-new-release-of-raspberry-pi-os/ (28th Oct 2024 ):
je me rends compte qu'en fait j'ai déjà utilisé Wayland et labwc (donc presque à l'insu de mon plein gré ;).
Vu comme ça, sous RaspiOs, ça marche très bien.
Mais comme je n'utilise pas mes RBPi avec un environnement graphique (style "bureau") je n'ai jamais vraiment creusé l'affaire.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Et pour les utilisateurs de KiCad ?
Posté par Tarnyko (site web personnel) . Évalué à 4 (+2/-0).
Ah bon sang, ils ont switché vers labwc l'année dernière \o/ !
Je l'ignorais, y compris qu'ils utilisaient wayfire d'abord (réputé plus tape-à-l'oeil, mais moins stable effectivement)… bon ben le point "embarqué" est prouvé 😎.
[^] # Re: Et pour les utilisateurs de KiCad ?
Posté par flavien75 . Évalué à 4 (+3/-0). Dernière modification le 15 décembre 2025 à 19:49.
Pas vraiment, c'est surtout que le message m'avait surpris. Je me serais attendu à voir un message du style "évitez Wayland à cause des bugs qui subsistent et qu'on ne peut pas nous-même corriger ou des fonctionnalités qui manquent dans Wayland" (manque de temps / de compétence pour débugger Wayland).
Dans mon cas, je cherche les ennuis vu que je lance Kicad depuis une Debian 13 dans une machine virtuelle sous Windows (j'ai une autre version de Kicad installée sur mon PC et je ne veux pas y toucher pour l'instant). Et franchement, malgré ça, ça marche plutôt bien, a part 2-3 glitch quand on essai de zoomer sur une partie de carte et que le zoom semble se faire ailleurs.
Et on est bien d'accord que c'est leur droit le plus fondamental de ne pas fournir du support pour des plates-formes qui ne leur conviennent pas.
Mais bon, j'ai aussi du mal à croire que rester sur Xorg soit une solution d'avenir à long terme.
edit: je ne suis pas non plus un utilisateur quotidien, disons qu'en ce moment je passe 1/2 journée par semaine dessus, mais d'habitude c'est plutôt une semaine ou deux par an.
Les vrais naviguent en -42
[^] # Re: Et pour les utilisateurs de KiCad ?
Posté par Tarnyko (site web personnel) . Évalué à 3 (+1/-0).
Je viens de l'installer du coup, sur la Debian 13 des captures justement ; ça marche plutôt pas mal. J'ai aussi essayé le zoom (avec la molette, sur la circuit par défaut) sans voir de gros souci… mais j'y connais rien à KiCad 😄 !
Tout à fait !
Oui pareil. Après ils doivent se dire qu'il reste du temps, et ils ont pas tort… le soft tourne apparemment grâce à XWayland et lui 1) ne bougera plus trop 2) est parti pour rester !
[^] # Re: Et pour les utilisateurs de KiCad ?
Posté par Meku (site web personnel) . Évalué à 2 (+0/-0).
Il y a d'autres cas où positionner une fenêtre peut être indispensable.
Par exemple pour certaines applications critiques, où certains espaces de l'écran ne doivent en aucun cas être recouverts par une fenêtre qui pop, contrôler depuis une application métier la position de la fenêtre qu'on ouvre est nécessaire (sans aller jusqu'à réimplémenter tout un gestionnaire de fenêtres).
[^] # Re: Et pour les utilisateurs de KiCad ?
Posté par YBoy360 (site web personnel) . Évalué à 3 (+1/-0).
C'est vraiment une très mauvaise réaction de la part des développeurs de Kicad (ils sont Français pour certains).
Kicad fonctionne sous Plasma Wayland, avec XWayland en hdpi à ma connaissance. Pourquoi ne pas suggérer une configuration utilisable sous Wayland, utilisant XWayland ?
Normal qu'il y ait plus de bug report sous Wayland, CAR C'est CE QU'UTILISE LES … UTILISATEURS !!!
Ahhh ça fait du bien …
Il devrait au moins supporter XWayland.
I use Arch BTW
[^] # Re: Et pour les utilisateurs de KiCad ?
Posté par Tarnyko (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 17 décembre 2025 à 18:13.
Merci pour ta réaction qui venait du coeur ☺️.
Alors je suppose que ce qui pourrait se passer :
- j'ai installé le paquet "kicad" sur Debian 13 Trixie. Dans ce cas-là, KiCad ne se lançait pas du tout sans Xwayland… mais c'est peut-être parce qu'il a été compilé pour (= en mode X11) ;
- normalement, dans ce mode, il a toutes ses capacités : positionner les fenétres, etc… car Xwayland émule X11 au mieux ;
- mais il est peut-être possible de le compiler sans X11, pour être en Wayland "pur". Dans ce cas, on tomberait effectivement dans le cas décrié par ses devs.
Nota : KiCad a l'air d'être un monstre, j'ai pas les compétences pour le recompiler et être sûr. Mais Xwayland n'est pas près de disparaître !
# Utilisation au quotidien de labwc
Posté par impromptux . Évalué à 4 (+4/-0).
Je suis passé d’Openbox à Wayfire il y a quelques mois puis, très rapidement après, je suis passé de Wayfire à labwc en passant à Debian Trixie. J’ai été agréablement surpris par ce compositeur, pour moi il est très proche d’Openbox par sa philosophie: légèreté, complètement personnalisable, stabilité(contrairement à Wayfire),etc. Il ajoute cependant plusieurs fonctionnalités intéressantes en plus de la sécurité apportée par Wayland comme la possibilité de forcer les applications à utiliser des décorations côtés client (y compris celles qui utilisent cette horreur qu’on appelle LibAdwaita).
Le seul problème que j’ai rencontré lors de la transition à Wayland était que la barre des taches de LXQt que j’utilisais jusque-là n’est pas compatible avec Wayland(en théorie si mais l’affichage est cassé et elle ne supporte pas les tray icons). Je suis donc passé à Waybar avant de m’apercevoir qu’elle bouffait à elle seule 10% du CPU et je suis passé à xfce4-pannel qui fonctionne parfaitement sous Wayland(à part un comportement un peu étrange avec les boutons des fenêtres auxquels on finit par s’habituer). Toutes les applications que j’utilisais avant fonctionnent parfaitement, celles de Xfce comme celles de LXQt, et presque aucune n’utilise Xwayland.
[^] # Re: Utilisation au quotidien de labwc
Posté par Tarnyko (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 15 décembre 2025 à 22:01.
Ahhhhh, un utilisateur de labwc. Enfin, j'en ren-contre un \o/ !
Alors justement ! J'ai constaté que beaucoup utilisent effectivement la décoration "serveur" fournie par labwc ; c'est agréable car c'est fonction absente sous GNOME p.ex. (qui a beaucoup poussé les décorations exclusivement clientes).
Mais du coup, comment ça se change, pour les tests ? Je connais la variable dédiée aux applis GTK (un truc finissant par "_CSD") mais y a un switch global dans la config labwc ?
Ah xfce4-panel… l'article le montrait à la base, et il est encore supérieur à Cairo-Dock ! Je l'ai juste dégagé à cause de sa dépendance à GTK3 -et pas grand-chose de plus, faut bien l'avouer.
[^] # Re: Utilisation au quotidien de labwc
Posté par impromptux . Évalué à 2 (+2/-0).
Il est possible de préférer les SSD ou CSD en modifiant rc.xml.
(C’est du XML, il faut remplacer [ et ] par < et > et imaginer l’indentation, car linuxFR ne me laisse pas mettre de XML)
Au contraire, on peut préférer les CSD en remplaçant 'server' par 'client '.
On peut forcer les SSD même pour les applications qui ne les acceptent pas :
Mais dans ce cas, les bouton de contrôle prévu pour les CSD resterons présents aussi sur l’application. Pour empêcher ça on peut les supprimer avec
[^] # Re: Utilisation au quotidien de labwc
Posté par Tarnyko (site web personnel) . Évalué à 2 (+0/-0).
Merci beaucoup ! Je teste ça ASAP 🙂
[^] # Re: Utilisation au quotidien de labwc
Posté par BAud (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 18 décembre 2025 à 08:39.
bien sûr que si, la preuve :
je te laisse parcourir l'aide édition pour découvrir toutes les autres possibilités de mise en forme.
Tu pourras démontrer ta compréhension en copiant-collant ton 2ème exemple (correctement cette fois-ci sans t'embêter à
sed 's/</[/g'nised 's/>/]/g'). Tu pourras vérifier la coloration syntaxique avec le boutonPrévisualiser)Si tu y arrives, tu me devras une bière et des explications de pourquoi tu n'y arrivais pas précédemment.
Si tu n'y arrives pas, tu me devras une bière et tu peux simplifier la page wiki pour indiquer ce qui permettrait de comprendre comment y arriver.
[^] # Re: Utilisation au quotidien de labwc
Posté par Tarnyko (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 18 décembre 2025 à 14:19.
Le sacrifice de la bière c'est sacré… sois pas trop dur avec @impromptux, il vient de me filer un bon coup de main ☺️.
[^] # Re: Utilisation au quotidien de labwc
Posté par Tarnyko (site web personnel) . Évalué à 2 (+0/-0).
Merci, c'est la version moderne de ce que je cherchais :).
Je constate par exemple que Foot (le terminal de l'article) ne dessinant jamais de CSDs, il se retrouve sans rien :D
C'est grâce à lui et d'autres applications comme Chromium que j'ai constaté que ce règlage où le compositeur fournit ses décorations ("SSD") s'est répandu un peu partout… c'est intéressant, je vais essayer d'ajouter un exemple qui en tire parti !
# A la fois super et dommage
Posté par AlexTérieur . Évalué à 3 (+2/-0). Dernière modification le 15 décembre 2025 à 21:56.
J'ai suivi longtemps l'"aventure Wayland" et cherché les solutions pour des config "minimale" mais moderne quand même… à l'époque j'ai bidouillé sur un RPi, et la seule solution c'était Enlightenment… Ils commençaient à développer un support Wayland, et même que Samsung avait développé leur interface Android à base des bibliothèques EFL (fondement de l'environnement Enlightenment)… Aujourd'hui, le support Wayland d'Enlightenment est resté "expérimental" (sic), et au passage Samsung a abandonné Tizen…
J'avais bien entendu connaissance de "Weston" mais c'était longtemps décrit comme un projet "exemple" et pas comme un véritable DM…
Je trouve que Wayland a raté le virage des supports de type "tablettes" et autres appareils tactiles… Cela lui aurait donné une légitimité de plus pour remplacer X11…
[^] # Re: A la fois super et dommage
Posté par Tarnyko (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 15 décembre 2025 à 22:21.
Oh, tu sais… je connais très bien Tizen 😉.
Tel quel, ce n'est effectivement pas un vrai DM ; il est surtout réellement exploitable (et exploité) dans l'embarqué.
En dehors de la Raspberry Pi qu'il est la 1ère plate-forme à avoir spécifiquement supporté ("rpi" était un backend dédié avant que son driver s'améliore), il sert aussi de bac à sable à l'automotive avec IVI-Shell qui en réalité l'implémentation d'un standard industriel COSEVA.
Perso j'ai surtout bossé surtout sur lui, et comme je l'aime bien vais sûrement le refaire ; j'ai bien vu que trop peu l'utilisent comme DM faute de modules, et je pense qu'il y a un truc à faire là…
Ah ça, les tablettes, les téléphones (typiquement ce que Tizen essayait de faire)… c'est une occasion manquée du Linux "libre" et standardisé face à une certaine variante 😈. J'ai un avis dessus ici d'ailleurs…
[^] # Re: A la fois super et dommage
Posté par Trollgouin . Évalué à 3 (+2/-0).
En téléphonie, tu as lipstick, compositeur de Nokia, Intel puis SailfishOS / Jolla qui est basé sur QtWayland.
Ça marche même bien d'ailleurs :)
# Digne successeur d'OpenBox sous Wayland
Posté par Nibel . Évalué à 5 (+3/-0). Dernière modification le 20 décembre 2025 à 12:56.
J'utilise labwc depuis la 0.5.3 après avoir été fidèle pendant une dizaine d'années à OpenBox, c'était pas tout à fait ça au début mais aujourd'hui c'est parfaitement utilisable au quotidien.
Je suis un amoureux d'OpenBox, extrêmement léger et modulaire et en tant que joueur, je voulais aller gratter quelques % de FPS en passant sous Wayland. J'ai donc cherché un OpenBox-like sous Wayland et clairement labwc en est le digne successeur.
A tel point qu'il supporte les fichiers de configuration d'OpenBox, ce qui m'a permis de migrer relativement facilement.
Je le couple avec swaybg pour la gestion du fond d'écran et waybar comme panel-bar et j'ai un environnement ultra-minimaliste et frugale en consommation de ressources qui répond parfaitement à mon besoin.
Je ne le conseillerais pas à tout le monde, il faut aimer mettre un peu les mains dans le cambouis pour le paramétrage et aimer les environnements plutôt minimalistes. Mais si vous êtes déjà un convertis d'OpenBox (ou FluxBox) et que vous voulez migrer de X11 vers Wayland, vous pouvez foncer tête baissé.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Digne successeur d'OpenBox sous Wayland
Posté par Tarnyko (site web personnel) . Évalué à 3 (+1/-0).
Hello, autre héraut de labwc !
Je viens d'essayer la WayBar ; j'aimais moins son look de base, mais je constate qu'elle est thémable à mort et qu'on peut en faire quasi ce qu'on veut… à condition de plonger dans ses arcanes (c'est pour ça que je ne l'avais pas sélectionnée pour l'article : je voulais un truc simple).
Clairement !
Je dirais que ça s'applique même à tous ceux qui utilisaient des WM alternatifs, sauf s'il existe une alternative encore plus fidèle (comme wlmaker pour… WindowMaker ;) ).
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.