Je me permets de vous soumettre le problème que je rencontre sur une
nouvelle machine, après avoir essayé une série de choses qui ne le
résolvent pas, en espérant que quelqu'un aurait une expérience utile
en la matière, ou déjà une idée ou deux :-)
La machine est un NUC Intel, modèle NUC7i3DNKE.
Son processeur est un Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz
Sa carte graphique, selon lspci : Intel Corporation HD Graphics 620 (rev 02)
Elle a 4GB de RAM de marque 2-Power dans le slot inférieur et est
couplée à deux écrans DELL U3011 par des câbles HDMI to DVI-D Dual
Link (ce barebone n'a que deux connecteurs HDMI 2.0). Ça fait donc 2x
2560x1600 en résolution (et il peut aller jusqu'à 2x 4k, @60 Hz).
Enfin, elle est utilisée comme client léger sous LTSP, bootant sur un
serveur LTSP en NFS, mais l'aspect LTSP est indifférent.
Question OS, a priori tout est du stretch pur jus, à jour (donc tant
le serveur LTSP que l'OS utilisé par le client léger, c.-à-d. ici le
NUC).
Le souci rencontré est que les écrans clignotent de temps en temps :
ils s'éteignent (l'un ou l'autre ou les deux) une à deux secondes,
voire parfois 4-5, et puis se rallument...
Jusqu'ici, j'ai lancé le NUC sous stretch 32bits et amd64, sans et
puis avec le microcode Intel (avec, ça améliore sensiblement les
choses, bien que ça ne soit pas encore parfait), pour finir enfin en
buster, avec le noyau 4.14.
Toujours avec le microcode, les résultats varient en fonction de la
version du noyau : avec le 4.9 de stretch, c'est inutilisable
tellement ça clignote. C'est un poil mieux avec le 4.14 des backports,
toujours en stretch et ça devient utilisable, mais encore gênant avec
le 4.14 de buster.
Pour voir, j'ai booté aussi, toujours sous buster, avec le noyau
4.15.7 de sid, mais là c'est catastrophique (et pour cause : le noyau
désactive une partie du microcode Intel en signalant qu'il ne résout
pas Spectre (j'ai oublié les termes exacts, mais le microcode est
pourtant la dernière version de chez Intel : 20171117).
Enfin, à part en 4.15.7, j'ai chaque fois essayé avec les pilotes
graphiques modesetting et Intel. On ne peut toutefois pas dire que ça
fait une différence notable de comportement, et comme modesetting est
recommandé et semble (mais c'est subjectif) un poil plus rapide à
l'affichage, je tourne avec ce pilote, sous buster pour le moment.
Enfin encore, je viens aussi d'upgrader le bios du NUC à la dernière
version (039) du 22/02/2018.
Mais même si ça n'a plus rien à voir avec les débuts sous stretch, les
clignotements persistent quand même encore, sur l'un ou l'autre des
écrans, au point que j'hésite à laisser ça comme poste de travail en
l'état...
Inverser les écrans ne change rien ; un à la fois ou deux, c'est tout
à fait pareil ; les connecteurs sont bien vissés aux écrans, etc.
Rien n'y fait : c'est totalement erratique. L'un ou l'autre s'éteint
puis se rallume, jusqu'à parfois 10x sur quelques minutes, et puis
plus rien pendant un moment, etc.
Les seuls constats qui semblent pouvoir être posés sont :
- que le phénomène ne semble jamais se produire quand l'écran change
en permanence : en lançant xscreensaver ou un film, je ne l'ai
jamais surpris à s'éteindre de manière inexpliquée. C'est quand
l'image est fixe, mais qu'on tape du texte ou non, ça le fait ;
- que l'écran qui n'a pas le focus *semble* s'exciter davantage que
celui qui contient la fenêtre où je tape ceci, mais c'est difficile
d'en être sûr...
Voilà le phénomène bizarre. Si quelqu'un a une expérience utile à
partager ou ne fut-ce qu'une idée de piste à explorer, je suis
preneur :-)
Je vous remercie d'avance, en tout cas de m'avoir lu.
Chère Liste, On Wed, Mar 07, 2018 at 06:43:47PM +0100, JF Straeten wrote: [...]
Je pense nécessaire d'essayer d'autres câbles du type requis, de bonne facture (et si vous en avez qui fonctionne, les références m'intéressent évidemment) parce qu'on a ici manifestement une piste exploitable. Ou bien, vous pensez que je perds mon temps ?
Pour finir sur ceci, je me réponds tout seul : j'ai encore fait un test hier soir : j'ai pu brancher le NUC sur un écran LG E2711T, un 27", en 1920x1080 (le max), en DVI-D, via un des câbles HDMI to DVI acquis en même temps que le NUC... Et bien l'image est parfaitement stable ; ça fonctionne parfaitement ; jamais aucun clignotement. Je pense donc que la conclusion à en tirer est que ces câbles, bien qu'ils se prétendent "Dual Link" (et qu'ils en aient le connecteur particulier), ne le sont en réalité pas et ne sont pas capables de tenir les signaux d'envoi d'une résolution 2560x1600. Ils plafonnent à 1920x1200, soit le max du "Single Link". Dans ces conditions, évidemment, ça revient à essayer de mettre deux litres dans un bidon d'un... Je n'ai pas du tout soupçonné ça parce que la fiche technique du câble en question spécifie « Compatible with DVD-D dual link devices », ce qui est nécessaire pour faire passer cette résolution, et c'est bien parce que c'était spécifié clairement que j'ai commandé ces câbles là. Rideau, donc ; je cherche une autre solution. Je remercie encore tous ceux qui se sont penchés sur ce problème. A+ -- JFS.
Chère Liste,
On Wed, Mar 07, 2018 at 06:43:47PM +0100, JF Straeten wrote:
[...]
Je pense nécessaire d'essayer d'autres câbles du type requis, de
bonne facture (et si vous en avez qui fonctionne, les références
m'intéressent évidemment) parce qu'on a ici manifestement une
piste exploitable. Ou bien, vous pensez que je perds mon temps ?
Pour finir sur ceci, je me réponds tout seul : j'ai encore fait un
test hier soir : j'ai pu brancher le NUC sur un écran LG E2711T, un
27", en 1920x1080 (le max), en DVI-D, via un des câbles HDMI to DVI
acquis en même temps que le NUC...
Et bien l'image est parfaitement stable ; ça fonctionne parfaitement ;
jamais aucun clignotement.
Je pense donc que la conclusion à en tirer est que ces câbles, bien
qu'ils se prétendent "Dual Link" (et qu'ils en aient le connecteur
particulier), ne le sont en réalité pas et ne sont pas capables de
tenir les signaux d'envoi d'une résolution 2560x1600.
Ils plafonnent à 1920x1200, soit le max du "Single Link".
Dans ces conditions, évidemment, ça revient à essayer de mettre deux
litres dans un bidon d'un...
Je n'ai pas du tout soupçonné ça parce que la fiche technique du câble
en question spécifie « Compatible with DVD-D dual link devices », ce
qui est nécessaire pour faire passer cette résolution, et c'est bien
parce que c'était spécifié clairement que j'ai commandé ces câbles là.
Rideau, donc ; je cherche une autre solution.
Je remercie encore tous ceux qui se sont penchés sur ce problème.
Chère Liste, On Wed, Mar 07, 2018 at 06:43:47PM +0100, JF Straeten wrote: [...]
Je pense nécessaire d'essayer d'autres câbles du type requis, de bonne facture (et si vous en avez qui fonctionne, les références m'intéressent évidemment) parce qu'on a ici manifestement une piste exploitable. Ou bien, vous pensez que je perds mon temps ?
Pour finir sur ceci, je me réponds tout seul : j'ai encore fait un test hier soir : j'ai pu brancher le NUC sur un écran LG E2711T, un 27", en 1920x1080 (le max), en DVI-D, via un des câbles HDMI to DVI acquis en même temps que le NUC... Et bien l'image est parfaitement stable ; ça fonctionne parfaitement ; jamais aucun clignotement. Je pense donc que la conclusion à en tirer est que ces câbles, bien qu'ils se prétendent "Dual Link" (et qu'ils en aient le connecteur particulier), ne le sont en réalité pas et ne sont pas capables de tenir les signaux d'envoi d'une résolution 2560x1600. Ils plafonnent à 1920x1200, soit le max du "Single Link". Dans ces conditions, évidemment, ça revient à essayer de mettre deux litres dans un bidon d'un... Je n'ai pas du tout soupçonné ça parce que la fiche technique du câble en question spécifie « Compatible with DVD-D dual link devices », ce qui est nécessaire pour faire passer cette résolution, et c'est bien parce que c'était spécifié clairement que j'ai commandé ces câbles là. Rideau, donc ; je cherche une autre solution. Je remercie encore tous ceux qui se sont penchés sur ce problème. A+ -- JFS.
steve
Le jeudi 08 mars 2018, JF Straeten a écrit :
Je pense donc que la conclusion à en tirer est que ces câbles, bien qu'ils se prétendent "Dual Link" (et qu'ils en aient le connecteur particulier), ne le sont en réalité pas et ne sont pas capables de tenir les signaux d'envoi d'une résolution 2560x1600.
Moi, ces histoires de câbles, ça me turlupine. J'aimerais bien que tu testes ton hypothèse (parce qu'en l'état, c'en est une) et qu'on arrive à une conclusion définitive. S
Le jeudi 08 mars 2018, JF Straeten a écrit :
Je pense donc que la conclusion à en tirer est que ces câbles, bien
qu'ils se prétendent "Dual Link" (et qu'ils en aient le connecteur
particulier), ne le sont en réalité pas et ne sont pas capables de
tenir les signaux d'envoi d'une résolution 2560x1600.
Moi, ces histoires de câbles, ça me turlupine. J'aimerais bien que tu
testes ton hypothèse (parce qu'en l'état, c'en est une) et qu'on arrive
à une conclusion définitive.
Je pense donc que la conclusion à en tirer est que ces câbles, bien qu'ils se prétendent "Dual Link" (et qu'ils en aient le connecteur particulier), ne le sont en réalité pas et ne sont pas capables de tenir les signaux d'envoi d'une résolution 2560x1600.
Moi, ces histoires de câbles, ça me turlupine. J'aimerais bien que tu testes ton hypothèse (parce qu'en l'état, c'en est une) et qu'on arrive à une conclusion définitive. S
JF Straeten
Salut Steve, On Thu, Mar 08, 2018 at 02:01:12PM +0100, steve wrote:
Le jeudi 08 mars 2018, JF Straeten a écrit :
Je pense donc que la conclusion à en tirer est que ces câbles, bien qu'ils se prétendent "Dual Link" (et qu'ils en aient le connecteur particulier), ne le sont en réalité pas et ne sont pas capables de tenir les signaux d'envoi d'une résolution 2560x1600.
Moi, ces histoires de câbles, ça me turlupine. J'aimerais bien que tu testes ton hypothèse (parce qu'en l'état, c'en est une) et qu'on arrive à une conclusion définitive.
Je t'entends bien, mais ça soulève deux questions, ai-je envie de dire : - que voudrais-tu faire comme test ? Si tu as une suggestion, n'hésite pas, mais en l'état, à part mesurer les signaux (comment ? à l'oscilloscope ?), je ne vois pas quoi faire de plus qui serait à ma portée, et dans un laps de temps raisonnable ? - vu l'impossibilité de résoudre le problème raisonnablement, est-il même nécessaire d'aller plus loin (*dans le cas d'espèce*, s'entend : remplacer un client léger ; je ne parle pas « pour la science » en général) ? Il ne suffit pas de passer à une version logicielle particulière, que ce soit de la distri, du microcode Intel ou du driver X, de régler un paramètre de config, ou même de changer les câbles... J'ai parcouru les commentaires utilisateurs de câbles du même type sur Amazon : tous rapportent un fonctionnement parfait, mais aucun ne fait état de résolutions supérieures au full HD, ou à 1920x1200 (quand ils en mentionnent une). Je n'ai donc absolument aucune preuve, ou même présomption raisonnable comme tu veux, qu'un de ces câbles a déjà fonctionné en 2560x1600. C'est justement compte tenu de ça que j'ai passé les fiches techniques des câbles qui avaient la tronche du dual link (24 pin + 1) à la loupe et retenu le premier qui mentionnait explicitement "Dual Link". Je ne me vois pas souder les câbles adéquats :-) Et en réalité, c'est une impasse totale même en rebondissant sur le DisplayPort qui équipe également les Dell en entrée parce que les convertisseurs de HDMI vers DisplayPort (un simple adaptateur d'une connexion à l'autre ne suffit pas, dans ce cas) ne montent pas non plus à 2560x1600 (il en existe un chez StarTech, le HD2DP, mais il ne supporte pas cette résolution selon la doc et un user Amazon rapporte explicitement qu'il ne la sort effectivement pas en pratique). C'est pour ça que je dis « rideau ». Sur mon problème de (bêtement) échanger une machine, je ne vois rien d'améliorable et ça deviendrait de l'entêtement inutile... Mais sur le fond, tu n'as évidemment pas tort du tout :-) A+ -- JFS.
Salut Steve,
On Thu, Mar 08, 2018 at 02:01:12PM +0100, steve wrote:
Le jeudi 08 mars 2018, JF Straeten a écrit :
> Je pense donc que la conclusion à en tirer est que ces câbles, bien
> qu'ils se prétendent "Dual Link" (et qu'ils en aient le connecteur
> particulier), ne le sont en réalité pas et ne sont pas capables de
> tenir les signaux d'envoi d'une résolution 2560x1600.
Moi, ces histoires de câbles, ça me turlupine. J'aimerais bien que
tu testes ton hypothèse (parce qu'en l'état, c'en est une) et qu'on
arrive à une conclusion définitive.
Je t'entends bien, mais ça soulève deux questions, ai-je envie de
dire :
- que voudrais-tu faire comme test ?
Si tu as une suggestion, n'hésite pas, mais en l'état, à part
mesurer les signaux (comment ? à l'oscilloscope ?), je ne vois pas
quoi faire de plus qui serait à ma portée, et dans un laps de temps
raisonnable ?
- vu l'impossibilité de résoudre le problème raisonnablement, est-il
même nécessaire d'aller plus loin (*dans le cas d'espèce*,
s'entend : remplacer un client léger ; je ne parle pas « pour la
science » en général) ?
Il ne suffit pas de passer à une version logicielle particulière,
que ce soit de la distri, du microcode Intel ou du driver X, de
régler un paramètre de config, ou même de changer les câbles...
J'ai parcouru les commentaires utilisateurs de câbles du même type
sur Amazon : tous rapportent un fonctionnement parfait, mais aucun
ne fait état de résolutions supérieures au full HD, ou à 1920x1200
(quand ils en mentionnent une). Je n'ai donc absolument aucune
preuve, ou même présomption raisonnable comme tu veux, qu'un de ces
câbles a déjà fonctionné en 2560x1600.
C'est justement compte tenu de ça que j'ai passé les fiches
techniques des câbles qui avaient la tronche du dual link (24 pin +
1) à la loupe et retenu le premier qui mentionnait explicitement
"Dual Link".
Je ne me vois pas souder les câbles adéquats :-)
Et en réalité, c'est une impasse totale même en rebondissant sur le
DisplayPort qui équipe également les Dell en entrée parce que les
convertisseurs de HDMI vers DisplayPort (un simple adaptateur d'une
connexion à l'autre ne suffit pas, dans ce cas) ne montent pas non
plus à 2560x1600 (il en existe un chez StarTech, le HD2DP, mais il
ne supporte pas cette résolution selon la doc et un user Amazon
rapporte explicitement qu'il ne la sort effectivement pas en
pratique).
C'est pour ça que je dis « rideau ». Sur mon problème de (bêtement)
échanger une machine, je ne vois rien d'améliorable et ça deviendrait
de l'entêtement inutile...
Mais sur le fond, tu n'as évidemment pas tort du tout :-)
Salut Steve, On Thu, Mar 08, 2018 at 02:01:12PM +0100, steve wrote:
Le jeudi 08 mars 2018, JF Straeten a écrit :
Je pense donc que la conclusion à en tirer est que ces câbles, bien qu'ils se prétendent "Dual Link" (et qu'ils en aient le connecteur particulier), ne le sont en réalité pas et ne sont pas capables de tenir les signaux d'envoi d'une résolution 2560x1600.
Moi, ces histoires de câbles, ça me turlupine. J'aimerais bien que tu testes ton hypothèse (parce qu'en l'état, c'en est une) et qu'on arrive à une conclusion définitive.
Je t'entends bien, mais ça soulève deux questions, ai-je envie de dire : - que voudrais-tu faire comme test ? Si tu as une suggestion, n'hésite pas, mais en l'état, à part mesurer les signaux (comment ? à l'oscilloscope ?), je ne vois pas quoi faire de plus qui serait à ma portée, et dans un laps de temps raisonnable ? - vu l'impossibilité de résoudre le problème raisonnablement, est-il même nécessaire d'aller plus loin (*dans le cas d'espèce*, s'entend : remplacer un client léger ; je ne parle pas « pour la science » en général) ? Il ne suffit pas de passer à une version logicielle particulière, que ce soit de la distri, du microcode Intel ou du driver X, de régler un paramètre de config, ou même de changer les câbles... J'ai parcouru les commentaires utilisateurs de câbles du même type sur Amazon : tous rapportent un fonctionnement parfait, mais aucun ne fait état de résolutions supérieures au full HD, ou à 1920x1200 (quand ils en mentionnent une). Je n'ai donc absolument aucune preuve, ou même présomption raisonnable comme tu veux, qu'un de ces câbles a déjà fonctionné en 2560x1600. C'est justement compte tenu de ça que j'ai passé les fiches techniques des câbles qui avaient la tronche du dual link (24 pin + 1) à la loupe et retenu le premier qui mentionnait explicitement "Dual Link". Je ne me vois pas souder les câbles adéquats :-) Et en réalité, c'est une impasse totale même en rebondissant sur le DisplayPort qui équipe également les Dell en entrée parce que les convertisseurs de HDMI vers DisplayPort (un simple adaptateur d'une connexion à l'autre ne suffit pas, dans ce cas) ne montent pas non plus à 2560x1600 (il en existe un chez StarTech, le HD2DP, mais il ne supporte pas cette résolution selon la doc et un user Amazon rapporte explicitement qu'il ne la sort effectivement pas en pratique). C'est pour ça que je dis « rideau ». Sur mon problème de (bêtement) échanger une machine, je ne vois rien d'améliorable et ça deviendrait de l'entêtement inutile... Mais sur le fond, tu n'as évidemment pas tort du tout :-) A+ -- JFS.
Yann Serre
Bonsoir, Que dire pour faire court (et nécessairement caricatural) ? Le câble est probablement "Dual Link" chez le fabricant quand il branche les appareils de mesure directement dessus. Ensuite les performances se dégradent en situation réelle (parasites, connectique, impédance,...) Parasites : économie de blindage, diaphonie, proximité d'une alim à découpage,... Connectique : métaux différents, corrosion, adaptateurs,... Impédance = combinaison de plusieurs paramètres : fréquence des signaux + longueur du câble + capacitance/inductance/résistance par mètre du câble + adaptation RLC de l'électronique derrière les connecteurs... Théoriquement tout devrait répondre à des normes. Tout ça fait que le rapport signal/bruit peut se dégrader dans des proportions qui rendent incertaines les détections correctes de tous les 1 et de tous les 0 ! Concrètement : Essayer un autre câble dit "Dual Link" PLUS COURT dans un premier temps. Le 08/03/2018 à 14:01, steve a écrit :
Le jeudi 08 mars 2018, JF Straeten a écrit :
Je pense donc que la conclusion à en tirer est que ces câbles, bien qu'ils se prétendent "Dual Link" (et qu'ils en aient le connecteur particulier), ne le sont en réalité pas et ne sont pas capables de tenir les signaux d'envoi d'une résolution 2560x1600.
Moi, ces histoires de câbles, ça me turlupine. J'aimerais bien que tu testes ton hypothèse (parce qu'en l'état, c'en est une) et qu'on arrive à une conclusion définitive. S
Bonsoir,
Que dire pour faire court (et nécessairement caricatural) ?
Le câble est probablement "Dual Link" chez le fabricant quand il branche
les appareils de mesure directement dessus.
Ensuite les performances se dégradent en situation réelle (parasites,
connectique, impédance,...)
Parasites : économie de blindage, diaphonie, proximité d'une alim à
découpage,...
Impédance = combinaison de plusieurs paramètres : fréquence des signaux
+ longueur du câble + capacitance/inductance/résistance par mètre du
câble + adaptation RLC de l'électronique derrière les connecteurs...
Théoriquement tout devrait répondre à des normes.
Tout ça fait que le rapport signal/bruit peut se dégrader dans des
proportions qui rendent incertaines les détections correctes de tous les
1 et de tous les 0 !
Concrètement :
Essayer un autre câble dit "Dual Link" PLUS COURT dans un premier temps.
Le 08/03/2018 à 14:01, steve a écrit :
Le jeudi 08 mars 2018, JF Straeten a écrit :
Je pense donc que la conclusion à en tirer est que ces câbles, bien
qu'ils se prétendent "Dual Link" (et qu'ils en aient le connecteur
particulier), ne le sont en réalité pas et ne sont pas capables de
tenir les signaux d'envoi d'une résolution 2560x1600.
Moi, ces histoires de câbles, ça me turlupine. J'aimerais bien que tu
testes ton hypothèse (parce qu'en l'état, c'en est une) et qu'on arrive
à une conclusion définitive.
Bonsoir, Que dire pour faire court (et nécessairement caricatural) ? Le câble est probablement "Dual Link" chez le fabricant quand il branche les appareils de mesure directement dessus. Ensuite les performances se dégradent en situation réelle (parasites, connectique, impédance,...) Parasites : économie de blindage, diaphonie, proximité d'une alim à découpage,... Connectique : métaux différents, corrosion, adaptateurs,... Impédance = combinaison de plusieurs paramètres : fréquence des signaux + longueur du câble + capacitance/inductance/résistance par mètre du câble + adaptation RLC de l'électronique derrière les connecteurs... Théoriquement tout devrait répondre à des normes. Tout ça fait que le rapport signal/bruit peut se dégrader dans des proportions qui rendent incertaines les détections correctes de tous les 1 et de tous les 0 ! Concrètement : Essayer un autre câble dit "Dual Link" PLUS COURT dans un premier temps. Le 08/03/2018 à 14:01, steve a écrit :
Le jeudi 08 mars 2018, JF Straeten a écrit :
Je pense donc que la conclusion à en tirer est que ces câbles, bien qu'ils se prétendent "Dual Link" (et qu'ils en aient le connecteur particulier), ne le sont en réalité pas et ne sont pas capables de tenir les signaux d'envoi d'une résolution 2560x1600.
Moi, ces histoires de câbles, ça me turlupine. J'aimerais bien que tu testes ton hypothèse (parce qu'en l'état, c'en est une) et qu'on arrive à une conclusion définitive. S
JF Straeten
Hello, On Thu, Mar 08, 2018 at 06:56:19PM +0100, Yann Serre wrote: [...]
Le câble est probablement "Dual Link" chez le fabricant quand il branche les appareils de mesure directement dessus.
[...]
Tout ça fait que le rapport signal/bruit peut se dégrader dans des proportions qui rendent incertaines les détections correctes de tous les 1 et de tous les 0 !
Je ne suis pas électronicien, mais c'est fait convaincant, parce que la résolution passe et il s'en faut de peu pour que ça reste stable...
Concrètement : Essayer un autre câble dit "Dual Link" PLUS COURT dans un premier temps.
Faisable. Il existe des Amazon basic de 0.50 ou 0.90 m. Bête question peut-être, mais les recouper et resouder, ça tiendrait la route ou pas ? Mais aussi.. comment expliquer alors que les petits adaptateurs HDMI/DVI-D essayés aient foiré aussi ? Ce sont deux prises dos à dos, et le reste de la connexion est un câble DVI-D. Par une mauvaise qualité ? En te remerciant, -- JFS.
Hello,
On Thu, Mar 08, 2018 at 06:56:19PM +0100, Yann Serre wrote:
[...]
Le câble est probablement "Dual Link" chez le fabricant quand il
branche les appareils de mesure directement dessus.
[...]
Tout ça fait que le rapport signal/bruit peut se dégrader dans des
proportions qui rendent incertaines les détections correctes de tous
les 1 et de tous les 0 !
Je ne suis pas électronicien, mais c'est fait convaincant, parce que
la résolution passe et il s'en faut de peu pour que ça reste stable...
Concrètement :
Essayer un autre câble dit "Dual Link" PLUS COURT dans un premier
temps.
Faisable. Il existe des Amazon basic de 0.50 ou 0.90 m.
Bête question peut-être, mais les recouper et resouder, ça tiendrait
la route ou pas ?
Mais aussi.. comment expliquer alors que les petits adaptateurs
HDMI/DVI-D essayés aient foiré aussi ? Ce sont deux prises dos à dos,
et le reste de la connexion est un câble DVI-D. Par une mauvaise
qualité ?
Hello, On Thu, Mar 08, 2018 at 06:56:19PM +0100, Yann Serre wrote: [...]
Le câble est probablement "Dual Link" chez le fabricant quand il branche les appareils de mesure directement dessus.
[...]
Tout ça fait que le rapport signal/bruit peut se dégrader dans des proportions qui rendent incertaines les détections correctes de tous les 1 et de tous les 0 !
Je ne suis pas électronicien, mais c'est fait convaincant, parce que la résolution passe et il s'en faut de peu pour que ça reste stable...
Concrètement : Essayer un autre câble dit "Dual Link" PLUS COURT dans un premier temps.
Faisable. Il existe des Amazon basic de 0.50 ou 0.90 m. Bête question peut-être, mais les recouper et resouder, ça tiendrait la route ou pas ? Mais aussi.. comment expliquer alors que les petits adaptateurs HDMI/DVI-D essayés aient foiré aussi ? Ce sont deux prises dos à dos, et le reste de la connexion est un câble DVI-D. Par une mauvaise qualité ? En te remerciant, -- JFS.
Yann Serre
Pour le DVI les données circulent à 165 MHz... Le Dual-Link, ce sont 2 canaux à 165MHz. Quand il rencontre une soudure, plus la fréquence est élevée, plus le signal "s'éparpille". Il perd quelques dB, une petite partie repart dans l'autre sens et déforme le signal... Pareil à chaque passage de connecteur, adaptateur et autres changements de conducteur électrique, de métal,... Si la soudure est artisanale et de qualité inégale sur les différents conducteurs, on doit même avoir des phénomènes de déphasage (ou plutôt un déséquilibre des amplitudes entre, par exemple, un conducteur qui véhicule la synchro et un autre qui véhicule les données). L'électronique du moniteur va compenser dans la plupart des cas, mais si elle a l'impression de recevoir un paquet de données dans le désordre, elle va attendre le paquet suivant puis se resynchroniser... Donc mauvaise idée de re-souder soi-même des câbles. Les productions industrielles seront beaucoup plus fiables ! Le mieux serait d'acheter un câble avec les bons connecteurs SANS ADAPTATEUR et se limiter à la longueur nécessaire. Éviter l'entrée de gamme (ce qui est valable à peu près pour tout !) Une section de câble plus importante laisse supposer que le blindage est plus efficace, etc... Et il suffit aussi qu'une broche de connecteur soit trop déformée (côté prise du câble ou côté chassis) pour perdre la synchro. Un faux contact intermittent. Le câble n'est pas directement en cause car il fonctionnera quand-même s'il est branché dans un autre appareil plus tolérant ! En résumé : si ça vaut le coup de dépenser de l'argent pour cette installation, alors un bon câble sera un bon investissement (et réutilisable sinon). Le 08/03/2018 à 21:41, JF Straeten a écrit :
Concrètement : Essayer un autre câble dit "Dual Link" PLUS COURT dans un premier temps.
Faisable. Il existe des Amazon basic de 0.50 ou 0.90 m. Bête question peut-être, mais les recouper et resouder, ça tiendrait la route ou pas ? Mais aussi.. comment expliquer alors que les petits adaptateurs HDMI/DVI-D essayés aient foiré aussi ? Ce sont deux prises dos à dos, et le reste de la connexion est un câble DVI-D. Par une mauvaise qualité ? En te remerciant,
Pour le DVI les données circulent à 165 MHz... Le Dual-Link, ce sont 2
canaux à 165MHz.
Quand il rencontre une soudure, plus la fréquence est élevée, plus le
signal "s'éparpille". Il perd quelques dB, une petite partie repart dans
l'autre sens et déforme le signal...
Pareil à chaque passage de connecteur, adaptateur et autres changements
de conducteur électrique, de métal,...
Si la soudure est artisanale et de qualité inégale sur les différents
conducteurs, on doit même avoir des phénomènes de déphasage (ou plutôt
un déséquilibre des amplitudes entre, par exemple, un conducteur qui
véhicule la synchro et un autre qui véhicule les données).
L'électronique du moniteur va compenser dans la plupart des cas, mais
si elle a l'impression de recevoir un paquet de données dans le
désordre, elle va attendre le paquet suivant puis se resynchroniser...
Donc mauvaise idée de re-souder soi-même des câbles. Les productions
industrielles seront beaucoup plus fiables !
Le mieux serait d'acheter un câble avec les bons connecteurs SANS
ADAPTATEUR et se limiter à la longueur nécessaire.
Éviter l'entrée de gamme (ce qui est valable à peu près pour tout !)
Une section de câble plus importante laisse supposer que le blindage est
plus efficace, etc...
Et il suffit aussi qu'une broche de connecteur soit trop déformée (côté
prise du câble ou côté chassis) pour perdre la synchro. Un faux contact
intermittent. Le câble n'est pas directement en cause car il
fonctionnera quand-même s'il est branché dans un autre appareil plus
tolérant !
En résumé : si ça vaut le coup de dépenser de l'argent pour cette
installation, alors un bon câble sera un bon investissement (et
réutilisable sinon).
Le 08/03/2018 à 21:41, JF Straeten a écrit :
Concrètement :
Essayer un autre câble dit "Dual Link" PLUS COURT dans un premier
temps.
Faisable. Il existe des Amazon basic de 0.50 ou 0.90 m.
Bête question peut-être, mais les recouper et resouder, ça tiendrait
la route ou pas ?
Mais aussi.. comment expliquer alors que les petits adaptateurs
HDMI/DVI-D essayés aient foiré aussi ? Ce sont deux prises dos à dos,
et le reste de la connexion est un câble DVI-D. Par une mauvaise
qualité ?
Pour le DVI les données circulent à 165 MHz... Le Dual-Link, ce sont 2 canaux à 165MHz. Quand il rencontre une soudure, plus la fréquence est élevée, plus le signal "s'éparpille". Il perd quelques dB, une petite partie repart dans l'autre sens et déforme le signal... Pareil à chaque passage de connecteur, adaptateur et autres changements de conducteur électrique, de métal,... Si la soudure est artisanale et de qualité inégale sur les différents conducteurs, on doit même avoir des phénomènes de déphasage (ou plutôt un déséquilibre des amplitudes entre, par exemple, un conducteur qui véhicule la synchro et un autre qui véhicule les données). L'électronique du moniteur va compenser dans la plupart des cas, mais si elle a l'impression de recevoir un paquet de données dans le désordre, elle va attendre le paquet suivant puis se resynchroniser... Donc mauvaise idée de re-souder soi-même des câbles. Les productions industrielles seront beaucoup plus fiables ! Le mieux serait d'acheter un câble avec les bons connecteurs SANS ADAPTATEUR et se limiter à la longueur nécessaire. Éviter l'entrée de gamme (ce qui est valable à peu près pour tout !) Une section de câble plus importante laisse supposer que le blindage est plus efficace, etc... Et il suffit aussi qu'une broche de connecteur soit trop déformée (côté prise du câble ou côté chassis) pour perdre la synchro. Un faux contact intermittent. Le câble n'est pas directement en cause car il fonctionnera quand-même s'il est branché dans un autre appareil plus tolérant ! En résumé : si ça vaut le coup de dépenser de l'argent pour cette installation, alors un bon câble sera un bon investissement (et réutilisable sinon). Le 08/03/2018 à 21:41, JF Straeten a écrit :
Concrètement : Essayer un autre câble dit "Dual Link" PLUS COURT dans un premier temps.
Faisable. Il existe des Amazon basic de 0.50 ou 0.90 m. Bête question peut-être, mais les recouper et resouder, ça tiendrait la route ou pas ? Mais aussi.. comment expliquer alors que les petits adaptateurs HDMI/DVI-D essayés aient foiré aussi ? Ce sont deux prises dos à dos, et le reste de la connexion est un câble DVI-D. Par une mauvaise qualité ? En te remerciant,
Rapha=c3=abl RIGNIER
Le 04/03/2018 à 22:03, JF Straeten a écrit :
Chère Liste, [...] Je vous remercie d'avance, en tout cas de m'avoir lu. A+
Bonjour, j'ai suivi le fil de tes déboires. Pas toujours évident de diagnostiquer ce genre de problème. J'utilise beaucoup LTSP pour différents usages et tout ne fonctionne pas toujours pareil qu'un poste natif. Le PXE doit y être pour quelque chose. J'ai des NUC première génération Celeron 4GB RAM qui sont pas stables pour 2 sous avec windows 7. Je les utilise donc avec une image ubuntu 16.04 LTSP pnp maison à base de openbox et vmware view client pour connecter à une ferme VDI vmware. Cela fonctionne très bien. J'utilise le même principe avec un vieux LTSP unbuntu 12.04 et un vieux client vmware 32 bits avec des machines encore plus vieilles à base de P4 2.5 et 1,5GB de RAM. Là non plus pas de souci majeur, sauf quand j'ai branché un splitter VGA sur l'un d'eux et impossible d'avoir une résolution > 800x600. En même temps les cartes graphiques sont des Sis qui ne font plus partie de xorg, je cherche vraiment les ennuis ! Les meilleurs résultats que j'ai avec LTSP et du matériel récent est d'utiliser Ubuntu en mode PNP -> https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp avec des images nbd. Essaie ensuite avec un poste natif, au point où tu en est... Je ne suis pas sectaire et j'utilise Debian pour tout le reste :) Cela dit, il peut y avoir du nouveau avec ltsp-manager que je n'ai pas testé.
Le 04/03/2018 à 22:03, JF Straeten a écrit :
Chère Liste,
[...]
Je vous remercie d'avance, en tout cas de m'avoir lu.
A+
Bonjour, j'ai suivi le fil de tes déboires. Pas toujours évident de
diagnostiquer ce genre de problème.
J'utilise beaucoup LTSP pour différents usages et tout ne fonctionne pas
toujours pareil qu'un poste natif. Le PXE doit y être pour quelque chose.
J'ai des NUC première génération Celeron 4GB RAM qui sont pas stables
pour 2 sous avec windows 7. Je les utilise donc avec une image ubuntu
16.04 LTSP pnp maison à base de openbox et vmware view client pour
connecter à une ferme VDI vmware. Cela fonctionne très bien.
J'utilise le même principe avec un vieux LTSP unbuntu 12.04 et un vieux
client vmware 32 bits avec des machines encore plus vieilles à base de
P4 2.5 et 1,5GB de RAM. Là non plus pas de souci majeur, sauf quand j'ai
branché un splitter VGA sur l'un d'eux et impossible d'avoir une
résolution > 800x600. En même temps les cartes graphiques sont des Sis
qui ne font plus partie de xorg, je cherche vraiment les ennuis !
Les meilleurs résultats que j'ai avec LTSP et du matériel récent est
d'utiliser Ubuntu en mode PNP ->
https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp avec des images nbd.
Essaie ensuite avec un poste natif, au point où tu en est...
Je ne suis pas sectaire et j'utilise Debian pour tout le reste :)
Cela dit, il peut y avoir du nouveau avec ltsp-manager que je n'ai pas
testé.
Chère Liste, [...] Je vous remercie d'avance, en tout cas de m'avoir lu. A+
Bonjour, j'ai suivi le fil de tes déboires. Pas toujours évident de diagnostiquer ce genre de problème. J'utilise beaucoup LTSP pour différents usages et tout ne fonctionne pas toujours pareil qu'un poste natif. Le PXE doit y être pour quelque chose. J'ai des NUC première génération Celeron 4GB RAM qui sont pas stables pour 2 sous avec windows 7. Je les utilise donc avec une image ubuntu 16.04 LTSP pnp maison à base de openbox et vmware view client pour connecter à une ferme VDI vmware. Cela fonctionne très bien. J'utilise le même principe avec un vieux LTSP unbuntu 12.04 et un vieux client vmware 32 bits avec des machines encore plus vieilles à base de P4 2.5 et 1,5GB de RAM. Là non plus pas de souci majeur, sauf quand j'ai branché un splitter VGA sur l'un d'eux et impossible d'avoir une résolution > 800x600. En même temps les cartes graphiques sont des Sis qui ne font plus partie de xorg, je cherche vraiment les ennuis ! Les meilleurs résultats que j'ai avec LTSP et du matériel récent est d'utiliser Ubuntu en mode PNP -> https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp avec des images nbd. Essaie ensuite avec un poste natif, au point où tu en est... Je ne suis pas sectaire et j'utilise Debian pour tout le reste :) Cela dit, il peut y avoir du nouveau avec ltsp-manager que je n'ai pas testé.
daniel huhardeaux
Le 06/03/2018 à 11:39, daniel huhardeaux a écrit :
Le 04/03/2018 à 22:03, JF Straeten a écrit :
Chère Liste, Je me permets de vous soumettre le problème que je rencontre sur une nouvelle machine, après avoir essayé une série de choses qui ne le résolvent pas, en espérant que quelqu'un aurait une expérience utile en la matière, ou déjà une idée ou deux :-) La machine est un NUC Intel, modèle NUC7i3DNKE. Son processeur est un Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz Sa carte graphique, selon lspci : Intel Corporation HD Graphics 620 (rev 02) Elle a 4GB de RAM de marque 2-Power dans le slot inférieur et est couplée à deux écrans DELL U3011 par des câbles HDMI to DVI-D Dual Link (ce barebone n'a que deux connecteurs HDMI 2.0). Ça fait donc 2x 2560x1600 en résolution (et il peut aller jusqu'à 2x 4k, @60 Hz). Enfin, elle est utilisée comme client léger sous LTSP, bootant sur un serveur LTSP en NFS, mais l'aspect LTSP est indifférent. Question OS, a priori tout est du stretch pur jus, à jour (donc tant le serveur LTSP que l'OS utilisé par le client léger, c.-à-d. ici le NUC). Le souci rencontré est que les écrans clignotent de temps en temps : ils s'éteignent (l'un ou l'autre ou les deux) une à deux secondes, voire parfois 4-5, et puis se rallument... Jusqu'ici, j'ai lancé le NUC sous stretch 32bits et amd64, sans et puis avec le microcode Intel (avec, ça améliore sensiblement les choses, bien que ça ne soit pas encore parfait), pour finir enfin en buster, avec le noyau 4.14. Toujours avec le microcode, les résultats varient en fonction de la version du noyau : avec le 4.9 de stretch, c'est inutilisable tellement ça clignote. C'est un poil mieux avec le 4.14 des backports, toujours en stretch et ça devient utilisable, mais encore gênant avec le 4.14 de buster. Pour voir, j'ai booté aussi, toujours sous buster, avec le noyau 4.15.7 de sid, mais là c'est catastrophique (et pour cause : le noyau désactive une partie du microcode Intel en signalant qu'il ne résout pas Spectre (j'ai oublié les termes exacts, mais le microcode est pourtant la dernière version de chez Intel : 20171117). Enfin, à part en 4.15.7, j'ai chaque fois essayé avec les pilotes graphiques modesetting et Intel. On ne peut toutefois pas dire que ça fait une différence notable de comportement, et comme modesetting est recommandé et semble (mais c'est subjectif) un poil plus rapide à l'affichage, je tourne avec ce pilote, sous buster pour le moment. Enfin encore, je viens aussi d'upgrader le bios du NUC à la dernière version (039) du 22/02/2018. Mais même si ça n'a plus rien à voir avec les débuts sous stretch, les clignotements persistent quand même encore, sur l'un ou l'autre des écrans, au point que j'hésite à laisser ça comme poste de travail en l'état... Inverser les écrans ne change rien ; un à la fois ou deux, c'est tout à fait pareil ; les connecteurs sont bien vissés aux écrans, etc. Rien n'y fait : c'est totalement erratique. L'un ou l'autre s'éteint puis se rallume, jusqu'à parfois 10x sur quelques minutes, et puis plus rien pendant un moment, etc. Les seuls constats qui semblent pouvoir être posés sont : - que le phénomène ne semble jamais se produire quand l'écran change en permanence : en lançant xscreensaver ou un film, je ne l'ai jamais surpris à s'éteindre de manière inexpliquée. C'est quand l'image est fixe, mais qu'on tape du texte ou non, ça le fait ; - que l'écran qui n'a pas le focus *semble* s'exciter davantage que celui qui contient la fenêtre où je tape ceci, mais c'est difficile d'en être sûr... Voilà le phénomène bizarre. Si quelqu'un a une expérience utile à partager ou ne fut-ce qu'une idée de piste à explorer, je suis preneur :-) Je vous remercie d'avance, en tout cas de m'avoir lu.
Bonjour, la lecture de ce message a fait tilt dans ma mémoire. J'avais un problème identique avec un Samsung SyncMaster P2770 que j'ai préparé pour la déchetterie suite à un comportement identique, partant du principe qu'il était HS. Je l'ai reconnecté ce matin. Les résultats sont: - fond d'écran, rien ne se passe: l'écran s´éteint/se rallume au bout de 5 secondes - un fichier PDF affiché: l'écran s'éteint/se rallume au bout de 30 secondes. Dès que je ferme le PDF l'écran s'éteint - une page web statique: comportement normal Lorsque je l'ai remisé l'écran était connecté en VGA<>DVI en console KVM sous stretch kernel 4.9.0.6. Le test de ce matin est en HDMI<>DVI sous Ubuntu 16.04 kernel 4.4.0-116
[...] Bonjour, suite aux échanges concernant ce message, j'ai commandé un câble HDMI <> HDMI ultra HD 4K 2160p et à présent mon écran fonctionne parfaitement, plus de clignotement. Merci d'avoir lancé le sujet, cela m'a permis de sauver un écran ! -- Daniel
Le 06/03/2018 à 11:39, daniel huhardeaux a écrit :
Le 04/03/2018 à 22:03, JF Straeten a écrit :
Chère Liste,
Je me permets de vous soumettre le problème que je rencontre sur une
nouvelle machine, après avoir essayé une série de choses qui ne le
résolvent pas, en espérant que quelqu'un aurait une expérience utile
en la matière, ou déjà une idée ou deux :-)
La machine est un NUC Intel, modèle NUC7i3DNKE.
Son processeur est un Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz
Sa carte graphique, selon lspci : Intel Corporation HD Graphics 620
(rev 02)
Elle a 4GB de RAM de marque 2-Power dans le slot inférieur et est
couplée à deux écrans DELL U3011 par des câbles HDMI to DVI-D Dual
Link (ce barebone n'a que deux connecteurs HDMI 2.0). Ça fait donc 2x
2560x1600 en résolution (et il peut aller jusqu'à 2x 4k, @60 Hz).
Enfin, elle est utilisée comme client léger sous LTSP, bootant sur un
serveur LTSP en NFS, mais l'aspect LTSP est indifférent.
Question OS, a priori tout est du stretch pur jus, à jour (donc tant
le serveur LTSP que l'OS utilisé par le client léger, c.-à-d. ici le
NUC).
Le souci rencontré est que les écrans clignotent de temps en temps :
ils s'éteignent (l'un ou l'autre ou les deux) une à deux secondes,
voire parfois 4-5, et puis se rallument...
Jusqu'ici, j'ai lancé le NUC sous stretch 32bits et amd64, sans et
puis avec le microcode Intel (avec, ça améliore sensiblement les
choses, bien que ça ne soit pas encore parfait), pour finir enfin en
buster, avec le noyau 4.14.
Toujours avec le microcode, les résultats varient en fonction de la
version du noyau : avec le 4.9 de stretch, c'est inutilisable
tellement ça clignote. C'est un poil mieux avec le 4.14 des backports,
toujours en stretch et ça devient utilisable, mais encore gênant avec
le 4.14 de buster.
Pour voir, j'ai booté aussi, toujours sous buster, avec le noyau
4.15.7 de sid, mais là c'est catastrophique (et pour cause : le noyau
désactive une partie du microcode Intel en signalant qu'il ne résout
pas Spectre (j'ai oublié les termes exacts, mais le microcode est
pourtant la dernière version de chez Intel : 20171117).
Enfin, à part en 4.15.7, j'ai chaque fois essayé avec les pilotes
graphiques modesetting et Intel. On ne peut toutefois pas dire que ça
fait une différence notable de comportement, et comme modesetting est
recommandé et semble (mais c'est subjectif) un poil plus rapide à
l'affichage, je tourne avec ce pilote, sous buster pour le moment.
Enfin encore, je viens aussi d'upgrader le bios du NUC à la dernière
version (039) du 22/02/2018.
Mais même si ça n'a plus rien à voir avec les débuts sous stretch, les
clignotements persistent quand même encore, sur l'un ou l'autre des
écrans, au point que j'hésite à laisser ça comme poste de travail en
l'état...
Inverser les écrans ne change rien ; un à la fois ou deux, c'est tout
à fait pareil ; les connecteurs sont bien vissés aux écrans, etc.
Rien n'y fait : c'est totalement erratique. L'un ou l'autre s'éteint
puis se rallume, jusqu'à parfois 10x sur quelques minutes, et puis
plus rien pendant un moment, etc.
Les seuls constats qui semblent pouvoir être posés sont :
- que le phénomène ne semble jamais se produire quand l'écran change
en permanence : en lançant xscreensaver ou un film, je ne l'ai
jamais surpris à s'éteindre de manière inexpliquée. C'est quand
l'image est fixe, mais qu'on tape du texte ou non, ça le fait ;
- que l'écran qui n'a pas le focus *semble* s'exciter davantage que
celui qui contient la fenêtre où je tape ceci, mais c'est difficile
d'en être sûr...
Voilà le phénomène bizarre. Si quelqu'un a une expérience utile à
partager ou ne fut-ce qu'une idée de piste à explorer, je suis
preneur :-)
Je vous remercie d'avance, en tout cas de m'avoir lu.
Bonjour,
la lecture de ce message a fait tilt dans ma mémoire. J'avais un
problème identique avec un Samsung SyncMaster P2770 que j'ai préparé
pour la déchetterie suite à un comportement identique, partant du
principe qu'il était HS. Je l'ai reconnecté ce matin. Les résultats sont:
- fond d'écran, rien ne se passe: l'écran s´éteint/se rallume au bout
de 5 secondes
- un fichier PDF affiché: l'écran s'éteint/se rallume au bout de 30
secondes. Dès que je ferme le PDF l'écran s'éteint
- une page web statique: comportement normal
Lorsque je l'ai remisé l'écran était connecté en VGA<>DVI en console
KVM sous stretch kernel 4.9.0.6. Le test de ce matin est en HDMI<>DVI
sous Ubuntu 16.04 kernel 4.4.0-116
[...]
Bonjour,
suite aux échanges concernant ce message, j'ai commandé un câble HDMI <>
HDMI ultra HD 4K 2160p et à présent mon écran fonctionne parfaitement,
plus de clignotement. Merci d'avoir lancé le sujet, cela m'a permis de
sauver un écran !
Le 06/03/2018 à 11:39, daniel huhardeaux a écrit :
Le 04/03/2018 à 22:03, JF Straeten a écrit :
Chère Liste, Je me permets de vous soumettre le problème que je rencontre sur une nouvelle machine, après avoir essayé une série de choses qui ne le résolvent pas, en espérant que quelqu'un aurait une expérience utile en la matière, ou déjà une idée ou deux :-) La machine est un NUC Intel, modèle NUC7i3DNKE. Son processeur est un Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz Sa carte graphique, selon lspci : Intel Corporation HD Graphics 620 (rev 02) Elle a 4GB de RAM de marque 2-Power dans le slot inférieur et est couplée à deux écrans DELL U3011 par des câbles HDMI to DVI-D Dual Link (ce barebone n'a que deux connecteurs HDMI 2.0). Ça fait donc 2x 2560x1600 en résolution (et il peut aller jusqu'à 2x 4k, @60 Hz). Enfin, elle est utilisée comme client léger sous LTSP, bootant sur un serveur LTSP en NFS, mais l'aspect LTSP est indifférent. Question OS, a priori tout est du stretch pur jus, à jour (donc tant le serveur LTSP que l'OS utilisé par le client léger, c.-à-d. ici le NUC). Le souci rencontré est que les écrans clignotent de temps en temps : ils s'éteignent (l'un ou l'autre ou les deux) une à deux secondes, voire parfois 4-5, et puis se rallument... Jusqu'ici, j'ai lancé le NUC sous stretch 32bits et amd64, sans et puis avec le microcode Intel (avec, ça améliore sensiblement les choses, bien que ça ne soit pas encore parfait), pour finir enfin en buster, avec le noyau 4.14. Toujours avec le microcode, les résultats varient en fonction de la version du noyau : avec le 4.9 de stretch, c'est inutilisable tellement ça clignote. C'est un poil mieux avec le 4.14 des backports, toujours en stretch et ça devient utilisable, mais encore gênant avec le 4.14 de buster. Pour voir, j'ai booté aussi, toujours sous buster, avec le noyau 4.15.7 de sid, mais là c'est catastrophique (et pour cause : le noyau désactive une partie du microcode Intel en signalant qu'il ne résout pas Spectre (j'ai oublié les termes exacts, mais le microcode est pourtant la dernière version de chez Intel : 20171117). Enfin, à part en 4.15.7, j'ai chaque fois essayé avec les pilotes graphiques modesetting et Intel. On ne peut toutefois pas dire que ça fait une différence notable de comportement, et comme modesetting est recommandé et semble (mais c'est subjectif) un poil plus rapide à l'affichage, je tourne avec ce pilote, sous buster pour le moment. Enfin encore, je viens aussi d'upgrader le bios du NUC à la dernière version (039) du 22/02/2018. Mais même si ça n'a plus rien à voir avec les débuts sous stretch, les clignotements persistent quand même encore, sur l'un ou l'autre des écrans, au point que j'hésite à laisser ça comme poste de travail en l'état... Inverser les écrans ne change rien ; un à la fois ou deux, c'est tout à fait pareil ; les connecteurs sont bien vissés aux écrans, etc. Rien n'y fait : c'est totalement erratique. L'un ou l'autre s'éteint puis se rallume, jusqu'à parfois 10x sur quelques minutes, et puis plus rien pendant un moment, etc. Les seuls constats qui semblent pouvoir être posés sont : - que le phénomène ne semble jamais se produire quand l'écran change en permanence : en lançant xscreensaver ou un film, je ne l'ai jamais surpris à s'éteindre de manière inexpliquée. C'est quand l'image est fixe, mais qu'on tape du texte ou non, ça le fait ; - que l'écran qui n'a pas le focus *semble* s'exciter davantage que celui qui contient la fenêtre où je tape ceci, mais c'est difficile d'en être sûr... Voilà le phénomène bizarre. Si quelqu'un a une expérience utile à partager ou ne fut-ce qu'une idée de piste à explorer, je suis preneur :-) Je vous remercie d'avance, en tout cas de m'avoir lu.
Bonjour, la lecture de ce message a fait tilt dans ma mémoire. J'avais un problème identique avec un Samsung SyncMaster P2770 que j'ai préparé pour la déchetterie suite à un comportement identique, partant du principe qu'il était HS. Je l'ai reconnecté ce matin. Les résultats sont: - fond d'écran, rien ne se passe: l'écran s´éteint/se rallume au bout de 5 secondes - un fichier PDF affiché: l'écran s'éteint/se rallume au bout de 30 secondes. Dès que je ferme le PDF l'écran s'éteint - une page web statique: comportement normal Lorsque je l'ai remisé l'écran était connecté en VGA<>DVI en console KVM sous stretch kernel 4.9.0.6. Le test de ce matin est en HDMI<>DVI sous Ubuntu 16.04 kernel 4.4.0-116
[...] Bonjour, suite aux échanges concernant ce message, j'ai commandé un câble HDMI <> HDMI ultra HD 4K 2160p et à présent mon écran fonctionne parfaitement, plus de clignotement. Merci d'avoir lancé le sujet, cela m'a permis de sauver un écran ! -- Daniel
