Déjà ton "problème" ne concerne pas le noyau mais Xorg, donc tu est hors sujet.
Ca fait 17 ans qu'ils sont incapables de faire une simple intereface qui permet de choisir resolution et frequence....
On peut choisir sa fréquence de la même façon sous Linux que sous Windows ! Si on a les bons pilotes...
Un ecran n'a pas beosin de pilotes. C'est comme ca.
Uniquement pour les modes définis par la norme Vesa, tout comme tu n'a pas besoin du pilote de ta carte graphique pour afficher le BIOS en 640x480.
Mais pour les modes un peu plus exotiques, il faut un pilote, certes un simple fichier texte suffit, on appelles ça des modelines, mais c'est bien un pilote et Windows le gère comme tel, dans Panneau de configuration -> Ajout de matériel.
Sans ça tu aura au choix pas d'affichage, des lignes horizontales qui vibrent avec un cri strident façon Canal+ sans décodeur (mon bon vieux 15 pouces réagissait comme-ça) ou un affichage d'une ligne sur deux sur un coté de l'écran et ce qui ressemble à une ombre de l'autre (ça c'est quand on utilises une mauvaise configuration pour l'entrelacement).
C'est pareil sous Linux et Windows. Si ton écran affiche une résolution non standard, soit il l'exporte via l'EDID, soit il exporte un EDID buggué (et le constructeur pourra pousse un quirk dans Windows pour qu'une correction soit appliqué automatiquement) soit il exporte rien du tout (pour les plus vieux moniteurs) et il faudra sous Windows, sélectionner l'écran dans ajout de périphérique éventuellement après avoir inséré le CD contenant le driver si le fabriquant ne l'a pas poussé dans Windows.
Sous Linux faudra trouver les bonnes modelines et les ajouter à la configuration de Xorg, on peut se baser pour ça sur le fichier .ini pour Windows ou utiliser un script de génération automatique en ligne et faire plusieurs essais.
À noter que si ce problème a quasiment disparus pour les écrans modernes, la même chose bat son plein en ce moment pour les périphériques d'entrée en USB (claviers, souris...), là déjà on est pas HS car ça concerne le noyau, mais le problème est pire : Les constructeurs buggent volontairement leurs tables USBHID (un peu l'équivalent de l'EDID) pour Forcer les utilisateurs de Windows à utiliser le logiciel fournis à fin de profiter des touches et fonctionnalités spéciales (alors que la norme USBHID est largement suffisante pour ces cas d'utilisation).
On peut se demander pourquoi tant d'acharnement à forcer l'utilisateur à utiliser des programmes alors qu'une norme supporté à la fois par Windows, Linux et MacOS permet de se passer du coût de leur développement. Espionnage ? Comme nous le rappelles Android à chaque fois qu'on installe un clavier virtuel, celui qui contrôle nos entrées a un large pouvoir.
Comment Linux gère ça, vu que bien sûr les fabricants s'en fiches de Linux ?
Ben en ajoutant au noyau des tables USBHID corrigés pour les périphériques buggés. Du coup il vaut mieux, si on ne veut pas avoir à créer ces tables corrigés soit-même (je l'ai déjà fait), acheter des grandes marques genre Logitech, ils sont pas moins buggés, mais le quirk arrive bien plus vite et bien plus sûrement dans le noyau.
[^] # Re: Tres bon
Posté par Tonton Benoit . En réponse à la dépêche Sortie du noyau Linux 3.19. Évalué à 8.
Déjà ton "problème" ne concerne pas le noyau mais Xorg, donc tu est hors sujet.
On peut choisir sa fréquence de la même façon sous Linux que sous Windows ! Si on a les bons pilotes...
Uniquement pour les modes définis par la norme Vesa, tout comme tu n'a pas besoin du pilote de ta carte graphique pour afficher le BIOS en 640x480.
Mais pour les modes un peu plus exotiques, il faut un pilote, certes un simple fichier texte suffit, on appelles ça des modelines, mais c'est bien un pilote et Windows le gère comme tel, dans Panneau de configuration -> Ajout de matériel.
Sans ça tu aura au choix pas d'affichage, des lignes horizontales qui vibrent avec un cri strident façon Canal+ sans décodeur (mon bon vieux 15 pouces réagissait comme-ça) ou un affichage d'une ligne sur deux sur un coté de l'écran et ce qui ressemble à une ombre de l'autre (ça c'est quand on utilises une mauvaise configuration pour l'entrelacement).
C'est pareil sous Linux et Windows. Si ton écran affiche une résolution non standard, soit il l'exporte via l'EDID, soit il exporte un EDID buggué (et le constructeur pourra pousse un quirk dans Windows pour qu'une correction soit appliqué automatiquement) soit il exporte rien du tout (pour les plus vieux moniteurs) et il faudra sous Windows, sélectionner l'écran dans ajout de périphérique éventuellement après avoir inséré le CD contenant le driver si le fabriquant ne l'a pas poussé dans Windows.
Sous Linux faudra trouver les bonnes modelines et les ajouter à la configuration de Xorg, on peut se baser pour ça sur le fichier .ini pour Windows ou utiliser un script de génération automatique en ligne et faire plusieurs essais.
À noter que si ce problème a quasiment disparus pour les écrans modernes, la même chose bat son plein en ce moment pour les périphériques d'entrée en USB (claviers, souris...), là déjà on est pas HS car ça concerne le noyau, mais le problème est pire : Les constructeurs buggent volontairement leurs tables USBHID (un peu l'équivalent de l'EDID) pour Forcer les utilisateurs de Windows à utiliser le logiciel fournis à fin de profiter des touches et fonctionnalités spéciales (alors que la norme USBHID est largement suffisante pour ces cas d'utilisation).
On peut se demander pourquoi tant d'acharnement à forcer l'utilisateur à utiliser des programmes alors qu'une norme supporté à la fois par Windows, Linux et MacOS permet de se passer du coût de leur développement. Espionnage ? Comme nous le rappelles Android à chaque fois qu'on installe un clavier virtuel, celui qui contrôle nos entrées a un large pouvoir.
Comment Linux gère ça, vu que bien sûr les fabricants s'en fiches de Linux ?
Ben en ajoutant au noyau des tables USBHID corrigés pour les périphériques buggés. Du coup il vaut mieux, si on ne veut pas avoir à créer ces tables corrigés soit-même (je l'ai déjà fait), acheter des grandes marques genre Logitech, ils sont pas moins buggés, mais le quirk arrive bien plus vite et bien plus sûrement dans le noyau.