Reprise du message précédent :
On ne recommande pas amdgpu ? Sauf vieille carte graphique

Portable : ATI Radeon Mobility HD 4530 (oui, ça s’appelait encore ATI quand je l’ai eu, en juillet 2009)
Fixe : AMD Radeon R7 240
 
Si celle du fixe pourrait utiliser AMDGPU (elle est compatible avec les deux pilotes), c’est pas le cas de celle du portable.

Tout s'explique, j'avais fait la recherche au tout début où j'installais Arch.
 
D'ailleurs pour le moment toujours mon fidèle Arch sur un PC portable, je teste une fois Fedora que je n'ai pas testée depuis 2 ans sur un autre portable identique, et Debian sur mon PC de jeu.
 
Verdict dans quelques semaines, mais pour l'instant je trouve toujours Arch à mon usage plus sympa. Juste quelques trucs qu'on trouve en officiel sous Debian et qu'en AUR sous Arch, style TeamViewer et Horizon Client

SurfaceGo 1 pas mise sous tension depuis la mi-novembre, mise à jour 2 minutes, reboot quand même et ok.
 
Franchement par rapport à mon PC Windows 11 pas utilisé depuis le 2 décembre, qui a fait 3 malheureuses mise à jour Windows, je dois encore faire un coup dans le store et dans Winget, Arch c'est quand même vraiment bien

 
Je découvre ça
 
https://www.phoronix.com/news/AMDVLK-Discontinued
 
En réinstaller un PC AMD Zen2 sous Arch, je m’apprêtais à installer Steam et je vois plus vulkan-amd, mais que Radeon    
 
Je tente avec celui là, les autres n'ont rien à voir  

 
Le noyau 6.18.3 est sorti : il semblerait que le bug avec le pilote AMDGPU soit toujours présent d'après le forum Arch Linux (écran noir avec l'affichage qui ne répond plus lorsqu'on lit en mode plein écran une vidéo youtube avec Firefox, un bug aléatoire), je suis donc resté à la version 6.17.9.
 
 
Je remarque aussi ce bug avec Plasma 6.5.4-1 et Qt6 6.10.1-1 sur Arch Linux (quelle que soit la version du noyau Linux) :
 
- ouvrez un programme utilisant Qt (comme l'éditeur de texte Kate, ou LibreOffice Writer qui peut aussi utiliser les boites de dialogue de Qt6)
- tapez du texte
- allez dans le menu "fichier, enregistrer sous"
- choisissez un emplacement dans la boite de dialogue qui apparaîtra
- cliquez sur le bouton "enregistrer" pour sauvegarder le fichier
 
Vous remarquerez alors que le programme semble se figer pendant une seconde, et on peut lire la mention "ne répond pas" dans la barre de titre du programme, puis ensuite le fichier s'enregistre bien.
 
Le problème ne se produit pas si on travaille sur un fichier existant (qui ne nécessite pas d'afficher la boite de dialogue d'enregistrement de fichier), un clic sur l'icône "disquette" de la barre d'outils pour sauvegarder le fichier permettant d'éviter d'afficher la boite de dialogue Qt6 d'enregistrement de fichiers.
 
En gros le simple fait d'afficher la boite de dialogue d'enregistrement de fichiers de Qt6 (ou celle de Plasma basée sur Qt6) peut entrainer ensuite une latence/freeze d'une seconde du programme quand on clique sur le bouton d'enregistrement de cette boite de dialogue.  
Si j'utilise un programme basée sur GTK alors je n'ai pas le souci.
 
Je ne sais pas si ça vient de ma configuration (j'utilise le thème Oxygène de Plasma), ou si c'est vraiment un bug de Plasma/Qt6 généralisé à toutes les configurations possibles.

J'ai tenté la manip décrite avec Kate, aucun souci (plasma avec le thème Breeze sombre).
 
J'ai par contre toujours le bug de sortie de veille (pas prolongée, juste veille écran) depuis les noyaux 6.18.x, qui reactive pas ma sortie HDMI, obligé de passer sur un autre tty avec un raccourci clavier puis revenir sur celui de l'interface graphique pour retrouver mon image.

En effet ça vient bien du thème Oxygen, car si j'utilise le thème Breeze alors la latence disparait au moment d'enregistrer le fichier.
 
Pour ton problème de bug de sortie de veille c'est bizarre, normalement il est censé avoir été résolu avec les derniers noyaux Linux.
 
C'est peut-être un autre bug, moi quand j'avais le bug je ne pouvais même pas ouvrir une console tty, l''écran ne voulait pas sortir de veille, la seule solution était de débrancher le cable HDMI, puis de le rebrancher, ça permettait au système de re-détecter l'écran.

Alors certes, il y en a sûrement plusieurs...
Mais un bug qui était très pénible a été enfin backporté en 6.18.3 (le fix date de v6.19-rc1...)
commit ede98c3943cd6141b6657e23b03a5ca838d3e8e4 drm/amd/display: Use GFP_ATOMIC in dc_create_plane_state()
Chez moi ce bug provoquait des bluescreens (ceux avec le QRcode de 3km de large) avec un stacktrace sur une fonction d'alloc un peu aléatoirement.

Perso avec ça de corrigé, je n'ai plus aucun problème avec amdgpu (et une 7900)

Ah tiens en effet j'ai un truc qui ressemble à ça....
J'ai essayé de remonter la piste mais j'arrive pas encore à déterminer d'où ça vient.
Moi c'est un peu différent, j'ai 2 écrans en DP. Quand les écrans passent en veille (ou xset dpms force off) ensuite ils mettent quasiment 20 secondes à se rallumer, peut-être plus.
J'attribuais ça à Xorg, mais sans vrai preuve... Je crois que même les vieux noyaux me le font, or toi tu sembles ne voir ça que sur 6.18 ?
 
Et si tu attends 20 ou 30 secondes ils reviennent pas dans ton cas ?
Tu es sur X ou wayland ? Quel GPU ?

Wayland et gpu Amd récent (9070xt)
J'ai essayé d'attendre, mais mon écran (TV LG 42C2) reste en mode veille jusqu'à ce que je bascule de tty.

 
Correction : finalement ça ne vient pas du thème Oxygen, mais d'un fichier de configuration corrompu de Qt,
 
en supprimant le fichier QtProject.conf dans /home/*/.config le problème disparait .
 
Ce fichier faisait 128 Mo, en le supprimant Qt6 le recrée, et il fait maintenant 108 octets.

Python 3.14 est arrivé sur le canal stable sur Arch Linux, en même temps que le noyau Linux 6.18.4. Préparez-vous à un gros téléchargement pour les mises à jour !

Ca passe pas inaperçu en effet, 232 paquets alors que ma mise à jour précédente datait de ce matin

Oui : tous les paquets qui dépendent de Python ont dû être recompilés en fonction de cette version 3.14. C’est pour ça que ça fait depuis la mi-décembre que certains attendaient dans les dépôts Testing. Ils ont pas forcément été mis à jour eux-mêmes, mais leurs paquets devaient être refaits parce que Python, lui, l’a été.

Petit joueur

Tiens d'ailleurs, à ce propos, vous mettez à jour à quel rythme et quel(s) jour(s) ?
 
Moi je mets à jour 1 fois par semaine le vendredi soir (histoire de pouvoir réparer durant le WE puisque j'utilise ce PC pour le boulot )

pas con

Tous les matins, sauf exception.

Au moins à chaque fois que je démarre mon PC donc 1 fois le matin et 1 fois le soir. Parfois plus, on sait jamais

Tous les matin de la semaine sur le pc du taf, et tous les soirs sur mon desktop perso.

J’ai très longtemps fait le matin (entre 9h30 et 10h, en gros), tous les jours. Et parfois à 12h30 sur le fixe familial quand il fallait ensuite redémarrer.
 
Mais depuis l’été dernier, je tends à les faire la nuit, avant d’éteindre pour aller me coucher. Mais il y a maintenant quelques fois où je peux décider d’attendre quelques jours avant de les faire, parce que j’attends celle de paquets bien précis pour les faire (c’est arrivé récemment, quand j’attendais une MAJ du noyau pour installer celle de mkinitcpio, histoire de ne pas avoir à régénérer les initramfs tous les jours ; mais vacances obligent, l’attente a duré bien une semaine).
 
Donc, actuellement, c’est : toutes les nuits avant d’éteindre, sauf exceptions où les machines ne se porteront pas plus mal de rester sur les versions actuellement installées quelques jours de plus.
 
Au passage : toujours pas de nouvelles de Thunderbird 146 ? Ça fait un peu un mois qu’il est sorti et qu’on l’a toujours pas vu pointer le bout de ses octets sur Arch…

J'ai pas regardé en détail mais y'a un soucis de signature du livrable côté Thunderbird donc Arch risque de zapper la 146.0 et passer directement à la prochaine (146.0.1) : https://gitlab.archlinux.org/archli [...] ote_376991

Ou, plus probablement, la 147… Perso, c’est ce que je pense de plus en plus.

Si vous ne l'aviez pas vu, un possble remplacement de pacman: ALPM (pour Arch Linux Package Management), écrit en rust
https://itsfoss.com/news/pacman-rust-treatment/

Pacman c'est plus sympa qu'ALPM

Je ne pense pas que ce soit spécifique à Arch, mais j'ai un petit souci un peu agaçant depuis quelques temps avec KeepassXC : il reverrouille la base de données de mots de passe tout seul au bout d'un moment, d'une façon qui semble aléatoire, souvent au bout de seulement quelques minutes. Ce n'est pas une mauvaise configuration de ma part, vu que ça ne le faisait pas avant et que je n'ai pas modifié la conf. Chez vous aussi ?

Pas de souci ici sur le pc du taf avec KeepassXC que je déverrouille après ouverture de ma session et dont la base reste déverrouillée tant que ma session est ouverte.

En fait je viens de voir que l'option "Verrouiller la base après X secondes d'inactivité" (15 minutes) était activée, mais elle a du s'activer toute seule après une MAJ ou quelque chose.

Ayant attendu que le noyau 6.18.5 arrive en stable, j’ai donc procédé à la grosse MAJ cette nuit. Sur le portable, ça a été dans les 250 paquets pour 1,4 Gio à télécharger. Installation en presque 12 minutes avec Core 2 Duo et HDD. Merci, Python 3.14 !
 
(Un poil moins sur le fixe avec presque 7 mn 30, car celui-ci n’a pas Wine d’installé, ni le dépôt Multilib activé)
 
Enfin, maintenant, le Wi-Fi interne du portable remarche avec le noyau 6.18 !