Reprise du message précédent :
GNOME 3.20 arrive dans stable..... par petits morceaux

Ça aurait peut-être plus sa place sur un topic Linux généraliste mais comme j'utilise Arch je me permets de poser ma question ici: avez vous déjà essayé des solutions comme celles-ci?
Edit: c'est pour monter des partitions linux sous windows... plutôt que de faire chier avec l'inverse  

Maj de LibreOffice fresh aujourd'hui, je le lance, ça y est l'ascenseur est bien affiché sur l'interface d’accueil ... j'ouvre un fichier et la c'est le drame, c'est moche et ça marche toujours pas
Bizarre ce comportement

Ext2Fsd marche bien même sur du ext4

Pour le theme breeze GTK, y'a un PKGBUILD qui marche avec GTK 3.20 ici: https://github.com/Martchus/PKGBUIL [...] t/PKGBUILD

Je suis le seul a avoir des polices floues (notamment dans Konsole) apres upgrade de font-config a la version 2.11.95-1?
Un downgrade corrige le probleme pour moi.

pas de soucis chez moi,

mais j'utilise un fichier de configuration personnalisé pour fontconfig ( ~/.config/fontconfig/fonts.conf )

affichage de type 5/4 sur un écran LCD 19 pouces 1280x1024 pixels, les polices de caractères sont nettes

Une belle astuce qui m’a bien servi, même si j’ai adapté le mien comme suit :

(En gros : hintslight au lieu de hintfull et lcdlight au lieu de lcddefault ; certains trouveront ça trop baveux mais je trouve que c’est plus joli comme ça ; évidemment, à chacun son réglage favori).
 
Par précaution, pour éviter les mauvaises surprises, j’ai mis le fichier en lecture seule. Ça devrait protéger d’éventuels changements à cause de mises à jour de Fontconfig.

je viens de remarquer un bug étrange qui touche l'affichage, il y a une corruption d'affichage qui se produit de manière aléatoire :
 
- de manière aléatoire sous plasma 5 le premier pixel de mon écran LCD devient tout blanc ( coordonnées x;y : 0;0, c'est le tout premier pixel en haut à gauche de l'écran )
 
- lorsque ce pixel devient blanc permanent alors le simple fait de changer de console ( ctrl - alt - f2 ) puis de revenir dans la session X ( ctrl - alt - f1 ) permet de résoudre le problème, le pixel redevient actif,
 
donc ce n'est pas un problème de pixel défectueux, mais bien un problème logiciel lié peut-être à mesa ou à Xorg,  
 
ce problème est apparu depuis dimanche ( ou lundi je ne sais plus ), quand j'ai fait un "pacman -Syu", à ce moment là il me semble avoir vu une mise à jour de mesa et d'un pilote libre lié à xorg et amd,
 
j'ai une radeon HD 4650 pcie et j'utilise le pilote libre radeon,
 
suis-je le seul à avoir remarqué une corruption d'affichage ?
 
ou bien c'est mon matos qui est train de tomber en panne ( carte graphique, mémoire vidéo, pixel défectueux de mon écran  ? )
mais ce serait étonnant que ce soit un pixel défectueux car le simple fait de relancer la session graphique ou de changer de console permet de faire disparaitre la corruption d'affichage
 
ça fait penser à ce vieux bug :
 
https://bugs.launchpad.net/ubuntu/+ [...] bug/944701
 
je soupçonne mesa 11.2.0-1, il fait partie du lot des mises à jour que j'ai eu dimanche dernier :
 

j'ai posé la question sur les forums anglais et français d'archlinux, des forumeurs me confirment qu'ils ont aussi remarqué ce problème il y a 3 jours lors de la mise à jour de mesa vers la version 11.2.0-1, un pixel blanc tout en haut à gauche de l'écran,

mais un autre qui a ce problème pense que ça peut venir aussi de gtk3 et de firefox,

j'ai crée un rapport de bug sur le site d'archlinux mais je devrais peut-être aussi en créer un sur le site de mesa,

c'est un bug aléatoire dont je n'ai pas réussi à trouver le moyen de le déclencher, je sais juste qu'il apparait après avoir ouvert un certain nombre de programmes et au bout d'un certain nombre d'heures dans la session X,

un bug assez dangereux dans le sens où il fait penser à un pixel défectueux/chaud sur l'écran, ça risque d'inciter les gens à masser leur écran pour faire ressusciter/débloquer le pixel ( l'autre technique consistant à utiliser un logiciel qui fait défiler des couleurs à l'écran ), ils vont paniquer ( trop forte pression sur l'écran --> création de vrais pixels défectueux cette fois ! ) et penser que leur écran est mourrant alors que c'est pas le cas

le problème semble avoir disparu depuis la mise à jour de firefox vers la version 45.0.2-1

La version 364.16 du driver nvidia est disponible avec le début de support du Kernel_mode_setting.
Voir : https://wiki.archlinux.org/index.ph [...] de_setting
https://wiki.archlinux.org/index.ph [...] de_setting

Pour mon probleme de font, j'ai du passer hintstyle a hintmedium.
Merci pour l'aide

Des personnes ont testé Mate 1.12 avec Gtk3 d'activé ?
Voir içi : https://www.archlinux.org/groups/x86_64/mate-gtk3/

Non, je suis toujours sur la version classique, et pas envie de tester, vu ce qu'on peut lire sur le wiki :

Ok merci  avec un gros retard

Bon ça y est, j'arrive à avoir mon splash screen Plymouth en version nickel, non-dégradée, en 2560x1440 avec les pilotes propriétaires nVidia (dernière version, celle qui supporte KMS). C'est cool.

Cool  
 
Un petit détail de la méthode ? ça m'intéresse

https://wiki.archlinux.org/index.ph [...] de_setting

- Ajouter nvidia-drm.modeset=1 en paramètre du noyau (dans /etc/defaut/grub)
- ajouter nvidia, nvidia_modeset, nvidia_uvm and nvidia_drm dans la ligne "Modules=" de /etc/mkinitcpio.conf (penser à regénérer l'initramfs)
- avoir Grub dans la bonne résolution du moniteur et mettre "keep" pour la résolution du noyau (ligne "GRUB_GFXPAYLOAD_LINUX=keep" de /etc/default/grub) afin de conserver la même résolution de Plymouth (et bien sûr, avoir mis "quiet splash" en paramètre noyau).

Ok,  merci, du coup n'étant pas sous grub mais sous syslinux, c'est encore possible ?

J'en sais rien, je connais pas syslinux, mais s'il propose les mêmes options que Grub, alors je vois pas pourquoi non.

Merci je vais checker ça

Mouais c'est nul, c'est que pour le paquet nvidia, pas pour les anciennes versions (340xx pour ma part)

Heureusement que j'ai précisé "la dernière version, celle qui supporte KMS", hein.

ben la 340 est mise à jour réguliérement, j'avais espoir qu'ils allaient le porter dessus aussi, les chats nvidia c'est vraiment des branleurs

pour ceux qui sont en pilote propriétaire nvidia: vous n'avez pas envie parfois d'essayer le pilote libre ?

pour voir si des progrès ont été faits depuis votre dernière tentative, car peut-être que la différence de performance s'est réduite, ou que l'usage de votre PC  ne justifie plus le fait de vouloir à tout prix le pilote le plus performant, ça éviterait les crises de nerfs à chaque mise à jour du noyau/xorg,

chez moi la question ne se pose pas ( j'ai une vieille carte amd dont le pilote propriétaire n'est plus maintenu, que ce soit sous windows ou linux, donc j'utilise le pilote libre par défaut )

J'ai jamais vraiment eu a me plaindre avec le driver proprio nvidia. Les équipes de nvidia et les mainteneurs archlinux font du bon boulot, je trouve.

Si j'avais une carte nVidia d'entrée / bas de gamme, je serais probbablement sur le pilote libre. Mais sur du haut de gamme, je trouve que ça fait chier de payer une carte 500 € pour obtenir les perfs en 3D d'une carte à 50 €, donc non.

Et sur du bas de gamme tu dirais que ça fait chier de pas pouvoir exploiter à 100% les maigres perfs dont la carte dispose pour pas avoir un truc qui rame

En tout cas les perfs se sont grandement améliorées sur les dernières générations avec les derniers kernels/drm  

Moi j'ai encore un vieux bidule ATI (moyen-haut de gamme pour l'époque) sous pilote libre et j'en suis pas mécontent

Non, sur du bas de gamme je m'en fous.
 
En AMD par contre je privilégie le pilote libre, car il est globalement très performant et le pilote proprio est une catastrophe. Même sur des cartes gamers je privilégie radeon.

Tiens d'ailleurs c'est marrant, je me suis refait une config avec 4790k + GA-H97M-D3H + GTX780ti + GTX660Ti pour du calcul GPU
Le couple mobo/proc possède un gpu intel et du coup on peut installer et faire tourner sur la sortie intel et lancer les applis avec le gpu avec bumblebee comme sur un laptop, chose que je n'aurais pas pensé Bon après ça va 5 minutes, je préfère tourner sur le GPU nvidia en natif mais c'est intéressant quand même

Sur mon PC portable du boulot, il y a aussi un GPU Intel + un chip AMD Radeon mobile, depuis le noyau 4.5 ce derneir est supporté avec AMDGPU, mais en fait après quelques tests, il s'avère que le chip intégré Intel est plus rapide. (enfin je pense que c'est juste une histoire de drivers)

perso je suis super content d'avoir trouvé un laptop avec un GPU Nvidia NATIF ! Car bumblebee c'est un peu l'enfer...

Cosmocats !

j'ai l'impression qu'il y a un bug lié au swap dans le noyau 4.5.3,  
 
j'ai un PC avec 4 Go de mémoire, 5 Go de swap, quand j'ouvre des programmes gourmands au bout d'un moment ça finit par déclencher le swap disque,
 
et quand cela arrive alors le PC semble freezer pendant quelques secondes, avec une forte activité disque, puis quand je vais dans dmesg je vois ce genre de message d'erreur :
 

 
il y en a un paquet de ce genre, et vers la fin je vois ça :
 

j'ai trouvé un nouveau bug dans le noyau 4.5.3 :

- un freeze total ( obligé de faire un reset ) quand je veux utiliser ma carte tuner TNT "leadtek winfast DTV1000 T" ( carte pci ), que ce soit avec mplayer ou kaffeine, ça freeze tout de suite

j'ai une autre carte tuner TNT : "leadtek winfast DTV1800 H" qui freeze de la même manière,

en downgradant vers le noyau 4.5.2 il n'y a pas de bugs, tout est Ok,

j'ai donc ouvert un rapport de bug sur le site du noyau linux, mais il se peut que je doive faire un git-bisect pour trouver le commit fautif,

j'ai vu que la dernière version du noyau stable est la 4.5.4, mais il n'est pas encore disponible dans les dépôts archlinux ( ni dans testing au moment où j'écris ce message )

Tu peux chercher dans https://www.kernel.org/pub/linux/ke [...] eLog-4.5.3 si tu connais le pilote et voir quel  commit est fautif.
ou bien:
http://lwn.net/Articles/687055/
et voir si un commit repare ce soucis.

j'ai pas encore fait de git-bisect mais dans le changelog du 4.5.3 il y a un commit suspect, il a un rapport avec v4l2 pour le dvb :
 
https://lkml.org/lkml/2016/5/2/867
 

 
le dvb-t est géré par v4l2 il me semble, d'ailleurs c'est dans le composant "v4l-dvb" que j'ai crée le rapport de bug,
 
https://bugzilla.kernel.org/show_bug.cgi?id=118061
 
je suis en train de compiler le noyau mainline 4.6rc7 pour voir si le bug est encore là, sinon je ferais un git-bisect entre le noyau 4.5.2 et 4.5.3

sur le forum gentoo quelqu'un a aussi un problème de freeze avec le noyau 4.5.3 quand il veut utiliser sa carte tuner dvb-t :

https://forums.gentoo.org/viewtopic [...] 06fe20f8cb

edit : je viens de tester le noyau mainline 4.6rc7 : ça ne résout pas le problème, le bug est toujours là,

il ne reste donc plus qu'à faire un git-bisect entre le noyau 4.5.2 et 4.5.3

edit 2 : pas encore fait de git-bisect mais il y a du nouveau dans la mailing-list lkml :

https://lkml.org/lkml/2016/5/11/678

je vais donc commencer par compiler le 4.5.3 en annulant ce commit 2c1f6951a8a82e6de0d82b1158b5e493fc6c54ab

bon le fautif était bien ce commit 2c1f6951a8a82e6de0d82b1158b5e493fc6c54ab
 
j'ai crée un patch qui annule ce commit, tout est ok maintenant :
 
https://bugzilla.kernel.org/attachment.cgi?id=216031

4.5.4 est dans testing maintenant.