Journal Paramétrer Wayland et WebRender pour Firefox sur ma distrib

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
19
27
mar.
2020

Bonsoir Nal,

Bon, de temps en temps je regarde où en est ma distrib par rapport aux dernières technos upstream, histoire de vérifier que ça ruisselle bien.

Pour faire « court », je suis sous Debian Sid GNOME-Wayland.

Voici les quatres points que je vous propose :

  • Travailler dans une session Wayland
  • Activer le procédé d'accélération WebRender pour Firefox
  • Passer Firefox en mode Wayland
  • Couper le cordon entre GNOME et X11

Travailler dans une session Wayland

Normalement, à partir de Debian 10 Buster, GNOME-Wayland est la session par défaut.

Pour rappel le choix entre GNOME-Wayland et GNOME-X11 se fait à l'ouverture de la session (par la petite roue crantée à côté du bouton « Se connecter »). Sous une version récente de Debian, choisir « GNOME » revient à choisir GNOME-Wayland (au contraire de « System X11 Default » ou « GNOME sur Xorg »).

Pour le vérifier, plusieurs méthodes :

  • aller dans « À propos » via les « Paramètres » de GNOME et regarder ce qui est indiqué en face de « Système de fenêtrage »
  • taper dans un terminal $ echo $WAYLAND_DISPLAY et voir si vous obtenez wayland-0
  • tenter la commande restart dans la boite Alt+F2 : ce devrait être refusé.

Activer le procédé d'accélération WebRender pour Firefox

Dans la barre d'adresse de Firefox, taper about:config et passer la clé
gfx.webrender.all sur true si ce n'est pas déjà le cas.

Sur GNU/Linux l'accélération matérielle étant désactivée par défaut, il peut être nécessaire de passer également la clé layers.acceleration.force-enabled à true pour ne pas bloquer WebRender (pas sûr que ce soit toujours nécessaire).

Redémarrer le navigateur.

Pour le vérifier, dans about:support, la ligne « Composition » doit indiquer « WebRender »

Passer Firefox en mode Wayland

Par défaut sous Debian Firefox est toujours en mode X11 et se lance donc à travers XWayland.

Plusieurs avantages accompagnent la version Wayland.

Deux hypothèses :

Pour utiliser ponctuellement Firefox en mode Wayland :
$ MOZ_ENABLE_WAYLAND=1 firefox

Pour utiliser tout le temps Firefox en mode Wayland :
Modifier le lanceur /usr/share/applications/firefox.desktop en ajoutant env MOZ_ENABLE_WAYLAND=1 à la ligne Exec=/usr/lib/firefox/firefox %u, comme ceci : Exec=env MOZ_ENABLE_WAYLAND=1 /usr/lib/firefox/firefox %u

Pour le vérifier :

  • regarder dans about:support où la ligne « Protocole de fenêtrage » devrait indiquer « wayland » au lieu de « x11 ».
  • dans un terminal, taper $ xlsclients : Firefox ne devrait plus figurer dans la liste des applications utilisant XWayland.

(idem pour Thunderbird : $ MOZ_ENABLE_WAYLAND=1 thunderbird ou modification du lanceur /usr/share/applications/thunderbird.desktop – sauf si vous utilisez la version Flatpak)

Couper le cordon entre GNOME et X11

Il s'agit d'une fonctionnalité expérimentale introduite avec GNOME 3.34.

Après avoir configuré mes lanceurs de Firefox et Thunderbird comme indiqué ci-dessus, voici ce que me renvoie encore la commande $ xlsclients :
HAL gnome-shell
HAL ibus-x11
HAL gsd-xsettings

Pour que XWayland ne se lance pas inutilement au démarrage, il faut ajouter la clé autostart-xwayland dans org.gnome.mutter experimental-features ce qui peut se faire avec la commande suivante :
$ gsettings set org.gnome.mutter experimental-features "['autostart-xwayland']"

Bon, chez moi cela n'a pas marché et $ xlsclients continue de me renvoyer le même résultat.

Et vous ?

  • # Non activé par défaut sur Fedora

    Posté par  . Évalué à 6.

    Merci pour ton journal, j'ai voulu vérifier sur ma distro, donc Fedora… qui a fait de Wayland son faire valoir depuis 2-3 versions (et Firefox on Wayland par défaut sur la dernière). Surprise, l'accélération matérielle n'est pas activée par défaut sur Firefox ! Sachant que je suis sous pilotes libres.
    Grâce à tes explications, j'ai activé et wow ! C'est parfaitement fluide, plus de tearing, affichage du contenu instantané lorsqu'on déroule ou change d'onglet.

  • # Pour KDE sous Mageia Cauldron

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

    Il faut installer 

    # urpmi plasma-workspace-wayland

    puis relancer KDE (5.18.3 sous Cauldron) en choisissant dans sddm "Plasma (Wayland)" et suivre les instructions du journal.

    Résultat : ça doit dépendre lourdement de la carte graphique car ce n'est pas foufou sous KDE, j'utilise un contrôleur intégré Intel.

    Kwin est en retard sur Wayland, il y a des bug graphiques lorsque l'on passe les fenêtres les unes sur les autres, style le z-index est au fraise. Il faudrait tester avec un autre gestionnaire de fenêtre purement Wayland (Sway ou Weston). Ou Gnome bien sûr.

  • # Ha si ça marche peut-être, en fait

    Posté par  (site web personnel) . Évalué à 6. Dernière modification le 27 mars 2020 à 10:55.

    Avec la config du journal, $ xlsclients ne répond plus du premier coup, je suis obligé de saisir la commande une deuxième fois.
    Du coup je me suis dis : "Si ça se trouve c'est moi qui lance XWayland avec cette commande ?"

    D'où l'idée de vérifier si les 3 lignes de résultat de $ xlsclients sont une conséquence de cette commande (=est-ce que l'observateur serait en fait acteur) et/ou de vérifier autrement si XWayland est lancé.

    Je viens de vérifier : le processus xwayland n'est effectivement plus lancé avec ma listé dans la liste de processus actifs du système, donc cela marche pour moi.

    Du coup je me demande comment interpréter le résultat de la commande $ xlsclients ?

    • [^] # Re: Ha si ça marche peut-être, en fait

      Posté par  . Évalué à 1.

      Sauf erreur, le compositeur Wayland se contente de créer la variable DISPLAY=:0 et le pipe correspondant dans /tmp/.X11-unix/X0. Quand le premier client essaye d'ouvrir le pipe pour parler au serveur X, le compositeur démarre XWayland.

      Et dans ton cas, le premier client est effectivement xlsclients. Ton compositeur possède probablement une option pour désactiver totalement XWayland.

      • [^] # Re: Ha si ça marche peut-être, en fait

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 27 mars 2020 à 20:19.

        Oui, je viens de regarder : $ xlsclients démarre XWayland

        Du coup à part les bogues signalés ci-après c'est cool :)

      • [^] # Re: Ha si ça marche peut-être, en fait

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 27 mars 2020 à 21:10.

        Carlos Garnacho me confirme tout ceci :

        the on-demand feature reacts to anything that comes up over the X11 display socket, that includes xlsclients requests to introspect the running clients (even though it's a CLI command itself). All those services are brought up just-in-time because X11 clients are typically UI applications, although it's not the case here :).

        However, mutter looks for existing X windows, and also shuts Xwayland down (and those extra services) some seconds after the last one disappears. So I also expect xlsclients to bring up Xwayland and misc. x11 services briefly.

        Et il me dit souhaiter que la fonctionnalité soit prête pour GNOME 3.38.

  • # Sélectionner-coller à la souris

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

    À propos de Wayland, c'en est où, le sélectionner-coller à la souris ? Est-ce que ça fonctionne dans tous les logiciels, y compris les clients X11?

    • [^] # Re: Sélectionner-coller à la souris

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

      Moi ça marchait entre gedit (wayland) et firefox (x11) par ex

      • [^] # Re: Sélectionner-coller à la souris

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 27 mars 2020 à 11:29.

        Je confirme que ça fonctionne également ici, sous Arch, tant entre clients Wayland qu'entre Wayland et X11. De la même façon, wl-clipboard-x11 permet de coller sous wayland les éléments copiés avec les outils en ligne de commande de X11. Je m'en sers pour pass par exemple - pour une raison que j'ignore, "pass -c" (qui permet de copier un mot de passe dans le presse-papier) ne fonctionne pas sans ce paquet.

        Edit: Pour ce que cela vaut, j'utilise sway/wlroots, pas GNOME/Mutter.

    • [^] # Re: Sélectionner-coller à la souris

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

      PS : J'ai un gestionnaire de presse papier, je ne sais pas si ça change qqch
      http://libre-ouvert.toile-libre.org/index.php?article178/mes-extensions-pour-gnome-shell-starring-clipboard-indicator

    • [^] # Re: Sélectionner-coller à la souris

      Posté par  (Mastodon) . Évalué à 3.

      Sous gnome je n'ai pas observé de problème particulier en dehors de copier/coller entre linux et une session citrix mais je ne suis pas sûr que ça marcherait mieux sous x11 et je n'utilise plus citrix maintenant.

    • [^] # Re: Sélectionner-coller à la souris

      Posté par  . Évalué à 3.

      J’ai entendu parlé de ça aussi, mais j’ai toujours eu deux buffers différent pour « sélection/molette » et « ctrl-c/ctrl-v » (comme sous X11 quoi).

      J’utilise régulièrement xclip aussi (je sais pas si c’est vraiment couplé à X11 ou pas) et j’ai vu aucun problème non plus.

      Par contre j’utilise alacritty et j’ai déjà remarqué que souvent mes copier/coller depuis ou vers le terminal ne fonctionnait pas toujours (comme si le fait de copier n’avait pas marché) et je dois refaire la manipulation. C’est d’autant plus chiant que ça m’est déjà arrivé de coller 50 lignes de texte dans IRC en voulant y coller 2 mots.

  • # Tiens, du coup j'ai débusqué un bogue concernant LibreOffice-Flatpak

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

    Bug 131623 - (LibreOffice-Flatpak) LibreOffice doesn't start as long as Xwayland is not running
    https://bugs.documentfoundation.org/show_bug.cgi?id=131623

  • # Typo

    Posté par  . Évalué à 1.

    Petite typo :

    « vosu » à la place de « vous » dans « Voici les quatres points que je vosu propose : »

    Merci pour le journal. :)

  • # Plein écran

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

    Merci pour le journal. J’ai essayé et je trouve le comportement de la souris assez différent - je pense vite m’habituer.

    Par contre, j’ai un bogue de plein écran avec Netflix qui ne couvre que la fenêtre, et pas la barre d’onglets

  • # Problèmes identifiés

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

    J'en ai profité pour essayer également Wayland, avec le compositeur Sway, qui est un équivalent du gestionnaire de fenêtres i3. Voici les problèmes que j'ai identifiés.

    Le HiDPI

    HiDPI, c'est un genre de nom marketing pour des écrans avec une définition supérieure à 96 ppp. C'est le genre de truc qui ne devrait poser aucun problème, X11, et a fortiori Wayland, étant censément capables de connaître non seulement la résolution, mais également les dimensions physiques des écrans. Cela fait belle lurette qu'on peut choisir des fontes en points – pour rappel, un point c'est une dimension physique, correspondant à 1/72 de pouce – et non en pixels.

    Seulement, pour des raisons qui me sont incompréhensibles, c'est en fait un problème, ce qui me donne bien l'impression que c'est un problème qu'on a créé en considérant cela comme quelque chose de différent de ce qui existait.

    Bref, sous X11, le HiDPI n'est pas un problème, les différentes bibliothèques d'affichage étant capables d'afficher des polices avec une taille physique déterminée, au prix éventuel d'un petit réglage manuel – qui devrait être inutile, puisque, encore une fois, elles peuvent très bien déterminer la définition de l'écran sans action de l'utilisateur.

    Sous Wayland, ça demande encore une fois un réglage manuel, qui devrait également être inutile mais qui a l'avantage d'être indépendant des bibliothèques d'affichage. Avec i3, ça se fait dans la définition des sorties, en indiquant un facteur d'échelle :

    output * scale 1.6

    Ça fonctionne impeccablement pour les logiciels qui utilisent Wayland. En revanche, pour les logiciels qui utilisent X11, donc le serveur intermédiaire XWayland, ça effectue un zoom matriciel, ce qui est assez affreux et pas du tout satisfaisant.

    Visiblement, ce qui se fait habituellement pour obtenir un résultat satisfaisant, c'est donc de ne pas définir ce facteur d'échelle, et de configurer individuellement les bibliothèques d'affichage Wayland et X11.

    Les combinaisons de touches

    Ça, c'est une problème que je me crée tout seul. Sous X11, j'ai choisi d'utiliser XbindKeys pour lancer des logiciels par combinaison de touches. L'intérêt, plutôt que de définir ces raccourcis dans la configuration de mon gestionnaire de fenêtres, c'est que c'est justement indépendant de celui-ci.

    Le problème donc, c'est qu'il n'existe à ma connaissance pas d'équivalent pour Wayland. Je vais donc revenir à la définitions de raccourcis clavier dans la configuration du compositeur.

    • [^] # Re: Problèmes identifiés

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

      Dans les fonctionnalités expérimentales sous GNOME 3.34, à côté de “autostart-xwayland”, j'ai :

      “scale-monitor-framebuffer” — makes mutter default to layout logical monitors in a logical pixel coordinate space, while scaling monitor framebuffers instead of window content, to manage HiDPI monitors. Does not require a restart. •

      Je ne sais pas si ça peut t'aider

    • [^] # Re: Problèmes identifiés

      Posté par  . Évalué à 1.

      Sway est très utilisable même si il reste de nombreux petits bugs. Par exemple, j'ai récemment remarqué qu'avec Sway 1.4, Firefox perd occasionnellement le focus du clavier. Il suffit alors de changer de bureau virtuel pour le récupérer. Il s'agit en fait d'un bug relatif à XWayland.

      J'en ai alors profité pour activer le backend Wayland de Firefox. Il était encore difficilement utilisable il y a juste quelques semaines mais, dans l'ensemble, Firefox 74.0 semble plutôt robuste en mode Wayland.

      Je n'ai noté qu'un seul petit bug agaçant sur le site du Crédit Agricole. Pour des raisons de sécurité, cette banque n'utilise pas le gestionnaire de mots de passe de Firefox mais la page d’authentification propose quand même un menu avec les numéros de comptes (probablement mémorisez dans des cookies). Or avec Firefox Wayland, ce menu reste invisible dans 90% des cas et s'il y a bien un truc que je n'ai pas envie d'avoir à me rappeler c'est mon numéro de compte bancaire. C'est assez représentatif des bugs que l'on peut encore rencontrer avec Wayland.

      Pour info, ma solution à ce petit problème consiste à ouvrir une seconde fenêtre et à alterner la souris entre les deux fenêtres jusqu'à ce que Firefox réussisse à afficher le menu. J'ai aussi noté que le menu même invisible reste accessible avec le clavier.

      J'ai aussi remarqué que Firefox X11 et Firefox Wayland n'utilisent pas le même protocole pour ouvrir les URLs. Par exemple, cela signifie que cliquer sur un lien dans Thunderbird ne fonctionnera que si celui ci utilise le même backend que Firefox. J'imagine que le problème existe aussi avec d'autres applications.

    • [^] # Re: Problèmes identifiés

      Posté par  . Évalué à 2.

      Concernant l'absence d'application équivalente à Xbindkeys, il est fort possible que cela n'arrive jamais car le protocole Wayland n'autorise pas ce genre "d'espionnage" du clavier. Chaque application ne reçoit que les évènements concernant ses propres fenêtres.

      Des applications comme xeyes ne peuvent donc pas fonctionner correctement avec Wayland. En fait, toutes les fenêtres des applications X11 sont gérées par le processus XWayland donc xeyes semble marcher tant que la souris se trouve sur une fenêtre X11.

      Différentier les applications X11 et les applications Wayland n'est pas toujours facile. Avec Sway, j'utilise l'astuce suivante pour configurer différemment la barre de titre de chaque fenêtre:

      for_window [shell="xdg"] title_format '<span color="#00AA00">[%app_id]</span> <span color="#FFAA00">%title</span>'
      for_window [shell="xwayland" ] title_format '<span color="#00AA00">[X11]</span> <span color="#FFAA00">%title</span>'

    • [^] # Re: Problèmes identifiés

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 31 mars 2020 à 15:53.

      GTK+3

      Un autre truc marrant, lorsqu'une session X11 et une ou plusieurs sessions Wayland sont ouvertes, d'où qu'on lance un logiciel qui utilise GTK+3, il s'affiche dans la session première session Wayland. C'est un beau bug dans son genre, ça.

      • [^] # Re: Problèmes identifiés

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

        J'ai été un peu plus loin. J'ouvre une session X11 DISPLAY=:0, puis une session Wayland WAYLAND_DISPLAY=wayland-0, puis une seconde session Wayland WAYLAND_DISPLAY=wayland-1.

        Dans cette situation donc, lorsqu'on lance n'importe quel logiciel qui utilise GTK+3, par exemple gnome-terminal ou LibreOffice, peu importe d'où on le lance, il s'affiche dans la session WAYLAND_DISPLAY=wayland-0.

        Maintenant, je ferme la première session Wayland WAYLAND_DISPLAY=wayland-0, de sorte qu'il ne reste plus que deux sessions, une X11 DISPLAY=:0 et une Wayland WAYLAND_DISPLAY=wayland-1. Maintenant, où qu'on lance un logiciel en GTK+3, d'où que ce soit, il s'affiche dans la session X11 DISPLAY=:0.

        Je n'ai pas encore essayé en fermant également la session X11, mais il va falloir que je regarde. Ça promet !

    • [^] # Re: Problèmes identifiés

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 12 avril 2020 à 00:40.

      je te réponds pour les combinaisons de touches.

      En ce qui me concerne sous X11 j'avais programmé une combinaison de touches pour gérer la rotation de l'écran : horaire, anti-horaire.

      Sous Wayland il a d'abord fallu que la fonctionnalité soit réimplémentée, ce qui a été fait via le Centre de contrôle de GNOME 3.22 (sous Matériel→Écrans).

      Mais pas de commande utilisable pour associer à une combinaison de touches.

      Voici l'échange que j'avais eu alors avec Carlos Garnacho :

      Q: With GNOME-X11 I used to assign screen rotation commands ("xrandr -o normal" and "xrandr -o left") to Keyboard Shortcuts. Could you please tell me what are the corresponding commands with GNOME-Wayland ?

      A: There is currently no easy way to do that from the command line, you could use the gdbus CLI tool to send messages to the org.gnome.Mutter.DisplayConfig interface [1], but the content of the messages is somewhat setup dependent, as the configuration for all monitors is sent in one go.
      A more… engineered option is doing a python script (or any with gobject-introspection binding support) using the libgnome-desktop API available for output configuration, which is the same than gnome-control-center uses. Perhaps libgnome-desktop should provide a small utility tool itself, although in honesty I wouldn't like seeing people take it as a drop-in replacement to xrandr.
      Oh, also, GNOME does already honor the key(s) mapped to XF86RotateWindow, toggling across all rotations in the main output, it's unfortunate that we don't offer configuration for mapping that action to other keybinding though…

      Q: If I understand correctly there is no easy way to get that on GNOME-Wayland ?

      A: Right, just not yet… I'm sure some command line tool will appear to compensate somewhat for the lack of xrandr for wayland, there's just been more crippling bugs to focus on :).

      Enfin, l'an dernier j'en ai fait part à Hans de Goede, de Red Hat, qui a semblé retenir ma demande dans le cadre du The Wayland Itches project.

      En attendant j'utilise une extension pour GNOME Shell : Display Button, qui offre un accès rapide aux réglages d’orientation de l'affichage.

      Je ne sais pas si ces pistes pourront se servir…

  • # Désactiver la fonctionnalité expérimentale XWayland sur demande

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

    Au fait, pour revenir à la situation par défaut :

    $ gsettings set org.gnome.mutter experimental-features "[]"

Suivre le flux des commentaires

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