Tarnyko a écrit 616 commentaires

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é 😎.

Ok donc c'est bien ce dont je me dputais !

Ah ? Alors ça… ça a l'air de faire le café ! (noté pour plus tard)

la seule solution c'était Enlightenment… Ils commençaient à développer un support Wayland […] resté "expérimental" (sic), et au passage Samsung a abandonné Tizen…

Oh, tu sais… je connais très bien 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…

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à…

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…

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…

Ahhhhh, un utilisateur de labwc. Enfin, j'en ren-contre un \o/ !

comme la possibilité de forcer les applications à utiliser des décorations côtés client

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 ?

je suis passé à xfce4-pannel qui fonctionne parfaitement sous Wayland

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.

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 😄 !

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.

Tout à fait !

Mais bon, j'ai aussi du mal à croire que rester sur Xorg soit une solution d'avenir à long terme.

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 !

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…

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…

Ah cool le 1er, on dirait une outil vraiment universel ! Par contre Tanguy a besoin de n'enregistrer qu'une fenêtre, je suppose qu'au niveau GPU ça ne peut marcher que tant qu'il ne la déplace pas ?
(je vais essayer après ;) )

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 ?

This functionality was omitted by design, not oversight.

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 ?

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 !

wf-recorder est buggé ?

C'est possible j'avoue, j'ai pas essayé la partie "son" dont j'ai pas l'utilité hors OBS… je pense qu'il faudrait que j'essaie en m'approchant de ta config :

• une lecture en cours (sur VLC ou Celluloid typiquement) ;
• une sortie son virtuelle ;
• les codecs AV1 et Opus (j'utilise plutôt le H.264 et AAC en général ; je commencerai par eux pour voir si c'est pas lié).

En fonction de ça et mon temps dispo je te ferai un retour… je vois que tu as des contacts affichés donc ça devrait pas être trop dur 😉.

C'est 2 philosophies différentes en fait (j'ai aussi OBS d'installé ; je l'utilise en "client lourd interactif", jamais essayé de scripter le bousin).

Peut-on dire qu'OBS est plus pratique en ponctuel, et que la ligne de commande serait plus adaptée à un cron p.ex.?

Ffmpeg n'a pas de module d'enregistrement natif PipeWire.

J'aurais dû lire ton comm' avant mon propre commentaire ci-dessous… bon à savoir, même si ça arrivera forcément un jour (tu peux ignorer cette partie du coup !).

Passionnant, merci ! J'ignorais l'usage du module PulseAudio ; PipeWire en direct ce serait intéressant, si la couche de compat' avec PA fait défaut un jour (mais là j'en suis encore à m'habituer…).

Je réagis sur :

À noter qu'on peut très facilement lancer de façon semblable un compositeur Wayland dans une fenêtre, mais que l'enregistrement d'un affichage Wayland est moins bien supporté : je m'en tiendrai donc à Xephyr.

Normalement la partie vidéo c'est couvert par cette section du billet (l'outil utilise aussi FFmpeg en interne).
Après il resterait à réunir les 2 flux.

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éfinissant WAYLAND_DISPLAY (l'équivalent de la variable DISPLAY sous 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, systemd dé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)?

Ne pas avoir d’équivalent à xrandr est un grave problème qui rend Wayland inadapté à mon flux de travail.

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…. ?

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.

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.

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 !

Hello Meku ; alors :

$ wlr-randr
compositor doesn't support wlr-output-management-unstable-v1

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 ?

Aux modérateurs, cette section:

---

Fedora 42 (mise à jour)

Vérifiez que vous avez bien wlroots 0.19 :

pkg-config --modversion wlroots-0.19
# 0.19.2

---

devrait en fait être :

---

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 meson

Vérifiez que vous avez bien wlroots 0.19 :

pkg-config --modversion wlroots-0.19
# 0.19.2

---

Merki 😀

Hello, quand tu dis que ça ne "lit plus", parles-tu plutôt de :
- l'affichage "brut" du contenu du DVD dans l'explorateur de fichiers ;
- la lecture DVD-Vidéo (effectuée avec un logiciel dédié, p.ex. VLC) ?

Murena, j'ai bien mais effectivement il reste un fork d'Android mais sans les codes googles.

/e/OS donc ; c'est ce que j'utilise.

Pour moi, après l'établissement du duopole actuel, c'est le meilleur possible. Un "ordiphone" ayant d'autres formats d'applis, un autre SDK… ça a été tenté plein de fois, et c'est voué à l'échec : sauf dans le cas d'un marché contrôlé, ou s'il fournit lui-même un bon émulateur Android (ce sur quoi j'avoue pas être très au jus).

Parmi les compositeurs minimaux, Weston est le plus simple puisqu'il arrive prêt à l'emploi (un terminal, un lanceur, un lock screen, un enregistreur d'écran, RDP…).
L'inconvénient est qu'il n'est pas très modulaire : on peut retirer ces choses, mais pas en ajouter ; et les modules externes pour lui sont rares (j'étais justement l'un des rares).

Les mini-compositeurs basés sur wlroots suivent en général l'optique inverse : ils arrivent avec quasi-rien (typiquement un menu-clic-droit à la TWM) mais s'appuient sur un écosystème de clients dont les privilégiés utilisent leur protocole "wlr" : n'importe quel terminal compatible, lanceur avec waybar / Cairo-Dock, lock screen avec swaylock, capture d'écran avec wf-recorder…

Je trouve que tu as là une bonne alternative décrite ; et comme les autres, ne pourrai te renseigner davantage avant d'en savoir plus ;).