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


31

¿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?


1
Video del desarrollador de Xorg Keith Packard sobre el futuro de los gráficos de Linux en linux.conf.au en enero de 2011: linuxconfau.blip.tv/file/4693305 Esto cubre tanto el modelo actual como los planes para el futuro cercano y mediano.
mattdm

arstechnica.com/open-source/guides/2011/03/… también es un artículo reciente que analiza la pila y elogia el compromiso de Ubuntu con Wyland.
apoorv020

Sí, aunque ese artículo está lleno de piezas faltantes e incluso inexactitudes y, a mi juicio, no es terriblemente coherente.
mattdm

@mattdm: incluso si es incoherente, etc., entra en la imagen más grande del tema, que no se menciona directamente en las respuestas a continuación.
apoorv020

Respuestas:


29

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.


No estoy de acuerdo con la última oración, pero es una respuesta muy rica en información. +1.
missingfaktor

"(hoy en día la mayoría de los dibujos se realizan en el cliente y se envían como una imagen al servidor)" Eso no es realmente cierto, bastantes de ellos realizarán el renderizado opengl a través de la extensión xgl, incluso sin un compositor.
Adam D. Ruppe

13

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).


Entonces, un marco como QT permite que una aplicación se dibuje sola, y los entornos de escritorio como Gnome y KDE deciden cómo dibujar múltiples ventanas en el mismo escritorio.
apoorv020

No exactamente. QT permite que la aplicación se dibuje sola (es decir, permite que la aplicación especifique cómo se comporta). WM como metacity (para Gnome) o kwin (para KDE) especifica cómo se comporta la ventana en el entorno. El entorno de escritorio es un paquete que contiene WM, paneles y otras aplicaciones como PIM que proporcionan una experiencia de superposición para el usuario.
Maciej Piechotka

9

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.


77
Esta respuesta está muy desactualizada. El núcleo ha estado involucrado en los gráficos durante mucho tiempo.
mattdm

55
Para ampliar el comentario de mattdm, incluso cuando los gráficos están siendo controlados por controladores desde fuera del árbol del kernel, todavía usan los servicios del kernel para controlar el acceso a los recursos gráficos. El núcleo siempre se encuentra en la parte inferior de la pila.
dmckee

No estaría de acuerdo con que el núcleo esté en la parte inferior de la pila. Por supuesto, los controladores de dispositivos utilizan los servicios del kernel para obtener acceso privilegiado al hardware, pero una aplicación X está hablando por la red, por lo que hay más capas más allá de la tarjeta de red.
Michael Dillon

X se basa en la red, aunque es importante para algunas configuraciones en muchos, es el detalle de la implementación (especialmente para equipos de escritorio) y existen extensiones como MIT-SHM. El kernel desempeña un papel importante en la pila actual, ya que proporciona controladores DRM, KMS y maneja texturas.
Maciej Piechotka

DRM y KMS son más sobre controladores de dispositivos que ahora tienen que comunicarse a través de una conexión de red interna dedicada a una CPU de representación gráfica en la tarjeta gráfica. Esto puede ser parte de la pila gráfica, y puede que no (es decir, Amazon EC2 Linux).
Michael Dillon

2

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

ingrese la descripción de la imagen aquí


1
¿De dónde es? Hay algunos números en un círculo, ¿qué significan? Y esto parece específico de Wayland, mientras que creo que X solo o Mir tendría diferentes organizaciones.
Muru

1
@muru haciendo una búsqueda inversa, se me ocurrió esto ... en.wikipedia.org/wiki/EGL_%28API%29 ... aunque actualmente está alojado en imgur, ya que parece ser una carga. ¿Pero acepto vincular la imagen de origen y dónde se muestra es la forma correcta de hacerlo?
jmunsch

1
¿Pero esta imagen realmente no explica nada más allá del servidor x? Mirándote es X11-clientsolo una gota, pero están pasando muchas cosas en esa gota. Según lo explicado por las otras respuestas realmente impresionantes.
jmunsch

1

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.