¿Cómo se organiza la pila de gráficos de Linux?

¿Alguien puede explicar (con suerte con una imagen), cómo está organizada la pila de gráficos de Linux? Escucho todo el tiempo sobre X / GTK / GNOME / KDE, etc., pero realmente no tengo idea de lo que realmente hacen y cómo interactúan entre sí y con otras partes de la pila. ¿Cómo encajan Unity y Wayland?

El sistema X Window utiliza una arquitectura cliente-servidor. El servidor X se ejecuta en la máquina que tiene la pantalla (monitores + dispositivos de entrada), mientras que los clientes X pueden ejecutarse en cualquier otra máquina y conectarse al servidor X usando el protocolo X (no directamente, sino más bien usando una biblioteca, como Xlib, o el XCB controlado por eventos sin bloqueo más moderno). El protocolo X está diseñado para ser extensible y tiene muchas extensiones (ver xdpyinfo(1)).

El servidor X solo realiza operaciones de bajo nivel, como crear y destruir ventanas, realizar operaciones de dibujo (hoy en día la mayoría de los dibujos se realizan en el cliente y se envían como una imagen al servidor), enviar eventos a las ventanas, ... Puede ver cuán poco un servidor X lo hace al ejecutar X :1 &(usar cualquier número que ya no haya sido usado por otro servidor X) o Xephyr :1 &(Xephyr ejecuta un servidor X integrado en su servidor X actual) y luego ejecuta xterm -display :1 &y cambia al nuevo servidor X (es posible que deba configurar la autorización X usando xauth(1)).

Como puede ver, el servidor X hace muy poco, no dibuja barras de título, no minimiza / iconiza ventanas, no administra la colocación de ventanas ... Por supuesto, puede controlar la ubicación de ventanas manualmente ejecutando un comando como xterm -geometry -0-0, pero generalmente tendrá un cliente X especial que hace las cosas anteriores. Este cliente se llama administrador de ventanas . Solo puede haber un administrador de ventanas activo a la vez. Si todavía tiene abierto el servidor X al descubierto de los comandos anteriores, se puede tratar de ejecutar un gestor de ventanas en él, como twm, metacity, kwin, compiz, larswm, pawm, ...

Como dijimos, X solo realiza operaciones de bajo nivel, y no proporciona conceptos de nivel superior como botones, menús, barras de herramientas, ... Estos son proporcionados por bibliotecas llamadas kits de herramientas , por ejemplo: Xaw, GTK, Qt, FLTK, ...

Los entornos de escritorio son colecciones de programas diseñados para proporcionar una experiencia de usuario unificada. Por lo tanto, los entornos de escritorio generalmente proporcionan paneles, iniciadores de aplicaciones, bandejas del sistema, paneles de control, infraestructura de configuración (dónde guardar la configuración). Algunos entornos de escritorio conocidos son KDE (creado con el kit de herramientas Qt), Gnome (con GTK), Enlightenment (con sus propias bibliotecas de kit de herramientas), ...

Algunos efectos de escritorio modernos se realizan mejor con hardware 3D. Entonces aparece un nuevo componente, el administrador compuesto . Una extensión X, la extensión XComposite, envía el contenido de la ventana al administrador compuesto. El administrador compuesto convierte esos contenidos en texturas y usa hardware 3D a través de OpenGL para componerlos de muchas maneras (mezcla alfa, proyecciones 3d, ...).

No hace mucho tiempo, el servidor X hablaba directamente con los dispositivos de hardware. Una parte importante del manejo de este dispositivo se ha trasladado al kernel del sistema operativo: DRI (que permite el acceso al hardware 3D por X y clientes de renderización directa), evdev (interfaz unificada para el manejo del dispositivo de entrada), KMS (configuración del modo de gráficos móviles al kernel) , GEM / TTM (gestión de memoria de texturas).

Entonces, con la complejidad del manejo de dispositivos ahora mayormente fuera de X, se hizo más fácil experimentar con sistemas de ventanas simplificados. Wayland es un sistema de ventanas basado en el concepto de administrador compuesto, es decir, el sistema de ventanas es el administrador compuesto. Wayland utiliza el manejo del dispositivo que se ha movido fuera de X y se procesa con OpenGL.

En cuanto a Unity, es un entorno de escritorio diseñado para tener una interfaz de usuario adecuada para netbooks.

La pila tradicional se basa en 3 componentes principales:

• Servidor X que maneja la visualización
• Administrador de ventanas que coloca ventanas en marcos, maneja minimizar ventanas, etc. Eso es parte de la separación del mecanismo de la política en Unix
• Clientes que realizan tareas útiles como mostrar el sitio web stackexchange. Pueden usar el protocolo X directamente (suicidio), usar xlib o xcb (un poco más fácil) o usar herramientas como GTK + o QT.

La arquitectura X se convirtió en red, lo que permitió a los clientes estar en un host separado y luego en un servidor.

Hasta aquí todo bien. Sin embargo, esa era la imagen de hace mucho tiempo. Hoy en día no es la CPU la que maneja los gráficos sino la GPU. Ha habido varios intentos de incorporarlo en el modelo, y colocarlo cuando el kernel entre en su lugar en mayor medida.

En primer lugar, se han hecho algunas suposiciones con respecto al uso de la tarjeta gráfica. Por ejemplo, solo se supuso el renderizado en pantalla. No puedo encontrar esta información en Wikipedia en este momento, pero DRI 1 también asumió que solo una aplicación usará OpenGL al mismo tiempo (no puedo citar de inmediato, pero puedo desenterrar el error donde estaba cerca como WONTFIX con una nota para esperar a DRI 2)

Se han propuesto algunas soluciones temporales para renderizado indirecto (necesario para WM compuesto):

• XGL: propuesta temprana que admite aplicaciones que hablan directamente con la tarjeta
• AIGLX: propuesta aceptada que utiliza las propiedades de red del protocolo OpenGL
• Solución patentada de NVidia

Se iniciaron los trabajos de arquitectura más nueva (DRI 2). Eso incluyó:

• Soporte en el núcleo para el manejo de memoria (GEM / TTM)
• El modo de configuración del kernel (KMS) permite cambiar la resolución en el kernel y, por lo tanto, evitar demoras al cambiar entre X y la consola y algunas otras características (como mostrar un mensaje de pánico incluso si X se está ejecutando, que se planea implementar IIRC).

De alguna manera ortogonal para pasar al kernel, se ha iniciado el trabajo en los controladores de galio. La biblioteca de Mesa comenzó como implementación de OpenGL en la CPU y luego comenzó a usar la aceleración de GPU. Siempre se ha ajustado a OpenGL. En OpenGL 3.0, el modelo ha cambiado significativamente y la reescritura de la biblioteca era inevitable. Sin embargo, están aprovechando la oportunidad para dividir el código en varias capas extrayendo código común y proporcionando API de bajo nivel que permite implementar varias API 3D encima, lo que permite, por ejemplo, que Wine proporcione DirectX hablando directamente con Gallium en lugar de pasar por OpenGL Capa API (que puede no tener llamadas directas 1-1).

Wayland es un proyecto que considera lo anterior un poco complicado y con demasiada "historia". El diseño de 1984 (aunque altamente modificado y adaptado) no corresponde al comienzo de 21 c. según los proponentes

Se supone que debe ofrecer una mayor flexibilidad y un mejor rendimiento, aunque todavía faltan algunas características importantes, como el soporte completo de OpenGL (e importante para algunos: soporte de red).

Un poco más sobre entornos de escritorio y gestores de ventanas. El administrador de ventanas es una aplicación responsable de cómo se comportará la ventana; por ejemplo, es responsable de administrar espacios de trabajo, dibujar la barra de título (lo que está en la parte superior de la pantalla con el título de ventana y los botones minimizar / maximizar / cerrar), etc.

En primer lugar, solo se usó WM mínimo, pero luego el usuario comenzó a querer entornos de escritorio, es decir, una versión más destacada, que incluía inicio de menú, fondo de escritorio, etc. Sin embargo, la mayoría de las partes del entorno de escritorio no es un administrador de ventanas, aunque a menudo están integradas.

Después de algún tiempo, se introdujeron los WM compuestos que usan OpenGL y renderizado indirecto para hacer su trabajo. Proporcionan no solo efectos gráficos, sino que también permiten una implementación más sencilla de algunas funciones de accesibilidad (como la lupa).

En primer lugar, realmente no hay una pila de gráficos de Linux. Linux no tiene capacidades de visualización gráfica.

Sin embargo, las aplicaciones de Linux pueden usar pantallas gráficas y hay varios sistemas diferentes para hacerlo. Los más comunes están construidos sobre X ventanas.

X es un protocolo de red porque en medio de una pila de protocolos X puede tener una red como componente estándar. Veamos un caso de uso específico. Un físico en Berlín quiere realizar un experimento en el CERN en Suiza con uno de los colisionadores de partículas nucleares. Inicia sesión de forma remota y ejecuta un programa de análisis de datos en una de las matrices de supercomputadoras del CERN y grafica los resultados en su pantalla.

En Berlín, el físico tiene un dispositivo de terminal X que ejecuta un software de servidor X que proporciona una capacidad de visualización gráfica para aplicaciones remotas. El software del servidor X tiene un framebuffer que se comunica con el controlador de dispositivo específico para el hardware específico. Y el software del servidor X habla el protocolo X. Por lo tanto, las capas pueden ser dispositivo gráfico-> controlador de dispositivo-> buffer de cuadro-> servidor X-> protocolo X

Luego, en Suiza, la aplicación se conecta a una pantalla utilizando el protocolo X y envía comandos de visualización gráfica como "dibujar rectángulo" o "mezcla alfa". La aplicación probablemente utiliza una biblioteca gráfica de alto nivel y esa biblioteca probablemente, a su vez, se basará en una biblioteca de nivel inferior. Por ejemplo, la aplicación se puede escribir en Python usando el kit de herramientas WxWidget que está construido sobre GTK, que usa una biblioteca llamada Cairo para los comandos de dibujo gráficos básicos. También puede haber OPENGL también en la parte superior de El Cairo. Las capas pueden ser así: WxWidgets-> GTK-> Cairo-> X Toolkit-> X protocol. Claramente, es el protocolo en el medio que conecta las cosas, y dado que Linux también es compatible con los sockets UNIX, un transporte de datos completamente interno, estos dos tipos de cosas pueden ejecutarse en una máquina si así lo desea.

X se refiere al protocolo y a cualquier cosa fundamental para la arquitectura, como el servidor X que ejecuta la pantalla gráfica, el dispositivo señalador y el teclado.

GTK y QT son dos bibliotecas GUI de propósito general que admiten ventanas, cuadros de diálogo, botones, etc.

GNOME y KDE son dos entornos de escritorio que administran las ventanas en el escritorio gráfico, proporcionan applets y cosas útiles como barras de botones. También permiten que múltiples aplicaciones se comuniquen a través del servidor X (dispositivo X-terminal) incluso si las aplicaciones se ejecutan en diferentes computadoras remotas. Por ejemplo, copiar y pegar es una forma de comunicación entre aplicaciones. GNOME está construido sobre GTK. KDE está construido sobre QT. Y es posible ejecutar aplicaciones GNOME en un escritorio KDE o aplicaciones KDE en un escritorio GNOME porque todas funcionan con el mismo protocolo X subyacente.

Esta es su organización, aprenderá más de esta imagen que de varias páginas de texto:

Linux en el escritorio y algunos servidores todavía son todos gráficos X y frame buffer. Debajo de la ventana X: viene GTK + y Qt, SÍ AMBOS usan el sistema X, de nuevo hay muchos entornos de escritorio: Gnome, KDE usa la pantalla X y sus shells, etc.

Por cierto, hubo un video reciente de linux conf (http://blip.tv/file/4693305/). Keith Packard de Intel habló sobre X y GL * Fue interesante.