Vous n'êtes pas identifié(e).
J'ai tenté d'installer l'utilitaire nvidia-detect mais visiblement ça ne marche pas.
L'implémentation diffère-t-elle sous Tails ? Y a-t-il l'équivalent du tableau de bord ubuntu "Logiciels & Mises à Jour" avec l'onglet listant aussi bien les nvidia que le nouveau ?
Encore merci pour votre aide.
Dernière modification par i4004 (06-06-2020 18:43:39)
Hors ligne
J'avais un écran Asus 24 pouces qui fonctionnait sans souci en 1920x1080. Dès que je l'ai remplacé par un Samsung 24SD330 (aussi en 1920x1080 [...]), Tails [s'est mis] en mode 1024x768 [...]
Déjà, la référence 24SD330 ne semble pas exister, chez Samsung... Peux-tu verrouiller ces points :
référence exacte du moniteur (genre S24D330H) ;
usage de Tails (genre session Live uniquement) ;
connectique utilisée (genre adaptateur DVI/HDMI).
Sous GNOME, le journal du serveur X se trouve dans le répertoire personnel, et pas dans /var/log/ :
Le log de X comporte en principe les données EDID de l'écran, et les modelines récupérées via DDC.
Sous Buster, le pilote Xorg utilisé pour un GPU NVIDIA est modesetting (modeset). Vérifier ça aussi.
cvt 1920 1080# 1920x1080 59.96 Hz (CVT 2.07M9) hsync: 67.16 kHz; pclk: 173.00 MHz
Modeline "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync
La modeline obtenue n'est pas adaptée, si le moniteur supporte la fréquence de 148,5 MHz au plus.
L'option -r (ie reduced blanking) fournit une modeline plus conforme aux spécifications du moniteur.
J'ai tenté d'installer l'utilitaire nvidia-detect mais visiblement ça ne marche pas.
C'est tout à fait normal, la section non-free n'étant pas « activée » par défaut, sous Debian ou Tails.
Après ajout de ladite section aux sources de paquets et mise à jour des listes ça « marche » mieux.
C'est juste pour le sport, car l'installation du pilote propriétaire (redémarrage requis) est hors sujet.
Dernière modification par èfpé (07-06-2020 21:18:42)
Hors ligne
Dans le listing obtenu de cat ~/.local/share/xorg/Xorg.1.log (dis-moi si je dois fournir d'autres infos):
Merci d'avoir donné le lien vers les specs, effectivement le moniteur ne supporte pas au delà de 148,5 MHz.
J'ai donc essayé cvt -r 1920 1080 et obtenu les mêmes résultats que toi:
Le problème est que si je fais xrandr --newmode avec les données de la Modeline, voici le résultat:
Donc je ne sais pas trop comment remédier à ça.
Sous Buster, le pilote Xorg utilisé pour un GPU NVIDIA est modesetting (modeset). Vérifier ça aussi.
Encore étranger pour moi...
i4004 a écrit :J'ai tenté d'installer l'utilitaire nvidia-detect mais visiblement ça ne marche pas.
C'est tout à fait normal, la section non-free n'étant pas « activée » par défaut, sous Debian ou Tails.apt-cache policy nvidia-detectN: Impossible de trouver le paquet nvidia-detect
Après ajout de ladite section aux sources de paquets et mise à jour des listes ça « marche » mieux.apt-cache policy nvidia-detectnvidia-detect:
Installé : (aucun)
Candidat : 418.113-1
Table de version :
440.82-2 -10
-10 tor+http://vwakviie2ienjx6t.onion/debian bullseye/non-free amd64 Packages
-10 tor+http://vwakviie2ienjx6t.onion/debian sid/non-free amd64 Packages
418.113-1 990
990 tor+http://vwakviie2ienjx6t.onion/debian buster/non-free amd64 Packages
C'est juste pour le sport, car l'installation du pilote propriétaire (redémarrage requis) est hors sujet.
Si c'est hors sujet je vais pas abuser mais de toute façon j'obtiens l'erreur "N- Impossible de trouver le maquet nvidia-dectect" et ne sais pas encore comment aller plus loin.
Dernière modification par i4004 (09-06-2020 22:00:19)
Hors ligne
Dernière modification par MicP (10-06-2020 08:03:51)
Hors ligne
[5.591701] nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for DVI-I-1
Ceci confirme l'origine du problème, hélas tes explications concernant la connectique sont confuses :
connecteur utilisé côté moniteur (VGA ?, HDMI ?) ;
connecteur utilisé côté carte graphique (DVI-I ?) ;
câble utilisé entre les deux (un truc clair/précis) ;
adaptateur utilisé (moniteur sans connecteur DVI).
L'extrait du log de X confirme l'utilisation du pilote Xorg modesetting et l'absence de données EDID.
xrandr --newmode DVI-I-1 "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsyncxrandr: unrecognized option '+hsync'
Try 'xrandr --help' for more information.
Cette commande est erronée... D'où l'invitation à lire la doc ou le man qui contient un exemple clair :
En principe, la dernière commande devrait provoquer le redimensionnement de l'affichage, à vérifier :
Ceci durera le temps d'une session... Si le résultat te convient, tu pourras créer un fichier xorg.conf.
Dernière modification par èfpé (11-06-2020 04:18:42)
Hors ligne
Bonjour
Si ça peut aider, vous pouvez aussi voir ce qui a déjà été fait à ce sujet dans ce fil de discussion
=======
@i4004
J'aimerai voir le retour de la ligne de commande suivante :cat /etc/apt/sources.list
Je regarde le fil recommandé dès que j'ai un moment...
Merci pour votre aide.
Hors ligne
Re-,
i4004 a écrit :[5.591701] nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for DVI-I-1
Ceci confirme l'origine du problème, hélas tes explications concernant la connectique sont confuses :
connecteur utilisé côté moniteur (VGA ?, HDMI ?) ;
connecteur utilisé côté carte graphique (DVI-I ?) ;
câble utilisé entre les deux (un truc clair/précis) ;
adaptateur utilisé (moniteur sans connecteur DVI).
L'extrait du log de X confirme l'utilisation du pilote Xorg modesetting et l'absence de données EDID.i4004 a écrit :xrandr --newmode DVI-I-1 "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsyncxrandr: unrecognized option '+hsync'
Try 'xrandr --help' for more information.
Cette commande est erronée... D'où l'invitation à lire la doc ou le man qui contient un exemple clair :xrandr --newmode "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsyncxrandr --addmode DVI-I-1 1920x1080Rxrandr --output DVI-I-1 --mode 1920x1080R
En principe, la dernière commande devrait provoquer le redimensionnement de l'affichage, à vérifier :xrandr --current
Ceci durera le temps d'une session... Si le résultat te convient, tu pourras créer un fichier xorg.conf.i4004 a écrit :Si c'est hors sujet je vais pas abuser mais de toute façon j'obtiens l'erreur "N: Impossible de trouver le paquet nvidia-detect" et ne sais pas encore comment aller plus loin.
C'est/était hors sujet pour un système Live sans persistance ; mais tu sembles avoir changé d'avis.
Quoi qu'il en soit, l'installation du pilote propriétaire ressemble plutôt à la manip de derniers recours.
D'abord MERCI pour ta dernière réponse, l'image est bonne avec les commandes que tu donnes. ENFIN !!!
MAIS: durant le premier essai: j'ai eu un plantage complet avant de tapper la troisième commande. Même la souris (sans fil, tout comme le clavier) ne répondaient plus. RESET...
A la seconde tentative, ça a marché.
En réponse à tes premières questions:
L'écran a une prise VGA actuellement utilisée, et une HDMI (non connectée pour le moment).
Côté ordi, il y a deux sorties DVI: une sur la carte mère (inutilisée), et l'autre sur la GeForce qui a aussi deux HDMI une HDMI et une DP (non utilisées). C'est la DVI GeForce qui est utilisée.
Le cordon est donc un simple VGA/DVI .
Ce qui m'inquiète, c'est ce plantage, car ce n'est pas la première fois que ça se produit. Mais là, on est peut-être hors sujet (à voir).
Comme tes dernières lignes de commandes donnent le résultat que je souhaitais depuis le début, je vais faire ce ficheir xorg.conf.
J'avais vu qu'on pouvait ajouter ces commandes dans /etc/gdm3/Init/Default et j'ai essayé de le faire en root, mais au redémarrage le fichier a perdu ses changements. Bref, je me plonge dans le xorg.conf... Histoire de commencer à connaître un peu mieux l'OS...
En tout cas, à priori il n'y a pas besoin du pilote NVIDIA. Ta bonne config du pilot nouveau marche.
Dernière modification par i4004 (16-06-2020 21:02:55)
Hors ligne
Comme tes dernières lignes de commandes donnent le résultat que je souhaitais depuis le début, je vais faire ce fichier xorg.conf.
Le man d'xorg.conf étant tout sauf une sinécure, voici un exemple de fichier ayant fait ses preuves :
DisplaySize est commenté parce que non confirmé. Par ailleurs je n'ai pas encore testé sur une Tails.
edit: bon, xorg.conf ne fonctionnera que sur un système installé, ou alors c'est franchement tordu.
L'alternative un peu bricolo, certes, mais très simple, est de coller trois lignes dans un fichier script :
Stocke-le sur le volume persistant, et exécute-le d'un clic au début de chaque nouvelle session Live.
Dernière modification par èfpé (11-06-2020 04:46:42)
Hors ligne
…Le cordon est donc un simple VGA/DVI . …
Certains cordons SVGA<->DVI sont plus ou moins complets, et il peut manquer certaines liaisons qui empêcheraient l'I²C de transmettre les informations DDC
Parfois, c'est aussi sur le connecteur de la carte graphique ou/et de l'écran q'il manque cette liaison.
Je m'étais aperçu de ça quand j'ai eu à dépanner un professionnel de l'animation vidéo qui ne comprenait pas pourquoi il n'arrivait pas à calibrer son écran tout neuf.
Sur son cordon DVI <-> DVI, même si toutes les broches étaient présentes, les broches 6 et 7 n'étaient reliées à aucun conducteur.
Sur un connecteur SVGA, ce sont les broches 12 et 15 que j'utilise (avec la masse en broche 10) comme port I²C sur mes PC pour mes montages électroniques )
=======
Certains protocoles propriétaires (en HDMI, par exemple) n'utilisent pas les broches réservées à l'I²C sur ces connecteurs,
car ils font passer l'I²C dans le flux d'informations qui circule par les autres connections.
=======
Fait quand même attention, maintenant que tu as défini les paramètres manuellement,
à ce que l'écran que tu connecteras à cette machine supporte bien cette configuration,
ça pourrait être fatal (matériellement) pour l'écran s'il n'était pas conçu pour supporter cette configuration.
(d'où l'intérêt du dialogue par l'I²C pour que la carte graphique s'entende avec l'écran sur la configuration optimale à utiliser)
Dernière modification par MicP (10-06-2020 18:08:40)
Hors ligne
…Le cordon est donc un simple VGA/DVI . …
Certains cordons SVGA<->DVI sont plus ou moins complets, et il peut manquer certaines liaisons qui empêcheraient l'I²C de transmettre les informations DDC
Parfois, c'est aussi sur le connecteur de la carte graphique ou/et de l'écran q'il manque cette liaison.
Je m'étais aperçu de ça quand j'ai eu à dépanner un professionnel de l'animation vidéo qui ne comprenait pas pourquoi il n'arrivait pas à calibrer son écran tout neuf.
Sur son cordon DVI <-> DVI, même si toutes les broches étaient présentes, les broches 6 et 7 n'étaient reliées à aucun conducteur.
Sur un connecteur SVGA, ce sont les broches 12 et 15 que j'utilise (avec la masse en broche 10) comme port I²C sur mes PC pour mes montages électroniques )
=======
Certains protocoles propriétaires (en HDMI, par exemple) n'utilisent pas les broches réservées à l'I²C sur ces connecteurs,
car ils font passer l'I²C dans le flux d'informations qui circule par les autres connections.
=======
Fait quand même attention, maintenant que tu as défini les paramètres manuellement,
à ce que l'écran que tu connecteras à cette machine supporte bien cette configuration,
ça pourrait être fatal (matériellement) pour l'écran s'il n'était pas conçu pour supporter cette configuration.
(d'où l'intérêt du dialogue par l'I²C pour que la carte graphique s'entende avec l'écran sur la configuration optimale à utiliser)
Merci pour ce conseil intéressant.
En effet, j'ignorais qu'il existait des versions différentes de cordons VGA/DVI au niveau câblage, surtout que l'écran précédent (un Asus 24 pouces orienté gamer dont j'ai oublié le modèle) marchait sans souci depuis toujours sous Tails, et que mon Samsung actuel a été détecté en 1920x1080 par Windows et fonctionne sans souci.
Sans vouloir faire de hors sujet, j'ai trouvé étrange que Windows le détecte et le fasse fonctionner immédiatement en 1920x1080 alors que Tails n'y est pas arrivé automatiquement. Cela amène plusieurs questions: peut-il exister plusieurs méthodes de détection de cet écran en mode 1920x1080, et si oui, est-il possible qu'il manque celle dont Tails / Debian ont besoin pour que cet écran soit détecté et fonctionnel en 1920x1080 ? Si c'est le cas, est-ce une histoire d'implémentation dans le pilote ("nouveau") ?
Existe-t-il un utilitaire qui tente de communiquer avec l'écran par toutes les façons possibles et te dis ce qui peut manquer dans ton cordon VGA/DVI ?
Encore merci !
Dernière modification par i4004 (10-06-2020 21:20:02)
Hors ligne
Re-,
L'alternative un peu bricolo, certes, mais très simple, est de coller trois lignes dans un fichier script :nano xrandr.sh#!/bin/sh
xrandr --newmode "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsync
xrandr --addmode DVI-I-1 1920x1080R
xrandr --output DVI-I-1 --mode 1920x1080R
chmod a+x xrandr.sh
Stocke-le sur le volume persistant, et exécute-le d'un clic au début de chaque nouvelle session Live.
Merci !
Je l'ai fait: ça marche impec depuis le Terminal via la commande
Seulement le double-clic ouvre le fichier sous éditeur de fichier texte (application Open With par défaut et je ne vois rien d'autre dans les propriétés qui semble correspondre à une exécution de script).
Au premier essai en double click, j'ai eu un plantage radical.
Je suis passé ensuite en exécution via Terminal et là ça marche impec.
Est-il possible d'automatiser l'exécution de ce fichier une fois le persistent délocké au démarrage ?
Dernière modification par i4004 (10-06-2020 21:57:24)
Hors ligne
…peut-il exister plusieurs méthodes de détection de cet écran en mode 1920x1080…
Oui, je pense que l'I²C doit passer aussi par d'autres canaux, multiplexés avec les signaux vidéos.
…est-ce une histoire d'implémentation dans le pilote ("nouveau") ? …
Vu ce que j'ai pu constater avec mes machines, je pense que oui.
Dès que ceux qui fabriquent les cartes graphiques mettront à disposition des développeurs pour Linux les caractéristiques de leur carte graphique,
elles seront implémentées dans les pilote pour Linux.
=======
C'est par le protocole I²C que le "dialogue" entre la carte graphique et l'écran se fait,
et dans le cas de la personne que j'ai dépannée, avec un simple multimètre,
j'ai pu m'apercevoir que c'était bien le cordon qui n'était pas complètement câblé.
J'ai mis dialogue entre guillemets, parce qu'en fait c'était, à la base, plus à sens unique
puisque c'était l'écran qui informait la carte graphique de ses caractéristiques,
Mais ce standard a beaucoup évolué et il y a maintenant beaucoup plus d'informations échangées,
et c'est devenu un vrai dialogue qui se poursuit, toujours en I²C, mais par un Hub USB.
Certaines fonctionnalités ne deviennent alors accessibles (en fonction de la carte graphique ou/et de l'écran)
qu'à condition d'utiliser les pilotes propriétaires.
Mon ancien PC Asus G53SW équipé d'une carte NVIDIA GTX460M ne pouvait utiliser un écran externe en deuxième écran
qu'avec le pilote propriétaire, et même si on arrivait à le lui faire accepter avec le pilote nouveau, la qualité des images
et certaines fonctionnalités étaient bridées (orientation de l'écran, sortie son, etc.)
Mais depuis peu (debian 9), le pilote nouveau semble très bien fonctionner avec cette carte,
donc je n'utilise plus le pilote propriétaire avec ce PC.
Voir la page WiKi concernant le Display Data Channel (en anglais => beaucoup plus détaillée et à jour)
(La même page WiKi mais en Français )
et voir aussi : https://fr.wikipedia.org/wiki/High-band … Protection
Dernière modification par MicP (11-06-2020 05:36:57)
Hors ligne
Est-il possible d'automatiser l'exécution de ce [script] une fois le [stockage persistant] délocké au démarrage ?
Oui par exemple via un fichier de configuration desktop créé dans le répertoire ~/.config/autostart/ :
C'est bricolo, mais ça peut dépanner en attendant de trouver le câble idéal. Références : ici, ici, et là.
Hors ligne
Hors ligne
Dernière modification par MicP (11-06-2020 09:00:50)
Hors ligne
Vérifie quand même si les broche I²C ne sont pas déjà bien câblées sur ton cordon,
Pour un cordon DVI / VGA, il me faudrait les combinaisons possibles pour faire les tests.
Je vais chercher un peu pour voir.
Mais bon, c'était peut-être un problème sur le connecteur de la carte graphique…
Comme quoi, même avec un écran et un cordon en bon état …
Je n'en suis pas convaincu. Windows a détecté mon écran en 1920x1080 de façon transparente et fonctionne sans souci. Pourquoi pas Tails (d'autant plus que les lignes de commande données par èfpé corrigent le problème) ? Pour moi, il manque quelque chose dans le pilote...
Dernière modification par i4004 (11-06-2020 17:48:39)
Hors ligne
La masse étant aussi utilisée pour les autres signaux,
ce n'est pas la peine de la tester : elle est sans doute connectée.
Hors ligne
Re-,
i4004 a écrit :Est-il possible d'automatiser l'exécution de ce [script] une fois le [stockage persistant] délocké au démarrage ?
Oui par exemple via un fichier de configuration desktop créé dans le répertoire ~/.config/autostart/ :cd /live/persistence/TailsData_unlocked/dotfilesnano xrandr.sh#!/bin/sh
xrandr --newmode "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsync
xrandr --addmode DVI-I-1 1920x1080R
xrandr --output DVI-I-1 --mode 1920x1080R
chmod +x xrandr.shmkdir -p .config/autostartcd .config/autostartnano xrandr.desktop[Desktop Entry]
Type=Application
Name=Xrandr
Exec=/home/amnesia/xrandr.sh
C'est bricolo, mais ça peut dépanner en attendant de trouver le câble idéal. Références : ici, ici, et là.
J'ai tenté cette manip mais le répertoire dotfiles n'existe pas sous /live/persistence/TailsData_unlocked.
Je l'ai donc créé pour voir, et continué. Après premier redémarrage, pas de changement.
J'ai ensuite vu que dans xrandr.desktop, le chemin de xrandr.sh me semblait erroné (en tout cas dans ce chemin, on ne trouve pas le fichier en question). Donc j'ai remplacé le chemin /home/amnesia/xrandr.sh par /live/persistence/TailsData_unlocked/dotfiles/xrandr.sh mais toujours rien après redémarrage.
Ais-je loupé quelque chose ?
PS: la création du dossier ainsi que des fichiers nécessitait le mode root.
Hors ligne
Sur la droite dans les pages web suivantes
tu as le brochage des connecteurs
https://fr.wikipedia.org/wiki/Digital_visual_interface
https://fr.wikipedia.org/wiki/Connecteur_VGAVGA DVI
-----------------------------------------------
SDA données I2C (DDC) Broche 12 <-> Broche 7
SCL Horloge I²C (DDC) Broche 15 <-> Broche 6La masse étant aussi utilisée pour les autres signaux,
ce n'est pas la peine de la tester : elle est sans doute connectée.
Je pense que le multimètre ne sera pas nécessaire: la carte a une prise DVI-I (c'est marqué dessus en plus ) et j'utilise un cordon avec une prise DVI-A .
Faudra voir si le problème se résoud en mettant un câble DVI-I (Dual Link) à la place.
Hors ligne
Ai-je loupé quelque chose ?
Oui, sans doute, tu n'as apparemment pas configuré la fonctionnalité Dotfiles (stockage persistant).
J'avais tout de même testé avant de poster (machine équipée d'une carte graphique NVIDIA, Fermi).
Hors ligne
Dernière modification par i4004 (11-06-2020 21:09:19)
Hors ligne
Hors ligne
Hors ligne
… Je préfère dans un premier temps la solution des fichiers shell, …
Tout-à fait logique, ça fera moins de manipulations à faire.
Mais avec seulement le cordon HDMI, si l'écran le détecte automatiquement ou s'il y a un menu OSD sur l'écran pour lui dire d'utiliser le connecteur HDMI
ça devrait fonctionner.
Dernière modification par MicP (16-06-2020 09:09:58)
Hors ligne
Dernière modification par i4004 (16-06-2020 21:24:40)
Hors ligne