Merci de ton retour
suis en 4.9.0.4, dépôt en backport…
Par défaut ce fichier n’existe pas car il n’est plus nécessaire.
Si je comprends bien, le problème ne se produit que lorsque l’émulateur de terminal est ouvert en plein écran ? Avec aucun autre programme ?
As-tu testé les autres modes graphiques ?
As-tu regardé dans les logs de Xorg quel était le pilote utilisé ?
PS : C’est une machine neuve ? Sinon, l’as-tu utilisée avec une version précédente de Debian, et si oui, présentait-elle le même problème ?
Merci de ton retour
Emulateur terminal et Libreoffice pour mon fichier pas à pas d’installation que je me suis constitué.
je teste d’autres modes graphiques (actuellement 1366768) je passe en 1360768 et teste
Comment obtenir ces logs de Xorg ?
Machine à 2 ans, super état, ras avec Debian 8, Ubuntu 17,10 et Fedora 27
Tu veux dire que ça se produit aussi avec LibreOffice Writer ? Toujours en plein écran, et uniquement avec ce fichier, ou n’importe quel fichier, ou un nouveau fichier vide ? (je soupçonne que c’est la présence de beaucoup de blanc dans l’image qui déclenche le phénomène).
Apparemment depuis stretch la localisation du fichier Xorg.0.log dépend de l’environnement de bureau et/ou du gestionnaire de connexion. Par exemple avec lightdm/LXDE, c’est dans /var/log comme avant (si ce fichier existe regarde la date, c’est peut-être un ancien qui date de jessie). Avec gdm/Gnome, c’est censé être dans ~/.local/share/xorg (pas vérifié, je ne l’utilise pas).
On voit que c’est bien le pilote modesetting qui est utilisé. Mais c’est normal si tu as désinstallé le pilote intel.
Tu peux réinstaller le pilote intel, redémarrer et regarder à nouveau dans les logs si c’est toujours modesetting ou intel qui est utilisé. Si c’est toujours modesetting, tu peux créer un fichier xorg.conf pour forcer l’utilisation du pilote intel comme indiqué ci-dessus. On ne peut plus désinstaller le pilote modesetting car il n’est plus dans un paquet séparé mais inclus dans le paquet de base xorg.
Bonjour
Merci encore de ton assistance
J’ai réinstallé le driver intel (il était déjà présent…)
Puis modifié mon /etc/X11/xorg.conf vierge comme ci-dessous (un peu au flan après quelques recherches et un lspci pour le nom exacte de la carte…)
Section "Device"
Identifier "Intel Corporation HD Graphics 5500"
Driver "Intel"
EndSection
Voici mon Xorg.0.log qui s’est considérablement modifié et dans lequel je ne trouve plus trace a priori de modesetting mais plutôt le driver Intel
Xorg.0.log (24,7 Ko)
Pour l’instant, j’ai quitté le mode sombre du thème (Pas de depart en cacahouète de l’écran mais seulement une image qui fige avec obligation de reboot sous ce mode) au profit du clair.
Je sollicite terminal pour retrouver éventuellement les mêmes symptômes…
J’ai vu dans les logs qu’il y a deux fréquences de rafraîchissement disponibles pour la résolution native 1366x768 : 60 Hz et 48 Hz. Tu peux tester les deux pour voir si ça fait une différence.
J’ai le même soucis. Je ne sais pas par où chercher pour essayer de diagnostiquer le problème…
Bonjour
J’ai essayé les deux fréquences… même résultat…
MAJ systématiques faites, passage en linux 4.9.0-5-amd64…
Par contre lorsque je passe le terminal en fond sombre rien ne se passe… écran stable… Bizarre…
Tu as vérifié à chaque fois que la fréquence était bien appliquée ?
Est-ce que l’utilisation du pilote intel change quelque chose ?
C’est le noyau de stretch. Tu as écris par ailleurs
mais le noyau de stretch-backports est en version 4.14. L’as-tu essayé ?
Ça me fait penser aux problèmes de synchronisation d’image avec les signaux vidéo analogiques RVB (VGA) ou composites. L’image blanche provoque des fronts importants et périodiques dans le signal image qui interfèrent avec la lecture des fronts des signaux de synchronisation marquant le début ou la fin des trames et des lignes.
J’ai exactement ce problème là. Merci @jcsm33 pour l’avoir pointé.
J’ai deux écrans connectés en DisplayPort. Vivement une mise à jour du noyau.
Toutes mes excuses pour le délai de réponse et ce long silence… Boulot…
Les deux fréquences offraient le même résultat décevant…
Passage sur le noyau backport 9.14 après une clean install :
# apt-cache search linux-image
# apt-get install linux-image-4.14.0-0.BPO.2-amd64
Les symptômes semblent avoir disparu…
A suivre… Quelques tests avant de placer le poste en résolu…
Dans tous les cas, un très grand merci pour l’assistance et la patience
Cordialement
M.
Je confirme que le passage au noyau des backports semble régler le problème. Comme @Merayo, je n’ai pas encore le recul pour confirmer que le soucis est définitivement réglé, mais la piste est sérieuse.
Il faut simplement préciser qu’il faut pour cela activer les dépôts backports de debian. Mais je trouve vraiment regrettable de devoir activer les backports simplement pour avoir un système stable. Espérons que le noyau de stretch sera prochainement patché et corrigé.
Et un petit correctif du post de @Merayo, le noyau de backports n’est pas le 9.14, mais le 4.14. J’espère que tu confirmes ?
Confirmation de ma faute de frappe… 4.14 comme le gros pavé en gras du dessous le confirme…
Merci Ploc
Pour l’instant c’est sans symptôme, à suivre…
J’ai vu passer une news quelque part sur un noyau 4.15 qui serai, va ou est disponible ?
Et je “plussois”… Backport pour avoir un système stable… On est proche du concept…
M.
Une nouvelle version 4.9.80 est disponible dans stretch-proposed-updates et bientôt comme mise à jour de sécurité.
J’ai une debian stretch tout ce qu’il y a de plus classique et mon noyau est le suivant :
4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64 GNU/Linux
Est-ce que mon noyau est en version 4.9.0-6 ou en 4.9.82-1 ? Pourquoi deux numéros de version ? Que veulent-ils dire ?
Est-ce que le bug mentionné dans ce fil de discussion est corrigé dans le noyau que j’utilise actuellement ?
Bonjour
Je ne sais pas quelle commande tu avais utilisé.
Tu ne nous a donné qu’une ligne de texte
qui ressemble au retour de l’exécution de la ligne de commande
uname --all
La commande suivante
uname --kernel-release
retourne la version qui a été utilisée pour compiler le noyau
La commande suivante
uname --kernel-version
retourne la version du noyau une fois qu’il a été compilé,
(donc, celui qui est utilisé par le système debian que tu utilises en ce moment)
et la date à laquelle il a été compilé.
J’avais tapé la commande uname -a qui équivaut à uname --all.
Je découvre donc qu’un noyau garde la mémoire du noyau avec lequel il a été compilé. J’imagine que c’est une information utile et importante.
Et j’en conclu que j’utilise le noyau 4.9.82 qui comprend effectivement le correctif du problème évoqué dans ce fil de discussion.
Merci @MicP pour ta réponse utile.