Servidor X.Org

X.Org Server es la implementación gratuita y de código abierto del servidor de visualización del sistema X Window administrado por la Fundación X.Org.

Las implementaciones del protocolo del sistema X Window del lado del cliente existen en forma de bibliotecas X11, que sirven como API útiles para comunicarse con el servidor X. Existen dos bibliotecas X importantes para X11. La primera de estas bibliotecas fue Xlib, la API X11 en lenguaje C original, pero más tarde en 2001 se creó otra biblioteca X en lenguaje C, XCB. Existen otras bibliotecas X más pequeñas, como interfaces para Xlib y XCB en otros lenguajes, y como interfaces más pequeñas para Xlib y XCB en otros lenguajes. Bibliotecas X independientes.

Los servicios con los que X.Org Foundation soporta X Server incluyen el empaquetado de los lanzamientos; certificación (de pago); evaluación de mejoras al código; desarrollar el sitio web y manejar la distribución de donaciones monetarias. Los lanzamientos están codificados, documentados y empaquetados por desarrolladores globales.

Arquitectura de software

El servidor X.Org implementa el lado del servidor del protocolo central del sistema X Window versión 11 (X11) y sus extensiones, p.e. RandR.

La versión 1.16.0 integra soporte para el inicio y la administración basados en systemd, lo que mejoró el rendimiento y la confiabilidad del arranque.

Dispositivo independiente X (DIX)

El Device Independent X (DIX) es la parte del servidor X.Org que interactúa con los clientes e implementa la renderización de software. El bucle principal y la entrega de eventos son parte del DIX.

Un servidor X tiene una enorme cantidad de funcionalidades que deben implementarse para admitir el protocolo central X. Esto incluye tablas de códigos, rasterización y almacenamiento en caché de glifos, XLFD y la API de renderizado principal que dibuja primitivos gráficos.

X dependiente del dispositivo (DDX)

El dispositivo X dependiente (DDX) es la parte del servidor x que interactúa con el hardware. En el código fuente del servidor X.Org, cada directorio bajo "hw" corresponde a un DDX. El hardware comprende tarjetas gráficas, así como mouse y teclados. Cada controlador es específico del hardware y se implementa como un módulo cargable independiente.

Controlador de gráficos 2D

Por razones históricas, el servidor X.Org todavía contiene controladores de dispositivos gráficos que admiten alguna forma de aceleración de renderizado 2D. En el pasado, la configuración del modo se realizaba mediante un controlador de dispositivo de gráficos del servidor X específico de algún hardware controlador de vídeo (p. ej., una GPU). A esta funcionalidad de configuración de modo, se agregó soporte adicional para aceleración 2D cuando estuvo disponible con varias GPU. La funcionalidad de configuración de modo se trasladó al DRM y se expone a través de una interfaz de configuración de modo DRM; el nuevo enfoque se denomina "configuración de modo de núcleo" (kernel mode-setting). (Kms). Pero la aceleración del renderizado 2D se mantuvo.

En Debian, los controladores de gráficos 2D para el servidor X.Org están empaquetados individualmente y se denominan xserver-xorg-video-*. Después de la instalación, el archivo del controlador de gráficos 2D se encuentra en /usr/lib/xorg/modules/drivers/. El paquete xserver-xorg-video-nouveau instala nouveau_drv.so con un tamaño de 215 KB, el controlador propietario Nvidia GeForce instala un archivo de 8 MiB llamado nvidia_drv.so y Radeon Software instala fglrx_drv.so con un tamaño de aproximadamente 25MiB.

Los controladores de dispositivos gráficos gratuitos y de código abierto disponibles se están desarrollando dentro del proyecto Mesa 3D. Si bien estos se pueden recompilar según sea necesario, el desarrollo de los controladores de gráficos DDX 2D propietarios se facilita enormemente cuando el servidor X.Org mantiene una API/ABI estable en varias de sus versiones.

Con la versión 1.17 se introdujo un método genérico para la configuración de modo. El paquete xf86-video-modesetting, el paquete Debian llamado xserver-xorg-video-modesetting, fue retirado y el DDX de configuración de modo genérico que contenía se trasladó al paquete paquete de servidor para convertirse en el DDX predeterminado habilitado para KMS, compatible con la gran mayoría de las GPU AMD, Intel y NVidia.

El 7 de abril de 2016, Michel Dänzer, empleado de AMD, lanzó xf86-video-ati versión 7.7.0 y xf86-video-amdgpu versión 1.1.0, esta última incluye soporte para su microarquitectura Polaris.

Arquitecturas de aceleración

Existen (al menos) XAA (XFree86 Acceleration Architecture), EXA, UXA y SNA.

En el sistema X Window, la Arquitectura de aceleración XFree86 (XAA) es una arquitectura de controlador para hacer que la aceleración de hardware 2D de una tarjeta de video esté disponible para el servidor X.. Fue escrito por Harm Hanemaayer en 1996 y lanzado por primera vez en XFree86 versión 3.3. Fue completamente reescrito para XFree86 4.0. Se eliminó nuevamente de X.Org Server 1.13.

La mayoría de los controladores implementan la aceleración utilizando el módulo XAA. XAA está activado de forma predeterminada, aunque la aceleración de funciones individuales se puede desactivar según sea necesario en el archivo de configuración del servidor (XF86Config o xorg.conf).

El controlador del chipset ARK fue la plataforma de desarrollo original para XAA.

En la versión 6.9/7.0 de X.Org Server, EXA se lanzó como reemplazo de XAA, ya que XAA casi no ofrece ninguna ventaja de velocidad para las tarjetas de video actuales. EXA se considera un paso intermedio para convertir todo el servidor X al uso de OpenGL.

Glamour

Glamour es un controlador de aceleración 2D genérico, independiente del hardware para el servidor X que traduce las primitivas de renderizado de X en operaciones OpenGL, aprovechando cualquier controlador 3D OpenGL existente. De esta manera, es funcionalmente similar a Quartz Extreme y QuartzGL (aceleración de rendimiento 2D) para Apple Quartz Compositor.

El objetivo final de GLAMOUR es obsoleto y reemplazar todos los controladores de dispositivos gráficos DDX 2D y arquitecturas de aceleración, evitando así la necesidad de escribir controladores específicos X 2D para cada chipset gráfico compatible. Glamour requiere un controlador 3D compatible con sombreadores.

Se aceptó el ajuste del rendimiento de Glamour para Google Summer of Code 2014. Glamour es compatible con Xephyr y DRI3 y puede impulsar algunas operaciones entre un 700 % y un 800 %. Desde su incorporación a la versión 1.16 del servidor X.Org, se continuó el desarrollo de Glamour y se publicaron parches para la versión 1.17.

Virtualización

Existe un DDX distinto y especial para instancias del servidor X.Org que se ejecutan en un sistema invitado dentro de un entorno virtualizado: xf86-video-qxl, un controlador para el "dispositivo de vídeo QXL". SPICE utiliza este controlador aunque también funciona sin él.

En los repositorios de Debian se llama xserver-xorg-video-qxl, cf. https://packages.debian.org/buster/xserver-xorg-video-qxl

Pila de entrada

En Debian, los controladores relacionados con la entrada se encuentran en /usr/lib/xorg/modules/input/. Estos controladores se denominan, p. evdev_drv.so, mouse_drv.so, synaptics_drv.so o wacom_drv.so.

Con la versión 1.16, el servidor X.Org obtuvo soporte para la biblioteca libinput en forma de un contenedor llamado xf86-input-libinput. En el XDC 2015 en Toronto, se presentó libratbag como una biblioteca genérica para admitir ratones configurables. xserver-xorg-input-joystick es el módulo de entrada para que el servidor X.Org maneje joysticks y gamepads clásicos, que no está diseñado para jugar juegos bajo X, sino para controlar el cursor con un joystick o mando.

Otros componentes DDX

XWayland

XWayland es una serie de parches sobre la base de códigos del servidor X.Org que implementan un servidor X que se ejecuta en el protocolo Wayland. Los parches son desarrollados y mantenidos por los desarrolladores de Wayland para la compatibilidad con las aplicaciones X11 durante la transición a Wayland, y se mainlined en la versión 1.16 del X.Org Server en 2014. Cuando un usuario ejecuta una aplicación X desde Weston, pide a XWayland que preste servicio a la solicitud.

XQuartz

XQuartz es una serie de parches de Apple Inc. para integrar el soporte para el protocolo X11 en su Compositor de Cuarzo, de manera similar a cómo XWayland integra X11 en los compositores Wayland.

Xspice

Xspice es un controlador de dispositivo para el servidor X.Org. Soporta el dispositivo QXL framebuffer e incluye un script envolvente que permite lanzar un servidor X.Org cuya pantalla se exporta a través del protocolo SPICE. Esto permite el uso de SPICE en un entorno de escritorio remoto, sin necesidad de virtualización KVM.

Xephyr

Xephyr es una aplicación X-on-X. Desde la versión 1.16.0, Xephyr sirve como el entorno de desarrollo primario para el nuevo subsistema de aceleración 2D (Glamor), permitiendo un rápido desarrollo y pruebas en una sola máquina.

RandR

RandR ()tamaño y rotación) es un protocolo de comunicaciones escrito como una extensión al protocolo X11. XRandR proporciona la capacidad de redimensionar, rotar y reflejar la ventana raíz de una pantalla. RandR es responsable de establecer la tasa de actualización de pantalla. Permite el control de múltiples monitores.

IPC

El servidor X.Org y cualquier cliente x se ejecutan como procesos distintos. En Unix/Linux, un proceso no sabe nada sobre ningún otro proceso. Para comunicarse con otro proceso, depende total y absolutamente del kernel para moderar la comunicación a través de los mecanismos de comunicación entre procesos (IPC) disponibles. Los sockets de dominio Unix se utilizan para comunicarse con procesos que se ejecutan en la misma máquina. Las llamadas a funciones de socket especiales son parte de la interfaz de llamadas del sistema. Aunque los sockets de dominio de Internet se pueden utilizar localmente, los sockets de dominio de Unix son más eficientes, ya que no tienen la sobrecarga del protocolo (sumas de verificación, órdenes de bytes, etc.).

El servidor X.Org no utiliza D-Bus.

Los sockets son el método de comunicación entre procesos (IPC) más común entre los procesos del servidor X y sus diversos clientes X. Proporciona la interfaz de programación de aplicaciones (API) para la comunicación en el dominio TCP/IP y también localmente sólo en el dominio UNIX. Hay varias otras API descritas en X Transport Interface, por ejemplo TLI (Transport Layer Interface). Otras opciones para IPC entre el cliente-servidor X requieren extensiones del sistema X Window, por ejemplo MIT Shared Memory Extension (MIT-SHM).

Configuración multiasiento

Multi-asiento se refiere a un conjunto de una sola computadora con múltiples "asientos", lo que permite a varios usuarios sentarse frente a la computadora, iniciar sesión y usar la computadora al mismo tiempo de forma independiente. La computadora tiene varios teclados, ratones y monitores conectados, cada "asiento" teniendo asignado un teclado, un mouse y un monitor. Un "asiento" consta de todos los dispositivos de hardware asignados a un lugar de trabajo específico. Consta de al menos un dispositivo gráfico (tarjeta gráfica o simplemente una salida y el monitor adjunto) y un teclado y un mouse. También puede incluir cámaras de video, tarjetas de sonido y más.

Debido a la limitación del sistema VT en el kernel de Linux y del protocolo central X (en particular, cómo X define la relación entre la ventana raíz y una salida de la tarjeta gráfica), el multi-asiento no funciona. Está listo para usar para la distribución habitual de Linux, pero requiere una configuración especial.

Existen estos métodos para configurar un ensamblaje de varios asientos:

• múltiple Servidores Xephyr sobre un servidor host xorg-servidor
• múltiples instancias de un servidor xorg
  • una tarjeta gráfica por asiento
  • una tarjeta gráfica para todos los asientos

Las opciones de línea de comandos utilizadas del servidor xorg son:

• -isolateDevice bus-id Restrict device resets (output) to the device at bus-id. La cadena bus-id tiene la forma bustype:bus:dispositivo:función (por ejemplo, ‘PCI:1:0:0’). En la actualidad, sólo se admite el aislamiento de los dispositivos PCI; es decir, esta opción se ignora si el bustipo es otra cosa que la PCI.
• vtXX el predeterminado por ejemplo. Debian 9 Stretch es 7, es decir, pulsando Ctrl+Alt+F7 el usuario puede cambiar al VT ejecutando el servidor xorg.

Solo el usuario en el primer monitor tiene el uso de consolas vt y puede usar Ctrl+Alt+Fx para seleccionarlos. Los otros usuarios tienen una pantalla de inicio de sesión de GDM y pueden usar el servidor xorg normalmente, pero no tienen vt.

Aunque un solo usuario puede utilizar múltiples monitores conectados a los diferentes puertos de una sola tarjeta gráfica (cf. RandR), el método que se basa en múltiples instancias del servidor xorg parece requerir múltiples tarjetas gráficas PCI.

Es posible configurar varios puestos empleando solo una tarjeta gráfica, pero debido a las limitaciones del protocolo X, esto requiere el uso del protocolo de control XDMCP del administrador de pantalla X.

También existe Xdmx (Distributed Multihead X).

Adopción

Unix y Linux

El X.Org Server se ejecuta en muchos sistemas operativos de software libre Unix, incluyendo ser adoptado para su uso por la mayoría de las distribuciones Linux y variantes de BSD. También es el servidor X para el sistema operativo Solaris. X.Org también está disponible en los repositorios de Minix 3.

Windows

Cygwin/X, la implementación de Cygwin del servidor X para Microsoft Windows, utiliza el servidor X.Org, como VcXsrv (Visual C++ X-servidor) y Xming. Los clientes de SSH como PuTTY permiten el lanzamiento de aplicaciones X a través de X11 reenvío con la condición de que esté habilitado tanto en el servidor como en el cliente.

OS X / macOS

OS X versiones anteriores a Mac OS X Leopard (10.5) enviado con un servidor XFree86, pero el servidor X de 10.5 adoptó la base de código X.Org. Empezando con OS X Mountain Lion, (10.8) X11 no está incluido en OS X; en cambio, debe instalarse desde, por ejemplo, el proyecto de código abierto XQuartz. A partir de la versión 2.7.4, X11.app/XQuartz no expone soporte para las pantallas Retina de alta resolución a las aplicaciones X11, que se ejecutan en modo pixel-doubled en pantallas de alta resolución.

OpenVMS

Las versiones actuales del servidor DECwindows X11 para OpenVMS se basan en X.org Server.

Historia

La moderna Fundación X.Org nació en 2004 cuando el organismo que supervisó los estándares X y publicó la implementación de referencia oficial unió fuerzas con antiguos desarrolladores de XFree86. X11R6.7.0, la primera versión del servidor X.Org, se bifurcó de XFree86 4.4 RC2. La razón inmediata de la bifurcación fue un desacuerdo con la nueva licencia para la versión final de XFree86 4.4, pero varios desacuerdos entre los contribuyentes surgieron antes de la división. Muchos de los desarrolladores anteriores de XFree86 se han unido al proyecto X.Org Server.

En 2005, se puso un gran esfuerzo en la modularización del código fuente del servidor X.Org, lo que resultó en un lanzamiento dual a finales de año. La versión X11R7.0.0 agregó un nuevo sistema de compilación modular basado en GNU Autotools, mientras que X11R6.9.0 mantuvo el antiguo sistema de compilación imake, y ambas versiones comparten la misma base de código. Desde entonces, la rama X11R6.9 se mantiene congelada y todo el desarrollo en curso se realiza en la rama modular. El nuevo sistema de compilación también trajo el uso del enlazador dinámico estándar dlloader para cargar complementos y controladores, desaprobando el antiguo método propio. Como consecuencia de la modularización, los binarios X11 se estaban moviendo desde su propio árbol de subdirectorios /usr/X11R6 al árbol global /usr en muchos sistemas Unix.

En junio de 2006, se hizo otro esfuerzo para mover el código fuente del servidor X.Org de CVS a git. Ambos esfuerzos tenían el objetivo a largo plazo de atraer nuevos desarrolladores al proyecto. En palabras de Alan Coopersmith:

Algunos de nuestros esfuerzos aquí han sido tecnológicos - uno de los esfuerzos de conducción de las conversiones de Imake a automake y de CVS a git era hacer uso de herramientas desarrolladores ya estaría familiar y productivo de otros proyectos. El proyecto de Modularización, que rompió X.Org de un árbol gigante en más de 200 pequeños, tenía el objetivo de hacer posible arreglar un error en una sola biblioteca o controlador sin tener que descargar y construir muchos megabytes de fuentes de software que no estaban siendo cambiados.

En la versión 7.1, el marco KDrive (una pequeña implementación de X escrita por Keith Packard, que no estaba basada en XFree86 que los desarrolladores de X.Org utilizaron como campo de pruebas para nuevas ideas, como EXA) se integró en el base de código principal del servidor X.Org.

En 2008, el nuevo DRI2, basado en el controlador de configuración del modo del kernel (KMS), reemplazó al DRI. Este cambio también marcó un hito importante en la arquitectura del servidor X.Org, ya que los controladores se trasladaron del espacio del servidor y del usuario (UMS) al espacio del kernel.

En 2013, Keith Packard escribió y codificó las versiones iniciales de DRI3 y las extensiones Present para proporcionar una representación 2D más rápida y sin interrupciones. A finales de año, Adam Jackson en Red Hat reescribió la implementación de GLX.

Lanzamientos