La nueva arquitectura de las X

Autor: Armonth | El martes 21 de marzo del 2006 @ 11:32.
  • De: Diego Gonzalez en El Blog de un gnomero
  • Enlace original: ya no existe
  • Fecha original: 22 de Febrero del 2005
  • Licencia: ??? (se le presupone una licencia libre)

Armonth: Como era de esperar (la url del blog era una IP con puerto 8080 en vez de el estándar TCP 80) el sitio ha desaparecido sin dejar rastro. Suerte que lo copie en un texto.

Se han corregido dos o tres faltas de ortografía, nada grave.

Actualización: Del artículo ni rastro, pero ahí archivada una discusión al respecto del artículo en Barrapunto.

Este fin de semana he estado con un amigo al cual le gusta GNU/Linux y estar enterado de como funcionan las cosas, esta interesado en saber como encajan todos los desarrollos que se están llevando acabo en el mundo de las X. Como supongo que hay mucha gente en la misma situación he decidido escribir este pequeño resumen.

El objetivo último que se persigue mediante el desarrollo de todos los proyectos que a continuación voy a detallar es conseguir que el servidor X-Window sea más rápido, use tecnologías actuales y soporte las nuevas tendencias, tanto hardware como de otro tipo, así mismo se pretende en la medida de lo posible reducir el código del servidor, cuanto más pequeño más sencillo de mantener.

Los Drivers

Actualmente los drivers son un mundo y suponen la mayor parte del código del servidor X (de los 49 megas de código fuente que tiene el servidor X.Org 30 megas corresponden a drivers), una gran parte del código de cada driver se ocupa de realizar la configuración de los dispositivos gráficos y el cambio de modo gráfico. Esta función debería ser realizada por el núcleo, para conseguir esto se esta modificando el fbdev del núcleo 2.6 para que, cuando se detecte un dispositivo gráfico en el sistema se lance un programa en espacio de usuario para extraer del dispositivo una lista de modos gráficos estándar y la información necesaria para cambiar entre ellos. Esta información será expuesta en el directorio sys y consistirá de una lista de modos y del modo activo. Un usuario normal podrá cambiar el modo activo por otro siempre que este se encuentre en la lista de modos soportados. El superusuario tendrá permiso para definir nuevos modos.

Este cambio supondrá la eliminación de una parte importante del código de los drivers del sistema X-Window.

El servidor actualmente también se encarga de configurar el bus PCI para enrutar las operación gráficas entre dispositivos cuando hay más de un adaptador gráfico en el sistema, esto supone que el estado hardware que ve el núcleo no coincide siempre con el estado que las X ven, lo cual suele producir cuelgues del sistema. Se está trabajando para que todas estas operaciones también las realice el núcleo, hay que modificar para ello el fbdev (el sistema de dispositivos gráficos del núcleo) para que soporte múltiples dispositivos.

Otra gran parte de los drivers que el servidor tiene son para dispositivos de entrada, los más usuales son teclados, ratones y joysticks, no obstante los núcleos 2.6 tienen un excelente soporte para todos estos dispositivos, por los cual se ha diseñado un traductor de eventos (evdev) que elimina la necesidad de tener estos drivers en el servidor.

Llegados a este punto tendríamos un servidor X con drivers que se encargarían únicamente de dibujar, el enturado de comandos, inicialización de dispositivos gráficos y cambio de modo de vídeo lo realizaría el núcleo, así mismo, se usaría el sistema de entrada del núcleo, las X solo tendrían que traducir los eventos que el núcleo proporcionaría para poder usarlos.

Con esta arquitectura las X seguirían teniendo dos drivers por así decirlo, un driver XAA para realizar operaciones 2D y otro driver DRI para realizar operaciones 3D, los drivers 3D se encuentran en Mesa3d.

El propósito de proyectos como Xgl y Xglx consisten en eliminar los drivers 2D del servidor gráfico y usar Mesa como interfaz para acceder a las operaciones gráficas del sistema. Si esto se consiguiese tendríamos un servidor gráfico en el cual ya no sería necesario mantener toda la arquitectura de drivers 2D pues todas las operaciones gráficas se traducirían en comandos 3D. Es decir, OpenGL se convertiría en el único interfaz hardware de las X-Window. Para poder llegar a este punto haría falta un “traductor” de comandos que transformarse las operaciones 2D en operaciones 3D, este traductor es glitz, también habría que conseguir que mesa pudiese dibujar sobre el framebuffer del núcleo, para conseguir esto se esta trabajando mesa-solo, una versión de Mesa3D que no precisa de las X-Window para dibujar.

¿Por qué Mesa necesita las X para dibujar?

Mesa3d sabe interactuar con el hardware de vídeo del sistema y pintar objetos 3D, no obstante necesitar del servidor X para obtener la memoria para colar las superficies sobre las que trabaja, Mesa3d no se ocupa de estos detalles y se comunica con las X mediante el protocolo GLX para obtener esta memoria y sincronizar su operación con el resto del sistema, por tanto, para que Mesa pudiese funcionar sobre el frambuffer necesitaría de una implementación similar, mesa-solo incluye un hack llamado mini-glx que realiza las operaciones de bajo nivel necesarias. No obstante se ha visto que esta implementación no deja de ser eso, un hack, existe un API estándar EGL (khronos.org) que tiene como función ser el interfaz de bajo nivel entre el sistema y la implementación OpenGL y ahora se está trabajando en sustituir mini-glx por EGL.

Resumiendo: llegados a este punto tenemos un sistema que usa el núcleo para cambiar de modo, enrutar las operaciones gráficos y obtener todos los eventos hardware, a través de glitz traduce todas las operaciones de dibujo que los clientes tradicionales mandan en comandos 3D y OpenGL es el interfaz con el hardware. Esto es, no hay drivers gráficos en el servidor X-Window.

El Sistema de Dibujo

El sistema de dibujo actual del servidor gráfico tiene más de 10 años, este sistema no se construyó para durar más de 2 años, no obstante no ha habido nadie con la disposición ni conocimientos para sustituirlo. El caso es que hoy en día los sistemas gráficos están tendiendo a basar su funcionamiento en primitivas vectoriales, se podría construir sistemas gráficos que al aumentar de tamaño no perdiesen calidad (no pixelasen), Cairo es la respuesta del grupo FreeDesktop. Cairo tiene además varios backend uno de ellos es capaz de producir pngs, otro PDF, otro es capaz de hablar el protocolo X11 (para mantener la compatibilidad con servidores antiguos), otro habla XRender y por último, otro backend permite transformar las operaciones 2D en 3D (glitz).

El último backend (glitz) usa GLX para negociar el área de memoria a usar con el servidor gráfico, si ambos, cliente y servidor están en la misma máquina se realiza el dibujado directo, es decir, las X solo intervienen para negociar y sincronizar el estado del cliente, pero todas las operaciones gráficas se mandan directamente al núcleo, este sistema es muy rápido.

Actualmente Pango (el sistema de posicionamiento de texto Unicode de GTK+) y GDK (la capa de bajo nivel del toolkit gráfico GTK+) están siendo portados para usar Cairo como sistema nativo de dibujo.

La Biblioteca libX11

Contiene la implementación del protocolo X y otros sistemas (localización, gestión del color, etc.) ocurre que la gran parte de esta biblioteca no se usa así mismo no soporta el acceso a sus funciones mediante diferentes hebras, lo cual es claramente una desventaja cuando se espera que entre este año y el que viene se comience la comercialización de sistemas de escritorio con procesadores dual-core. Para subsanar este problema un grupo está construyendo XCB, una biblioteca que pretende implementar de forma eficiente (tanto es espacio como en velocidad) aquellas partes de protocolo X más usadas, la generación del código se hace forma automática mediante XSLT. Actualmente esta biblioteca implementa parte del protocolo X11, y los protocolos GLX, XRender y XRandR, y tiene un tamaño mucho menor que X11, así mismo permite el acceso desde diferentes hebras.

A continuación se presentan tres diagramas mostrando como funciona el servidor actual y como funcionaría el servidor que implementase todas las mejoras en las que se esta trabajando.

Armonth: Lo siento, no dispongo de los diagramas

Estado Actual:

  • FbDev está siendo adaptado para manipular varios adaptadores gráficos y permitir la manipulación del modo desde el espacio de usuario, actualmente ya hay parches que permiten realizar lo descrito.
  • Se está procediendo a la implementación de EGL en Mesa3D, aunque mini-glx es funcional.
  • XGL se ha conseguido que funcione sobre el framebuffer.
  • Cairo se espera que sea estable en Junio del 2005.
  • Pango ya ha sido portado a Cairo.
  • GDK está siendo portado a Cairo.
  • Se espera que GTK+ sobre Cairo sea completamente funcional en Agosto de 2005.
  • XCB está siendo implementado, quedan muchos tests por hacer antes de que Qt y GTK+ puedan comenzar a usarlo.

Comentarios