Reprise du message précédent :
edit: trompage de topic.

Tu peux supprimer tes messages via l’icône et choisir « Effacer ce message » en bas de la zone de texte…

 
Oui je sais.  

 
Y'en a qui tournent sous Wayland et qui utilisent Zoom ? Sur mon laptop pro sous Arch + plasma Kde, impossible malgré toutes les manips vue sur les wiki et forums, le client plante juste après l'authentification pendant l'affichage de la page d'accueil.
 
Tout le reste fonctionne très bien, et zoom fonctionne très bien sous xorg bien sur.

Je suppose que tu as déjà suivi le wiki officiel d'archlinux sur zoom, il y a un paragraphe qui concerne wayland :
https://wiki.archlinux.org/title/Zoom_Meetings

Il faudrait regarder du coté du SAV de Zoom, faire remonter l'information aux développeurs de Zoom, qui est un logiciel propriétaire :
https://support.zoom.us/hc/fr

La consultation des fichiers log (dmesg, journalctl) peut aussi aider à y voir plus clair sur la cause de l'erreur, tu peux aussi lancer le client desktop depuis une console, pour voir s'il y a des messages d'erreur utiles, l'application Zoom stocke son fichier log dans le chemin /home/user/.zoom/logs/zoom_stdout_stderr.log,

comme Zoom n'est pas un logiciel libre ça réduit considérablement la marge de manoeuvre pour l'utilisateur (pas de possibilité de patcher, recompiler).

Idéalement il faudrait que les auteurs de Zoom publient une version web HTML5/javascript, pour que ça fonctionne dans un navigateur, comme ça fini les problèmes de compatibilité d'API graphique, d'OS, leur concurrent Teams a une version web par exemple.

Merci pour cette réponse détaillée

Effectivement j'ai suivi le wiki concernant le sujet, le plus étonnant est qu'une release note indique que le partage d'écran fonctionne sousbwaylande depuis juin 2022, donc le client devrait fonctionner...

Je vais chécker les logs pour voir mais un démarrage depuis la console ne m'a rien indiqué de plus.

À force de batailler, j'ai enfin zoom qui fonctionne sous Wayland correctement, j'avais remarqué que l'appli plantait lors du chargement du panneau latéral de l'appli, du coup j'ai ouvert l'appli sous ma session X11, désactivé le panneau latéral, puis quand j'ai rouvert l'appli sous Wayland, plus de crash ...
 
C'était la seule appli qui m'obligeait à rester sous X11, plus besoin maintenant

Depuis une mise à jour récente j'ai remarqué que la barre des tâches de plasma pouvait se corrompre un boot sur deux, on voit des motifs carrés bleus aléatoires (bleu si votre fond d'écran est bleu) dans la barre des tâches :

En se déconnectant et en réouvrant la session plasma le problème disparaît.

J'utilise le thème oxygen, le pilote radeon (pour une vieille carte graphique radeon HD4650), il est possible que ça vienne du paquet sddm, depuis sa mise à jour je remarque que le curseur de souris n'apparait plus à la fin des messages de systemd au boot, mais dans un écran noir dédié (juste après la fin des messages de systemd), mais ça peut aussi venir du pilote radeon ou de plasma.

Avec le même pilote, sur ma Radeon Mobility HD 4530, j’ai aussi des problèmes de gitchs visuels sur Vivaldi (depuis la version basée sur Chromium 102) et le client Discord quand je laisse la rasterisation GPU activée. Ça disparaît si je change (temporairement) le thème de bureau, et j’ai dû désactiver cette rasterisation depuis les flags de Vivaldi pour que ça ne se produise pas. Se contenter de désactiver l’accélération matérielle dans ces logiciels ne suffit pas (en fait, c’est pas cette accélération le problème, mais bien la rasterisation).
 
De ton côté, et si ça arrive sur Plasma sans application particulière ouverte, faut voir comment désactiver ça, sans forcément couper tout le compositeur d’affichage.

C'est un bug vraiment bizarre ces glitchs visibles que sur la barre des tâches de plasma,

j'ai voulu tester avec un autre compte utilisateur : j'ai le même souci avec un profil plasma vierge et cette fois sans utiliser le thème oxygen (ça utilise par défaut le thème breeze),
souvent le bug disparaît après une déconnexion/reconnexion à plasma, pour revenir aléatoirement au prochain boot.

Puis j'ai testé avec le noyau linux-lts 6.1.38-1 et là je n'ai pas réussi à provoquer le bug (malgré plusieurs redémarrages), dans la foulée je ré-essaye le noyau linux 6.4.1-arch2-1 et je n'ai pas encore eu le bug (mais ça ne veut rien dire, tellement il est aléatoire).

Ces glitchs quand ils apparaissent : ils restent là pendant toute la session plasma dans la barre des tâches, et ne vont pas migrer sur d'autres zones de l'écran, et quand ils disparaissent (après une reconnexion ou un reboot) on est tranquille pendant toute la durée de la session plasma, jusqu'au prochain boot.

Il est possible que ça vienne du pilote radeon, c'est du RV730 que j'ai sur ma carte graphique radeon HD4650.

Suite du bug :

- j'ai essayé le boot non graphique, en utilisant "startx" au lieu de "sddm" : même souci,

je me demande aussi si le problème ne serait pas en fait matériel, ma carte graphique étant vieille (14 ans), ce qui est bizarre c'est que le bug disparait après une déconnexion/reconnexion de la session plasma, il n'est pas permanent, si c'était un souci matériel alors le bug serait tout le temps présent et pas aléatoire.

J'ai ouvert un rapport de bug sur le site de plasma, mais sans grande attente sur sa résolution.

Te déconnecter rafraîchit surement l'écran et ca repart de 0, peut-être que sans un truc bogue et le carré n'est jamais enlevé par la suite. Je dirais de tenter sur autre chose que Plasma pour voir si c'est Plasma, ou tu peux aussi tenter avec d'autres pilotes pour voir si ca vient de la (le ddx modeset au lieu d'ATI par example, pour le module noyau ca dependra de la carte.)

Merci pour ces idées je vais tenter ça  ,
 
je vais essayer de trouver un live cd linux avec autre chose que plasma comme bureau pour tester.

Pour info le bug des glitchs sur la barre des tâches de plasma (quand on a une vieille radeon de la fin des années 2000) semble résolu depuis un "pacman -Syu" fait vendredi soir.

Ça fait 2 boots que je n'ai plus le problème.

Les mises à jour de paquets qui ont peut-être résolu le problème :

- linux (6.4.4.arch1-1 -> 6.4.6.arch1-1)
- mesa (23.1.3-2 -> 23.1.4-2)

Ah ? Je verrai ça la prochaine fois que je lancerai l’appli Discord, lors d’une réunion de mon asso qui requerra ma présence… Ou si je réactive la rasterisation GPU dans Vivaldi.
 
Après, ce serait super cool si le problème que j’avais avec Stellarium (écran qui ne cesse de clignoter, rendant ce logiciel totalement inutilisable), ou avec des jeux Windows lancés sous Wine comme Operation Flashpoint (où les sprites 3D étaient totalement déformés), était corrigé lui aussi…

Toujours pas de glitchs 4 jours après avoir constaté la disparition du bug (suite à la mise à jour du noyau linux et de mesa).

Il est possible que tes problèmes avec ta vieille radeon soient résolus, ou grandement réduits.

Salut, lors de la mise à jour j'ai des soucis de signature, que peut-on faire pour régler ça ?

C'est plus grave que prévu, la commande "pacman-key --populate archlinux" ne passe pas.

Je vais chercher un peu maintenant que j'ai une piste.  
 
edit : Je crois que c'est bon, j'ai réalisé cette manip après avoir re-effacé consciencieusement le répertoire "/etc/pacman.d/gnupg" :
 

NB : j'ai remis "pacman.conf" comme à l'origine après l'installation de "archlinux-keyring".
 
  merci pasta_gars, tu m'a mis sur la bonne voie .
 

Ça me semble bizarre ton problème, je n'ai jamais eu à changer la valeur par défaut de SigLevel, ni à effacer de répertoire "/etc/pacman.d/gnupg", ni à taper des commandes de type pacman-key (ou alors j'ai dû le faire qu'une seule fois, lors de l'installation d'archlinux), au pire si un paquet refuse de s'installer pour des problèmes de signature alors il me suffit d'installer la dernière version du paquet archlinux-keyring, qui va automatiquement après mettre à jour le trousseau de clés.
Un service systemd existe aussi pour mettre à jour périodiquement les clés, sans avoir besoin d'attendre la mise à jour du paquet archlinux-keyring.

À voir si ton problème ne cache pas un autre plus grave, de type corruption de données, suite à un SSD qui commence à avoir trop de secteurs défectueux, on peut le savoir en consultant les données SMART, via un outil présent dans le paquet smartmontools.

A priori le disque n'a pas de problème, je viens de vérifier.
 
C'est venu comme ça sans que je bidouille en faisant une maj en revenant de vacances. Mais j'avais peut-être fais des bêtises bien avant !
 
Je n'avais pas le paquet "archlinux-keyring" et je ne connaissais pas.
 
Après avoir supprimé le répertoire "/etc/pacman.d/gnupg", je ne pouvais plus rien installer ou mettre à jour. En modifiant le fichier de conf, j'ai pu installer "archlinux-keyring" et refaire les clés.

La sale surprise du jour : les paquets xflux et xfluxd (version Linux de f.lux et un paquet permettant de le lancer automatiquement en tant que service utilisateur) ont été dégagés d’AUR !

Heureusement que j’ai pu les retrouver avec Internet Archive et les recompiler (et les mettre en lieu sûr). Mais même s’ils n’ont plus eu (besoin ?) de mise à jour, ni de mainteneur depuis longtemps, j’en ai besoin, moi : j’aime pas le rendu de RedShift (trop rouge par rapport à l’orangé de xflux que je préfère) !

Le dépôt git des paquets supprimés reste accessible: 'git clone https://aur.archlinux.org/xflux.git' fonctionne toujours.
Peut-être ces paquets avaient-ils été marqués orphelins avant suppression ?
Tu peux toujours en demander la maintenance  en tout cas, c'est encore la meilleure façon de t'assurer qu'ils resteront dispos
https://wiki.archlinux.org/title/Ar [...] m_the_AUR?

L’adresse est valide, mais elle renvoie sur une 404. Donc, non.

Pardon, j’avais pas vu le « git clone ». OK, c’est récupéré et recompilé.
 

Comme j’ai dit dans mon message précédent : oui, ça faisait longtemps qu’ils avaient été marqués comme orphelins. Mais vu qu’ils ne nécessitaient manifestement aucune maintenance, ils pouvaient rester en l’état.
 

Merci de te proposer !
 
Même si ce ne seraient pas les plus compliqués à gérer, je considère que maintenir des paquets, c’est un métier. Et outre le fait que mes compétences archiennes se limitent à pouvoir compiler des PKGBUILD déjà prêts (mais pas vraiment à en créer : j’ai essayé, ça n’a pas bien marché), ou éventuellement les corriger localement pour des logiciels qui n’avaient pas encore été mis à jour dans les dépôts (OpenTTD, quand le mainteneur était en vacances et que j’avais besoin de la toute dernière version pour une partie en réseau local), mon métier est de corriger les annonces à publier de mon association.

C'est plus un passe-temps qu'un métier je pense, du moins on n'est pas souvent remunerer pour en maintenir.

Bah, t’as bien compris que je veux dire que ça peut à l’occasion nécessiter davantage de compétences et de temps que de simplement se contenter d’incrémenter des numéros de version dans un PKGBUILD déjà établi.

Ah ca c'est certain, c'est pour cela que j'ai des paquets non mis à jour depuis des mois, j'ai peu de temps dernièrement et pas envie de le passer comme cela... En contrepartie quand j'avais le temps ca m'a permit d'avoir du code dans des projets importants pour réparer le paquet...

J'ai un disque dur externe Toshiba USB de 2 To, le fabricant l'a formaté par défaut en NTFS,
est-ce qu'il vaut mieux le reformater avec le système exFAT ?

Je lis souvent qu'il est préférable d'utiliser exFAT sur les périphériques externes USB (carte mémoire, disque dur externe), mais dans l'univers linux est-ce aussi le système de fichier le plus adapté pour les périphériques de stockage USB ?

Si tu arrives à l’utiliser tel quel sur tous tes appareils, je te dirais de ne pas te prendre la tête avec ça et de ne pas y toucher.

Moi aussi mes DD externes (je parle des WD Elements et ne jure plus que par ça) me sont parvenus préformatés en NTFS, et même en mode GPT. Tu sais quoi ? Ils le sont toujours et j’ai eu zéro souci avec. L’avantage du NTFS étant aussi qu’on peut passer ses volumes en mode lecture seule pour éviter que des maladroits ou malveillants puissent supprimer des fichiers ou formater le volume. Si tu veux faire de l’archivage, c’est plus qu’intéressant. Hélas, cette restriction ne fonctionne que sous Windows, les volumes en question étant toujours accessibles en écriture sous Linux.

Sinon, exFAT présente surtout un intérêt par rapport à FAT32, dont il repousse certaines des limitations. Mais par rapport à NTFS, il serait plutôt une grosse régression (pas de gestion des droits d’accès, pas de chiffrement ou de compression intégrés au FS…).

À voir aussi comme critère la résistance à la fragmentation pour le choix du système de fichiers.
Je remarque aussi que exFAT n'est pas sensible à la casse pour le nom des fichiers (majuscules/minuscules), ça peut poser problème pour la copie à l'identique du contenu d'un dossier.
 
Je vais donc par prudence rester en NTFS sur ce disque dur externe.

 
Dites, y'en a qui ont des problèmes avec le bluetooth depuis les noyaux 6.4.x ?
 
Avec mon portable du taf (puce bluetooth Intel AX201) j'ai des soucis depuis les noyaux 6.4.x, impossible d'appairer mon clavier BT par exemple, et de temps en temps impossible d'avoir de l'audio avec mon casque Bose (la c'est plus aléatoire, mais j'ai l'impression que le problème a disparu depuis que j'ai réinitialisé les paramètres de pipewire). Par contre ma souris Logitech fonctionne très bien dessus en BT.
 
En attendant j'ai branché un dongle USB (reconnu comme un Cambridge Silicon), sur lequel j'ai réussi à appairer mon clavier, mais ce périph BT ne démarre pas automatiquement après boot (malgré un AutoEnable=true dans /etc/bluetooth/main.conf, qui à priori ne démarre même pas la puce Intel intégrée, vu que ma souris ne fonctionne pas sur l'écran de login SDDM), donc je suis obligé de me logguer sous SDDM avec le clavier du portable, puis ensuite d'aller activer le dongle à la main pour pouvoir utiliser mon clavier (la puce intégrée s'active automatiquement après le loggin par contre)
 
Des idées ? Ou j'attends la dispo du noyau 6.5 pour voir si ça corrige les soucis ?
 
J'ai fouillé le wiki Arch et les forums sans trouver de solution pour l'instant.
 
Edit : précision, je sous sous KDE Plasma avec une session Wayland.
 
Edit² : log de tentative d'appairage sur la puce intégrée  

 
Alors qu'avec le dongle pas de souci d'appairage et de connexion ensuite.
 
Edit³ : passage sur le kernel 6.5 en testing, ça change rien

Je ne m'en sers jamais, mais quand j'ai voulu lancer le gestionnaire Bluetooth Blueman, j'ai eu ça :

edit : Kernel: x86_64 Linux 6.4.12-arch1-1 | DE: KDE 5.109.0 / Plasma 5.27.7

Bluez n'a pas été démarré, nécessaire à la gestion du BT.
 
Sinon je continue mes investigations, j'ai désactivé le BT interne pour ne laisser que le dongle, mais le périph ne s'active pas au démarrage, si après m'être loggué à ma session, obliger d'aller l'activer manuellement dans les paramètres bluetooth

Pas vraiment du Arch, mais je me suis dit que ca pouvait intéresser certains ici.
 
J'ai finalement regardé les outils de dédoublements pour btrfs, mais ca n'a pas forcément l'air 100% positif... Et puis ca prend pas mal de temps. Je me suis tourné vers fclones a la place, avec lequel je dédouble non pas les blocs mais les fichiers, ce qui me suffit je pense; fclones remplace les données des copies avec reflink donc pas de soucis si dans le futur les copies ne devaient plus être parfaites. Sur un système de fichiers sans reflink des liens standards peuvent être utilisés.

ah oui, j'ai démarré manuellement le service et ça semble aller, du moins avec mon téléphone, j'ai que ça sous la main.

Suite des mes soucis de BT : En repassant sur une session Xorg, le BT s'active correctement à l'ouverture de session, et tous mes périph s'y connectent correctement. C'est déjà mieux que sous Wayland, et accessoirement je retrouve Xscreensaver qui me manquait sous Wayland
 
Reste juste le souci de la page de login (sddm), sur laquelle je ne peux pas saisir mon user/pass avec mon clavier BT car le BT n'est toujours pas activé avant d'ouvrir ma session
 
J'ai bien mis le paramètre AutoEnable=true dans le /etc/bluetooth/main.conf, mais ça ne fonctionne toujours pas.
 
Des idées ?

contenu du dmesg pour la partie BT :

 
Je vois rien de spécial (à part le "Bad flag given ...", je sais pas si ça a une incidence)... Et je sais pas ou chercher ailleurs (apdmc) ...
 
 
Edit : j'ai l'impression que systemd a du mal a démarrer le service :

 
Ça peut être du à ça ?

Bon trouvé, un paramètre à la con que j'avais mis dans le /etc/bluetooth/main.conf    
 
Lors de mes tests pour essayer d'utiliser le chip BT intégré du laptop avec mon clavier, j'avais mis l'option ControllerMode = dual, en remettant par défaut, ça re-fonctionne correctement, allez savoir pourquoi ^^
 
Plus de souci de bluetooth sur le dongle avec ça, il s'active correctement avant d'arriver sur la page de login sddm

hum, petit problème avec les kernels 6.5 ici ...
 
Quand je reboot, ben ça reboot pas du tout, ça reste sur un écran noir...
Et idem si je shutdown, ben en fait ça fait toute la procédure jusqu'au dernier message où normalement le PC s'éteint, là la LED reste allumée, ventilateur soufflant et ne s'éteint jamais ... obligé de poweroff à la barbare (5s sur le bouton power) ...
Du coup suis repassé sur le dernier 6.4
 
D'autre ont un pb avec ces kernel ?

Pas ici, non… Si tu donnes ta config, ça pourrait peut-être donner des pistes ?

Dell Inc. OptiPlex 7040
Intel® Core™ i7-6700T × 8
Intel® HD Graphics 530 (SKL GT2)
 
Sous Gnome 44.4, ça le fait avec les 2 kernels 6.5 (le .2 et .3)
Besoin d'autres infos ?