Résoudre les problèmes de Microsoft Teams avec KDE sous Linux

Cet article a été publié il y a 3 ans 7 mois 11 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Microsoft a mis à disposition il y a plusieurs mois déjà son client Teams pour les linuxiens. Il est très proche fonctionnellement de la version Windows, avec aussi peu de réglages que son homologue, et son statut de preview fait qu’il est souvent à la bourre sur les toutes dernières évolutions introduites dans le client. Il a aussi d’autres problèmes qui dépendent de l’environnement de bureau dans lequel vous tournez, et ça a été mon cas avec KDE.

KDE mon amour (je l’ai déjà faite, non ?)

KDE, c’est l’environnement qu’on dit sympa pour les nouveaux utilisateurs parce que proche de Windows. Alors les gens qui disent ça n’ont soit pas vu un Windows depuis longtemps, soit jamais utilisé KDE non plus. Parce que l’environnement qui repose sur le toolkit graphique Qt est un bordel sans nom tellement il est configurable dans tous les sens. J’en utilise moi-même probablement qu’un petit tiers des capacités, et ce nombre est probablement surestimé.

Je l’ai quand même sélectionné quand j’ai basculé mon laptop pro sous Linux, j’en avais parlé, parce que maintenant que la génération 5 avait maturé, je me suis dit que ça serait suffisamment stable et je voulais voir ce qu’ils en avaient fait après avoir apprécié la version 4. Globalement, c’est fluide, en fonction des thèmes c’est visuellement proche d’un Windows mais avec quelques spécificités parce que bon sinon ça serait pas KDE (pour ceux qui veulent vraiment mimer y’a l’incognito mode de Kali :D). C’est un environnement plaisant dont j’ai pu modifier les aspects que je voulais pour le rendre plus fluide pour mes besoins, et c’est finalement ce qu’on demande en priorité à son environnement de bureau.

Malgré tout, sur le Latitude 5470 j’ai quand même eu quelques galères. La consommation mémoire est déjà un peu élevée, genre 800Mo à froid, sans rien de chargé. Ensuite, en fonction des mises à jour j’ai déjà eu des soucis avec des freezes de l’écran de verrouillage. Comprenez que l’image est figée à l’écran, mais la souris bouge, et si on saisit le mot de passe au clavier, ça fonctionne, juste on ne le voit pas. Et ça, aussi bien sur le noyau d’origine à l’installation (4.19 LTS) que celui que j’ai sélectionné après, le 5.4 LTS. La solution était de rebasculer sur un TTY, et de revenir sur la session graphique pour qu’il reprenne le dessin. Bizarre autant qu’étrange, mais c’était limité au login screen.

J’ai quand même pris un peu de temps pour chercher un peu. Kwin, qui est le composant responsable du dessin de tout ça, et qu’on appelle à juste titre compositeur de fenêtres, dispose lui-même, à l’image du reste de l’environnement, de pas mal de réglages, sur les effets, et aussi sur un point important, le mode de rendu. Chez moi, et je n’ai aucune idée de pourquoi, le mode de rendu sélectionné était OpenGL 2, alors que le pilote et le GPU intégré supportent, au moins sous Linux, OpenGL 3.3+ depuis la génération Haswell, c’était en 2014. Vérification faite, depuis cet été Intel a validé OpenGL 4.6 pour tout ce qui est Broadwell+, ce qui est le cas de Skylake. Et dans les options proposées, je n’ai qu’un OpenGL 3.1. J’ai donc tenté le coup, c’est plus stable effectivement, mais rien de révolutionnaire sur la consommation CPU ou RAM. Moins de bug, c’est toujours ça.

Ça n’empêche pas de temps en temps d’avoir un énorme message d’erreur sur fond noir me disant qu’il faut déverrouiller la session via la ligne de commande dans un TTY justement, ceci dit c’est assez rare pour ne pas poser plus de problème que ça.

Tu voulais pas nous parler de Teams ?

Alors pourquoi je m’attarde sur tout ça ? Déjà pour dire que l’environnement sur lequel il s’exécute a déjà quelques soucis graphiques avérés au moins par le passé. Ensuite parce qu’évidemment, avec une utilisation toujours plus poussée de Teams voire même une utilisation exclusive depuis quelques mois maintenant, je ne peux pas me permettre d’avoir un outil non fonctionnel. Certains éléments ne dépendent pas de moi, comme la téléphonie, dont la procédure de migration que j’ai pu lire me donne encore des migraines tellement elle est complexe par rapport aux tests du début qui fonctionnaient bien mais qui, selon Microsoft, posaient « des problèmes de sécurité ». Pour d’autres c’est lié à mon PC et lui seul, donc autant chercher à agir.

En dehors d’une consommation CPU et RAM démesurée qui est régulièrement pointée du doigt et qui ne semble pas la priorité de Microsoft (ajouter les fonds custom sur les visio et les grilles 3×3 « à la Zoom », c’est tellement plus important), le principal problème que j’ai rencontré est pratiquement impossible à capturer et visible uniquement par mes interlocuteurs : le partage d’écran « clignote », et on voit régulièrement des bouts de fonds d’écran par dessus les fenêtres, ce qui est particulièrement désagréable pour eux. Au début justement je pensais que c’était dû à l’OpenGL 2, mais le passage à OpenGL 3.1 n’a rien réglé. Je me suis dit que j’étais maudit, j’ai repensé au fait qu’Electron, qui est le framework applicatif utilisé pour développer Teams, repose sur Chromium, qui n’utilise pas Qt mais GTK comme toolkit. Possible, après tout Pierre-Marie qui va me faire payer une taxe à chaque fois que je le cite l’utilise sans souci avec Cinnamon, même si lui utilise la version non-officielle, donc la version d’Electron pourrait jouer.

Au passage dans les recherches, je vois que la consommation CPU peut être un peu réduite en désactivant l’accélération matérielle. Me demandez pas pourquoi mais c’est vrai, j’ai décoché l’accélération matérielle, redémarré l’application et ça va un peu mieux. Ça reste toujours Bagdad sur le Core i5 en conférence audio/vidéo, mais bon, le reste du temps, c’est à dire au « repos » il est beaucoup plus calme. Mais rien de mieux sur le partage d’écran qui clignote toujours. Et en continuant de chercher, je finis par retomber sur cette histoire de mode de rendu.

En effet, j’ai évoqué différentes versions d’OpenGL, mais il existe une dernière option pour Kwin qui s’appelle Xrender. Ce mode de rendu historique remonte à 2001 et déjà à l’époque permettait d’exploiter les capacités d’accélération des cartes graphiques pour s’occuper d’un ou plusieurs aspects de l’environnement de bureau. Il est toujours supporté sur les installations récentes qui reposent encore sur X.org, et c’est mon cas. Certains semblent avoir réussi à calmer les glitches du partage d’écran avec, et comme je n’avais aucune information sur le fait que ça pourrait faire mal au CPU et/ou à la RAM, j’ai tenté.

Eh ben devinez quoi, c’est la solution ! Donc pour avoir Teams + KDE + x  = partage d’écran, x = Xrender. J’étais content, j’allais pouvoir repartager mon écran facilement, c’est d’autant plus important en ces temps de télétravail continu.

Le retour de la vengeance des bugs bizarre de KDE

Et oui, tel un Jason Voorhees qu’on croit mort et qui revient toujours, un nouveau bug encore plus étrange est venu se mettre en travers de ma route : de manière très aléatoire, même si je pensais à un lien direct avec Teams, ce n’est plus l’écran de verrouillage qui freeze mais le bureau, carrément ! Je peux encore basculer entre les fenêtres avec Alt+Tab, mais plus question d’utiliser le menu KDE ou la barre des tâches. Et même certaines fenêtres finissent par un peu souffrir et freezer elles aussi. La solution trouvée sur un forum est de « tuer » plasmashell et de le relancer dans la foulée. Ce qui fonctionne, mais pour un temps plus ou moins limité avant de devoir recommencer.

Retour donc dans les méandres de la recherche sur le web, pour découvrir que cette fois-ci, c’est la combinaison Xrender + noyau 5.14 qui semble problématique, et que 4.19 permettra de retrouver sa stabilité. Au point où j’en étais j’ai tenté. Et au bout d’une semaine sans freeze avec moults partages d’écrans et sessions audio/vidéo Teams, force est de constater que le résultat est là. Le prix à payer est que les noyaux plus récents disposent d’améliorations de performances et/ou d’autonomie qui ne sont pas critiques non plus, surtout en ce moment où le laptop est constamment relié au secteur.

Un possible basculement sur XFCE ?

Par rapport à ce que j’utilise de KDE, franchement je me pose la question. la version 4.14 a amélioré son support GTK 3, qui est le toolkit sur lequel repose la majorité de mes applications en dehors de KeepassXC et VLC. Firefox, Thunderbird, LibreOffice, Sublime Text, Terminator, Teams, la liste n’est pas complète mais vous avez l’idée. Le problème, c’est que pouvoir basculer dessus demande tellement de changements sur le système que je me demande comment je vais procéder, la réinstallation étant probablement le mieux.

En attendant, j’ai retrouvé une stabilité nécessaire, ce qui une fois de plus nous montre bien que non, « Linux » c’est pas pour tout le monde, quelque soit la qualité du matériel.

PS : j’ai écrit cet article au mois de mai, il se trouve qu’entre temps, j’ai découvert une conséquence malencontreuse, à savoir que docker est cassé dans ce contexte, depuis la dernière mise à jour de Docker il y a une régression qui casse le dossier /var/run quand on tente un pull. Les détails et malheureusement la solution inapplicable dans mon cas sont à consulter dans cette issue. Une raison de plus pour passer sur container dockerless ?