Je me suis demandé où placer ce morceau de texte. Propre site Web est un candidat possible, ou trouvez un fil sur superuser.com qui se rapproche le plus de mon sujet (et qui m'a peut-être aidé). C'est comme ça que je suis arrivé ici :-)
Mon problème particulier était de savoir comment forcer un mode vidéo particulier sur mes consoles de texte. Configuration du système: Debian 9 Stretch sur du matériel Haswell, son IGP géré par le pilote i915 sous Linux (prenant maintenant en charge KVM et DRI / DRM depuis un certain temps). Un commutateur KVM analogique stupide, indiquant au PC via DDC / EDID que la résolution maximale était de 1600x1200, mais alimentant en réalité un écran LCD capable de 1280x1024 :-)
J'ai commencé à jouer avec vbetoolet fbset, qui sont cependant périmés / impropres à cet usage, car ils sont incompatibles avec KMS + DRM. "Inteldrmfb" semble n'être qu'un compromis sur KMS + DRM (et ne semble pas être incorporé dans un module de noyau en soi). Les paramètres de géométrie sont en lecture seule. Bien au moins fbset peut afficher passivement la résolution active, qui a une valeur informative.
Pourtant, il semble y avoir un moyen pour vous et moi de définir la résolution et la fréquence de rafraîchissement vertical AKA à partir de la ligne de commande du noyau (paramètres du chargeur de démarrage sur la ligne commençant par "linux", qui se trouve être situé vers la fin d'un processus moderne. section grub.conf sur plusieurs lignes).
Vous pouvez manipuler les paramètres au moment du démarrage si vous appuyez sur ependant que Grub décompte le délai. Suivez l'aide à partir de là. Une fois que vous êtes satisfait de vos modifications, appuyez sur Ctrl + X ou F10 pour démarrer le profil modifié. (Vos modifications sont éphémères - elles apparaîtront dans / proc / cmdline dans votre noyau en cours d'exécution lors de ce démarrage, mais ne seront pas écrites dans le fichier grub.conf.) Pour le stockage persistant de vos paramètres de démarrage supplémentaires (arguments de la commande de noyau dans le noyau), dans Debian vous devriez les entrer /etc/default/grubdans une variable appelée GRUB_CMDLINE_LINUX_DEFAULT. Et, courez update-grub.
Maintenant pour les arguments. Tout d’abord, vous avez besoin i915.modeset=1 (à condition que votre sous-système graphique soit un Intel IGP). Si vous rencontrez le même problème que moi, à savoir que le noyau configure une résolution beaucoup trop élevée, vous avez probablement modeset = 1 déjà par défaut (compilé dans le noyau). Tandis que vous vous débattez avec la syntaxe des curses de cmdline et que vous voulez parfois utiliser n'importe quel mode graphique, vous pouvez essayer i915.modeset=0. Cela empêche apparemment les changements de mode graphique et vous vous retrouvez avec une console presque classique de 80x25 caractères, jusqu'à la connexion à la console. Vous remarquerez également qu'il n'y a pas de / dev / fb0, ni de messages de débogage DRM dans dmesg (lisez la suite pour plus de détails).
Remarquez également l'option quiet. Cela fonctionne avec ou sans la définition de mode. Cela empêche apparemment l’impression de messages du noyau sur votre console (/ dev / tty) = vous obtenez un écran noir pendant quelques secondes puis vous êtes accueilli par l’invite de connexion. C'est un défaut dans Debian. (En fait, dans Debian moderne avec systemd, vous obtenez probablement les messages de démarrage de systemd sur votre écran, au lieu du journal du noyau ...) Le fait est que si vous voulez récupérer les messages du noyau, vous devez simplement effacer le mot "quiet" depuis la ligne de commande du noyau et utilisez cette ligne pour un seul démarrage (appuyez sur "e" dans Grub, edit, ctrl + x pour continuer) ou de manière permanente (edit / etc / default / grub && update-grub).
Maintenant, enfin, le point: une fois que vous avez i915.modeset=1, vous devez également ajouter video=<xres>x<yres>@framerate. Tels que, dans mon cas, video=1280x1024@60ou video=1024x768@60. Il y a d'autres options possibles, voir le chapitre correspondant sur Arch wiki . Par exemple, vous pouvez également spécifier la profondeur de couleur, ou appliquer le mode à un seul port de sortie vidéo (appelé "connecteur" dans les tripes DRM). Notez que votre mode spécifié doit probablement correspondre à l’un des modes connus du noyau, c’est-à-dire l’un des "modèles de modélisation EDID". Le noyau conserve une liste de ces blocs de données, obtenus soit via DDC à partir d'un moniteur, soit dans / lib / firmware, soit éventuellement compilés. Par exemple, vous ne pouvez pas spécifier une géométrie quelconque.
Dans certains howtos, vous trouverez juste video=<xres>x<yres>, tels que video=1024x768. Cela a l'effet souhaité, en ce sens que la résolution apparaît sur la sortie - mais vous avez laissé la décision sur la fréquence d'images aux pilotes, qui ont tendance à choisir la fréquence d'images la plus élevée possible (parmi les "lignes de mode" disponibles dans l'ensemble des blocs EDID). Comme dans mon cas, il est apparu que le pilote avait choisi 1024x768@85, ce qui aurait été un choix judicieux à l'époque du tube cathodique, mais il est terriblement hors de portée pour de nombreux écrans LCD modernes. Notez que les écrans LCD modernes bon marché (avant FreeSync) prennent généralement une fréquence de trames de 60 Hz. C’est donc ce que vous devez définir explicitement, si votre DDC est absent ou dingue.
Pendant ma recherche de réponses, je n'arrêtais pas de trouver des références à ce correctif défini par Dave Airlie - qui apporte le traitement video = cmdline arg. Il s’avère que cela a été fusionné avec Linux à la vanille il y a quelques années.
Dans mon cas, le moniteur était piloté par 1600x1200 et signalait "hors de portée" car il ne pouvait pas s'en sortir. Tandis que j'essayais divers arguments de cmdline, j'ai juste essayé video=1024x768, ce qui a abouti à un " dépassement de portée" sur le moniteur. À l’extérieur, par le vague message d’erreur, il semblait que l’argument de la ligne de commande n’avait aucun effet. Ce n'est que plus tard que j'ai découvert qu'il ne me manquait qu'un @60suffixe :-)
La partie intéressante ici est, comment j'ai découvert. Il existe un autre argument de la commande cmdline du noyau qui fait que le sous-système DRI / DRM imprime un journal de débogage plus bavard:
Version du noyau inférieure à 4.1:
drm.debug=0xe
noyau version 4.1 ou plus récent:
drm.debug=0x1e log_buf_len=1M
( source )
Je joins un exemple de journal de débogage de ma machine . Les choses de se concentrer sur (mots - clés pour rechercher): Kernel command line, cmdline, adjusted mode,[drm:
Les "noms de connecteur" peuvent être lus à partir d'ici:
ls /sys/class/drm/
et notez que la syntaxe video = ... cmdline arg ne prend pas le préfixe "card-" que vous pouvez voir dans / sys / class / drm. La syntaxe de video = et des noms de connecteurs est décrite en détail dans un chapitre pertinent du wiki Arch Linux .
Maintenant, laissez-moi changer de sujet / changer de sujet un peu.
La question initiale dans ce fil était, comment modifier la géométrie du mode vidéo. Je l'ai déjà fait auparavant sous X et Windows (en utilisant le dernier Intel IEGD). Sous Linux sous kvm + drm, le seul moyen de modifier la géométrie et le timing consiste apparemment à déposer votre propre fichier EDID, que vous devez d’abord créer manuellement. Bien presque.
La construction EDID est brièvement décrite dans un extrait de documentation inclus avec le code source du noyau vanilla.
Le Makefile et les exemples de définitions EDID résident dans son répertoire parent .
Sélectionnez un exemple .S, copiez-le dans votre propre fichier (voir la convention de nommage au-dessus du Makefile), éditez les timings, construisez votre binaire EDID et ... espérons-le, cela résoudra votre problème :-)
Les chronométrages / comptages de pixels mettent quelques calculs à faire. Et, il y a plusieurs normes historiques alternatives que vous feriez mieux de respecter et qui sont en conflit les unes avec les autres (ce sont des étapes d'évolution des normes de minutage d'affichage):
- l'ère des tubes cathodiques
GTF,
- l'ère LCD
DMTou CVT,
- et ensuite
CVT-RB(réduction du blanking).
Vous pouvez soit calculer les chiffres à la main, soit utiliser des outils et des tableaux de modes standard. Essayez googler pour "calculateur EDID" ou "calculateur modeline" ou quelque chose du genre. Il existe même un
outil de ligne de commande Linux soigné pour le travail. Voir aussi la
base de données modeline .
Votre problème particulier peut éventuellement être résolu en décalant l’impulsion HSYNC vers la droite (vous pouvez également essayer de changer sa polarité), ou en allongeant l’impulsion de synchronisation et / ou le temps total de suppression, ou (comme vous l’avez suggéré) en diminuant la durée. résolution en pixels visible / affichée (en multiples de 8). Si vous élargissez la suppression, vous devrez peut-être augmenter l’horloge de pixels pour conserver la cadence d’image initiale.