Réglage du mode noyau vs Framebuffer?

Avec KMS, les pilotes graphiques sont déplacés dans le noyau. Étant donné que le framebuffer était déjà dans le noyau, je ne m'attendrais pas à ce que cela affecte le fonctionnement du framebuffer. Pourtant, j'ai lu que KMS remplace le fb, augmente le fb, nécessite le fb et nécessite la suppression du support fb. Que diable? La réponse que je recherche est une explication de la relation entre KMS et le framebuffer.

J'utilise uvesafb pour obtenir une résolution native sur le tty. Mon but ici est de comprendre comment cela va fonctionner sur un système avec KMS. Cela aiderait également à couvrir des choses comme .. Le défilement est-il plus rapide avec KMS? Les utilitaires comme fbterm et fbida fonctionnent-ils de la même manière? La stabilité est-elle meilleure?

Tout d'abord, il existe essentiellement deux types de pilotes Framebuffer classiques:

• Pilotes génériques de matériel et de micrologiciel (par exemple vga, vesafb / uvesafb, efifb)
• Pilotes spécifiques au matériel (par exemple rivafb, atyfb)

Les pilotes de framebuffer classiques avaient tous un support de paramétrage de mode de base, mais ils exposaient peu ou pas de support pour l'accélération matérielle.

Avec la conception X classique, ce n'était pas vraiment un problème: pour obtenir une accélération 2D, le serveur X s'exécutait en tant que root et pouvait accéder directement au matériel. Il a essentiellement contourné complètement le pilote framebuffer. Pour la prise en charge 3d (et 2d sur les cartes plus récentes), il utiliserait également un pilote DRM du noyau qui assurait la médiation de l'accès et de la mémoire vidéo gérée.

Dans cette configuration, il y avait deux endroits où le paramétrage des modes a été effectué: à la fois dans le pilote du framebuffer du noyau et dans le serveur X de l'espace utilisateur. Cette duplication de code (et les combats occasionnels entre pilotes, par exemple sur VT-switch) n'était pas idéal.

De plus, il y avait deux pilotes distincts dans le noyau pour le même matériel: le pilote framebuffer et le pilote DRM. Dans certains cas (par exemple pré-kms intelfb), vous pouvez charger l'un ou l'autre, mais pas les deux en même temps.

KMS était la solution à ces problèmes. Il:

• Fusionne le pilote framebuffer spécifique au matériel du noyau et le pilote drm en un seul pilote.
• Fournit une interface à utiliser par le serveur X pour contrôler le paramétrage des modes, afin que le serveur X n'ait pas à accéder directement au matériel. (En effet, avec KMS, le serveur X n'a ​​plus besoin des autorisations root.)

Quelques notes intéressantes: La migration vers ce qui est maintenant KMS a en fait commencé vers 2004; voir l'email de Jon Smirl sur la réarchitecture de la console .

Pour répondre à vos questions plus spécifiques:

• La vitesse ne sera généralement pas pire que l'un des pilotes génériques non accélérés (par exemple, VGA, vesafb), mais la console texte KMS framebuffer a été conçue pour la commodité et l'utilisation d'urgence plutôt que la vitesse, et la console n'est pas complètement accélérée sur certains pilotes. Les longues lignes enveloppées sont assez mauvaises sur les cartes Intel, par exemple.
• Les applications conçues pour utiliser les anciennes interfaces framebuffer fonctionneront toujours sur un framebuffer KMS.

KMS définit la résolution et la profondeur d'affichage dans l'espace du noyau plutôt que dans l'espace utilisateur. Alors oui, il la remplace. Il permet une résolution native dans le framebuffer.

Réglage du mode noyau