Configuración del modo de kernel vs. Framebuffer?

Con KMS, los controladores gráficos se trasladan al núcleo. Como el framebuffer ya estaba en el kernel, no esperaría que esto afectara la operación del framebuffer. Sin embargo, leí que KMS reemplaza a fb, aumenta fb, requiere fb y requiere que se elimine el soporte de fb. ¿Qué diablos? La respuesta que estoy buscando es una explicación de la relación entre KMS y el framebuffer.

He estado usando uvesafb para obtener una resolución nativa en el tty. Mi propósito aquí es entender cómo funcionará eso en un sistema con KMS. También ayudaría a cubrir cosas como ... ¿Desplazarse más rápido con KMS? ¿Las utilidades como fbterm y fbida funcionan igual? ¿Es mejor la estabilidad?

En primer lugar, existen básicamente dos tipos de controladores clásicos de framebuffer:

• Controladores genéricos de hardware y firmware (por ejemplo, vga, vesafb / uvesafb, efifb)
• Controladores específicos de hardware (por ejemplo, rivafb, atyfb)

Todos los controladores clásicos de framebuffer tenían soporte básico de configuración de modo, pero expusieron poco o ningún soporte para la aceleración de hardware.

Con el diseño clásico de X, esto no era realmente un problema: para obtener la aceleración 2D, el servidor X se ejecutaba como root y podía acceder al hardware directamente. Básicamente omitió por completo el controlador framebuffer. Para 3D (y soporte 2d en tarjetas más nuevas), también usaría un controlador DRM kernel que mediaba el acceso y administraba la memoria de video.

En esta configuración, había dos lugares donde se realizaba la configuración de modo: tanto en el controlador de framebuffer del kernel como en el servidor X del espacio de usuario. Esta duplicación de código (y las peleas ocasionales entre conductores, por ejemplo, en el interruptor VT) no fueron ideales.

Además, había dos controladores separados en el núcleo para la misma pieza de hardware: el controlador framebuffer y el controlador DRM. En algunos casos (por ejemplo, pre-kms intelfb), puede cargar uno u otro, pero no ambos al mismo tiempo.

KMS fue la solución a estos problemas. Eso:

• Fusiona el controlador framebuffer específico del hardware del núcleo y el controlador drm en un solo controlador.
• Proporciona una interfaz para que el servidor X use para controlar la configuración de modo, de modo que el servidor X no tenga que acceder directamente al hardware. (De hecho, con KMS, el servidor X ya no necesita permisos de root).

Algunas notas interesantes: La migración a lo que ahora es KMS en realidad comenzó alrededor de 2004; vea el correo electrónico de Jon Smirl en la arquitectura de la consola .

Para responder a sus preguntas más específicas:

• La velocidad generalmente no será peor que la de uno de los controladores genéricos no acelerados (por ejemplo, VGA, vesafb), pero la consola de texto de framebuffer KMS fue diseñada para su conveniencia y uso de emergencia en lugar de la velocidad, y la consola no está completamente acelerada en algunos controladores. Las líneas largas envueltas son bastante malas en las tarjetas de inteligencia, por ejemplo.
• Las aplicaciones diseñadas para usar las antiguas interfaces framebuffer seguirán funcionando en un framebuffer KMS.

KMS establece la resolución y la profundidad de visualización en el espacio del kernel en lugar del espacio del usuario. Entonces sí, lo reemplaza. Permite la resolución nativa en el framebuffer.

Configuración del modo kernel