Voici plusieurs semaines que j'ai reçu mon écran TFT Samsung 172X et que je l'utilise (bientôt 1 mois). Pour information, mon PC tourne sous GNU/Linux Debian sarge et il est doté d'une carte graphique Matrox G550.
Au déballage, il présente un seul et unique pixel mort : il éclaire continuellement bleu. Ce n'est pas génant, il faut vraiment aller à la chasse aux pixels morts et de très près pour le percevoir. A l'usage, en D-Sub, aucun problèmes. Pour utiliser le connexion DVI, j'ai du télécharger les drivers Matrox pour mon système graphique, X11 (j'utilise l'implémentation XFree86 de X11). Pour avoir essayer le mode D-Sub, puis DVI-D, pour revenir jusqu'à présent en D-Sub, je peux affirmer qu'il y a une différence de qualité entre les deux, malgrès la qualité des circuits D-Sub de Samsung : il n'y a pas photo, l'image est nettement plus fine, mieux contrastée en DVI-D que en D-Sub (cela vient aussi peut-être de la qualité supérieure DVI de chez Matrox).
C'est avec le DVI-D que j'ai eu quelques problèmes. En effet, j'utilise deux consoles graphiques afin que ma femme et moi puissions utiliser le PC sans avoir à se déconnecter de notre session. Avec une seule console graphique, je n'aurais peut-être pas eu ce problème. En fait, un des avantages du DVI-D est qu'il permet la synchronisation automatique entre la carte graphique et le moniteur. Le problème est la lenteur de cette synchronisation observée dans ma configuration. En effet, lorsque ma femme ou moi fermons notre session graphique, le display manager se réinitialise en reprenant la main. Le serveur X11, un système graphique réseau mais aussi multi-écrans, se réinitialise donc de même. Or durant cette phase, parce que l'on commute de mode graphique (on-off-on), la synchronisation DVI-D se lance. Le résultat est que durant un laps de temps, le second serveur X (sur l'autre console graphique), perd le contacte de l'écran. Or comme la synchronisation DVI-D prend un certain temps assez percevable, le serveur X peut se terminer automatiquement par un time-out; bien sûr la main est reprise par le display manager, mais la conséquence de ceci est arrivée : si un de nous avait une session graphique ouverte sur cette console graphique, elle est perdue !
A côté de ceci, j'apprécie et j'en suis plutôt content de mon écran Samsung 172X mais je regrette mon choix de 17". En fait, avec mon vieux 17" CRTC, sous GNU/Linux la résolution 1280x1024 est le choix optimum (comme l'est celle 1024x768 sous Windows). Avec cette même résolution sur un écran TFT 17" ('équivalent' 19" d'un CRTC), j'ai l'impression d'avoir perdu de la place sur mes bureaux graphiques. En fait, une même résolution entre un CRTC et un TFT ne sont pas comparables. Finalement, vue que les 19" TFT présentent la même résolution, et vue le 'condensé' de pixels pour représenter une 'forme' sur un 17", je me suis dit que j'aurais pu bien aérer mes bureaux graphiques avec un 19". J'aurais peut-être dû prendre soit un Samsung 192B, sois un Samsung 193 sachant que pour ce dernier j'ai appris que quelqu'un à réussi à écrire un outil pour GNU/Linux pour paramétrer l'écran.
Voili voilou mes petites aventures jusqu'à présent avec cet écran.
Marsh Posté le 07-12-2004 à 23:07:13
Bonjour,
Voici plusieurs semaines que j'ai reçu mon écran TFT Samsung 172X et que je l'utilise (bientôt 1 mois).
Pour information, mon PC tourne sous GNU/Linux Debian sarge et il est doté d'une carte graphique Matrox G550.
Au déballage, il présente un seul et unique pixel mort : il éclaire continuellement bleu. Ce n'est pas génant, il faut vraiment aller à la chasse aux pixels morts et de très près pour le percevoir.
A l'usage, en D-Sub, aucun problèmes. Pour utiliser le connexion DVI, j'ai du télécharger les drivers Matrox pour mon système graphique, X11 (j'utilise l'implémentation XFree86 de X11).
Pour avoir essayer le mode D-Sub, puis DVI-D, pour revenir jusqu'à présent en D-Sub, je peux affirmer qu'il y a une différence de qualité entre les deux, malgrès la qualité des circuits D-Sub de Samsung : il n'y a pas photo, l'image est nettement plus fine, mieux contrastée en DVI-D que en D-Sub (cela vient aussi peut-être de la qualité supérieure DVI de chez Matrox).
C'est avec le DVI-D que j'ai eu quelques problèmes. En effet, j'utilise deux consoles graphiques afin que ma femme et moi puissions utiliser le PC sans avoir à se déconnecter de notre session. Avec une seule console graphique, je n'aurais peut-être pas eu ce problème. En fait, un des avantages du DVI-D est qu'il permet la synchronisation automatique entre la carte graphique et le moniteur. Le problème est la lenteur de cette synchronisation observée dans ma configuration. En effet, lorsque ma femme ou moi fermons notre session graphique, le display manager se réinitialise en reprenant la main. Le serveur X11, un système graphique réseau mais aussi multi-écrans, se réinitialise donc de même. Or durant cette phase, parce que l'on commute de mode graphique (on-off-on), la synchronisation DVI-D se lance. Le résultat est que durant un laps de temps, le second serveur X (sur l'autre console graphique), perd le contacte de l'écran. Or comme la synchronisation DVI-D prend un certain temps assez percevable, le serveur X peut se terminer automatiquement par un time-out; bien sûr la main est reprise par le display manager, mais la conséquence de ceci est arrivée : si un de nous avait une session graphique ouverte sur cette console graphique, elle est perdue !
A côté de ceci, j'apprécie et j'en suis plutôt content de mon écran Samsung 172X mais je regrette mon choix de 17". En fait, avec mon vieux 17" CRTC, sous GNU/Linux la résolution 1280x1024 est le choix optimum (comme l'est celle 1024x768 sous Windows). Avec cette même résolution sur un écran TFT 17" ('équivalent' 19" d'un CRTC), j'ai l'impression d'avoir perdu de la place sur mes bureaux graphiques. En fait, une même résolution entre un CRTC et un TFT ne sont pas comparables. Finalement, vue que les 19" TFT présentent la même résolution, et vue le 'condensé' de pixels pour représenter une 'forme' sur un 17", je me suis dit que j'aurais pu bien aérer mes bureaux graphiques avec un 19". J'aurais peut-être dû prendre soit un Samsung 192B, sois un Samsung 193 sachant que pour ce dernier j'ai appris que quelqu'un à réussi à écrire un outil pour GNU/Linux pour paramétrer l'écran.
Voili voilou mes petites aventures jusqu'à présent avec cet écran.