X.Org Server es la implementación gratuita y de código abierto del servidor de visualización X Window System (X11) administrado por la Fundación X.Org .
Existen implementaciones del protocolo del sistema de ventanas X del lado del cliente en forma de bibliotecas X11 , que sirven como API útiles para comunicarse con el servidor X. [4] Existen dos de estas bibliotecas X importantes para X11. La primera de estas bibliotecas fue Xlib , la API X11 original del lenguaje C, [5] pero otra biblioteca X en lenguaje C, XCB , se creó más tarde en 2001. [6] Existen otras bibliotecas X más pequeñas, tanto como interfaces para Xlib y XCB en otros lenguajes, como bibliotecas X independientes más pequeñas. [ cita requerida ]
Los servicios con los que la Fundación X.Org apoya a X Server incluyen el empaquetado de las versiones, la certificación (a cambio de una tarifa), la evaluación de las mejoras del código, el desarrollo del sitio web y el manejo de la distribución de donaciones monetarias. [ cita requerida ] Las versiones están codificadas, documentadas y empaquetadas por desarrolladores globales . [ aclaración necesaria ]
xdpyinfo, un comando para mostrar información del servidor X.OrgEl servidor X.Org implementa el lado servidor del protocolo central del sistema X Window versión 11 (X11) y extensiones del mismo, por ejemplo RandR. [7]
La versión 1.16.0 integra soporte para el lanzamiento y la gestión basados en systemd, lo que mejora el rendimiento y la confiabilidad del arranque. [8]
El dispositivo independiente X (DIX) es la parte del servidor X.Org que interactúa con los clientes e implementa la representación del software. El bucle principal y la entrega de eventos son parte del DIX. [9]
Un servidor X tiene una enorme cantidad de funcionalidad que debe implementarse para soportar el protocolo central X. Esto incluye tablas de códigos, rasterización y almacenamiento en caché de glifos, XLFD y la API de renderizado central que dibuja primitivas gráficas.
El dispositivo dependiente X (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 incluye tarjetas gráficas, así como mouse y teclados. Cada controlador es específico del hardware y se implementa como un módulo cargable independiente.
Por razones históricas, el servidor X.Org aún contiene controladores de dispositivos gráficos que admiten algún tipo de aceleración de renderizado 2D. En el pasado, la configuración de modo se realizaba mediante un controlador de dispositivo gráfico de servidor X específico para algún hardware de controlador de video ( por ejemplo , 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 llama "configuración de modo de kernel" (KMS). Pero la aceleración de renderizado 2D se mantuvo.
En Debian, los controladores de gráficos 2D para el servidor X.Org se empaquetan individualmente y se denominan xserver-xorg-video-* . [10] 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 se instala nouveau_drv.socon un tamaño de 215 KiB, el controlador propietario Nvidia GeForce instala un archivo de 8 MiB llamado nvidia_drv.soy Radeon Software se instala fglrx_drv.socon un tamaño de aproximadamente 25 MiB.
Los controladores de dispositivos gráficos gratuitos y de código abierto disponibles se están desarrollando dentro del proyecto Mesa 3D . Si bien se pueden volver a compilar según sea necesario, el desarrollo de los controladores 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 incorporó un método genérico para la configuración de modos. El xf86-video-modesettingpaquete, el paquete Debian que se llamaría xserver-xorg-video-modesetting, se retiró y el DDX de configuración de modos genérico que contenía se trasladó al paquete del 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, el empleado de AMD Michel Dänzer lanzó xf86-video-atila versión 7.7.0 [11] y xf86-video-amdgpula versión 1.1.0 [12], esta última incluye soporte para su microarquitectura Polaris .
Existen (al menos) XAA (XFree86 Acceleration Architecture), [13] EXA , UXA y SNA .
En el sistema X Window , la arquitectura de aceleración XFree86 ( XAA ) es una arquitectura de controlador que permite que la aceleración de hardware 2D de una tarjeta de vídeo esté disponible para el servidor X. [14] [15] Fue escrita por Harm Hanemaayer en 1996 y publicada por primera vez en la versión 3.3 de XFree86 . Fue completamente reescrita para XFree86 4.0. [16] Fue eliminada nuevamente de X.Org Server 1.13.
La mayoría de los controladores implementan la aceleración mediante 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 ( XF86Configo 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, se lanzó EXA como reemplazo de XAA, ya que XAA prácticamente no ofrece ventajas de velocidad para las tarjetas de video actuales. EXA se considera un paso intermedio para convertir todo el servidor X al uso de OpenGL .
Glamor es un controlador de aceleración 2D genérico, independiente del hardware, para el servidor X que traduce las primitivas de renderizado X en operaciones OpenGL , aprovechando cualquier controlador OpenGL 3D existente. [17] De esta manera, es funcionalmente similar a Quartz Extreme y QuartzGL (aceleración de rendimiento 2D) para Apple Quartz Compositor .
El objetivo final de GLAMOR es dejar obsoletos y reemplazar todos los controladores de dispositivos gráficos DDX 2D y arquitecturas de aceleración, evitando así la necesidad de escribir controladores X 2D específicos para cada chipset gráfico compatible. [18] [19] [20] Glamor requiere un controlador 3D con soporte para sombreadores . [21]
El ajuste del rendimiento de Glamor fue aceptado para Google Summer of Code 2014. [22] Glamor es compatible con Xephyr y DRI3 , [23] y puede aumentar algunas operaciones entre un 700 y un 800 %. [24] Desde su incorporación a la versión 1.16 del servidor X.Org, se continuó con el desarrollo de Glamor y se publicaron parches para la versión 1.17. [25]
Existe un DDX específico y específico para las 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 video 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
En Debian, los controladores relacionados con la entrada se encuentran en /usr/lib/xorg/modules/input/. Dichos controladores se denominan, por ejemplo evdev_drv.so, mouse_drv.so, synaptics_drv.soo 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. [26] En el XDC 2015 en Toronto, se presentó libratbag como una biblioteca genérica para soportar ratones configurables. [27] [28] xserver-xorg-input-joystick es el módulo de entrada para el servidor X.Org para manejar joysticks y gamepads clásicos, que no está pensado para jugar juegos bajo X, sino para controlar el cursor con un joystick o gamepad. [29] [30]
El servidor X.Org y cualquier cliente x se ejecutan como procesos distintos. En Unix/Linux, un proceso no sabe nada acerca de otros procesos. Para comunicarse con otro proceso, depende completamente del núcleo 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 Unix son más eficientes, ya que no tienen la sobrecarga del protocolo ( sumas de comprobació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. Proporcionan la interfaz de programación de aplicaciones (API) para la comunicación en el dominio TCP/IP y también localmente solo en el dominio UNIX. Hay varias otras API descritas en la interfaz de transporte X, por ejemplo TLI (interfaz de capa de transporte). Otras opciones para la IPC entre el cliente y el servidor X requieren extensiones del sistema X Window, por ejemplo, la extensión de memoria compartida MIT (MIT-SHM) .
El término "multi-seat" hace referencia a un conjunto de una única computadora con varios "asientos", lo que permite que varios usuarios se sienten frente a la computadora, inicien sesión y utilicen la computadora al mismo tiempo de forma independiente. La computadora tiene varios teclados, ratones y monitores conectados a ella, y cada "asiento" tiene un teclado, un ratón y un monitor asignados. 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 conectado) y un teclado y un ratón. También puede incluir cámaras de vídeo, tarjetas de sonido y más.
Debido a la limitación del sistema VT en el kernel de Linux y del protocolo del núcleo X (en particular, cómo X define la relación entre la ventana raíz y una salida de la tarjeta gráfica), la función multi-seat no funciona de manera inmediata para la distribución de Linux habitual, sino que requiere una configuración especial.
Existen estos métodos para configurar un conjunto de varios asientos:
Las opciones de línea de comandos utilizadas del servidor xorg son:
-isolateDevice bus-idRestringe los reinicios de dispositivos (salida) al dispositivo en el bus-id. La cadena de bus-id tiene el formato bustype:bus:device:function (por ejemplo, 'PCI:1:0:0'). En la actualidad, solo se admite el aislamiento de dispositivos PCI; es decir, esta opción se ignora si el bustype es distinto de 'PCI'.vtXXEl valor predeterminado para, por ejemplo, Debian 9 Stretch es 7, es decir, al presionar Ctrl+ + el usuario puede cambiar al VT que ejecuta el servidor xorg.AltF7Solo el usuario del primer monitor tiene acceso a las consolas vt y puede usar + + x para seleccionarlas. Los demás usuarios tienen una pantalla de inicio de sesión de GDM y pueden usar xorg-server normalmente, pero no tienen consolas vt.CtrlAltF
Aunque un solo usuario puede utilizar varios 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 terminales empleando solo una tarjeta gráfica, pero debido a las limitaciones del protocolo X esto requiere el uso del Protocolo de control del administrador de pantalla X (XDMCP). [37]
También existe Xdmx (Distributed Multihead X).
La Fundación X.Org moderna nació en 2004 cuando el organismo que supervisaba los estándares X y publicaba la implementación de referencia oficial unió fuerzas con antiguos desarrolladores de XFree86 . [43] X11R6.7.0, la primera versión de X.Org Server, fue una bifurcación de XFree86 4.4 RC2. [1] La razón inmediata de la bifurcación fue un desacuerdo con la nueva licencia para la versión final de lanzamiento 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, [44] lo que dio como resultado una versión 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 compartieron 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 consigo el uso del enlazador dinámico estándar dlloader para cargar complementos y controladores, lo que desaprobó el antiguo método propio. Como consecuencia de la modularización, los binarios X11 se estaban moviendo de su propio /usr/X11R6árbol de subdirectorios al /usrárbol global en muchos sistemas Unix .
En junio de 2006, se realizó otro esfuerzo para trasladar el código fuente del servidor X.Org de CVS a git . [45] Ambos esfuerzos tenían el objetivo a largo plazo de atraer nuevos desarrolladores al proyecto. En palabras de Alan Coopersmith: [46]
Algunos de nuestros esfuerzos en este sentido han sido tecnológicos: uno de los esfuerzos impulsores de las conversiones de Imake a automake y de CVS a git fue hacer uso de herramientas con las que los desarrolladores ya estarían familiarizados y serían productivos gracias a otros proyectos. El proyecto de modularización, que dividió X.Org de un árbol gigante en más de 200 árboles pequeños, tenía el objetivo de hacer posible la reparación de un error en una única biblioteca o controlador sin tener que descargar y crear muchos megabytes de software y fuentes que no se estaban modificando.
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 usaron como campo de pruebas para nuevas ideas, como EXA ) se integró en la base de código principal del servidor X.Org.
En 2008, el nuevo DRI2, basado en el controlador de configuración de modo de kernel (KMS), reemplazó a DRI. Este cambio también marcó un hito importante en la arquitectura del servidor X.Org, ya que los controladores se trasladaron del espacio de servidor y usuario (UMS) al espacio de kernel .
En 2013, Keith Packard escribió y codificó las versiones iniciales de las extensiones DRI3 y Present para proporcionar una representación 2D más rápida y sin cortes . A finales de año, Adam Jackson de Red Hat reescribió la implementación de GLX . [47]
Servidor Windows X basado en las fuentes git de xorg (como xming o xwin de cygwin), pero compilado con Visual C++ 2010.
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}