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 X Window del lado del cliente en forma de bibliotecas X11 , que sirven como API útiles para comunicarse con el servidor X. [4] Existen dos bibliotecas X importantes para X11. La primera de estas bibliotecas fue Xlib , la API X11 en lenguaje C original, [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, como interfaces para Xlib y XCB en otros lenguajes y como bibliotecas X independientes más pequeñas. [ cita necesaria ]
Los servicios con los que X.Org Foundation apoya a 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. [ cita necesaria ] Los lanzamientos están codificados, documentados y empaquetados por desarrolladores globales . [ se necesita aclaración ]
xdpyinfo, un comando para mostrar información del servidor X.OrgEl servidor X.Org implementa el lado del servidor del protocolo central del sistema X Window versión 11 (X11) y sus extensiones, por ejemplo, RandR. [7]
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. [8]
El Device Independent 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 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.
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.
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 ( 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 denomina "configuración de modo kernel" (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-* . [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 tamaño 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 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 xf86-video-modesettingpaquete, llamado Debian xserver-xorg-video-modesetting, fue retirado y el DDX de configuración de modo 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 para hacer que la aceleración de hardware 2D de una tarjeta de video esté disponible para el servidor X. [14] [15] 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. [16] Se eliminó nuevamente de X.Org Server 1.13.
La mayoría de los conductores 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 ( 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, 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 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. [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 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. [18] [19] [20] Glamour requiere un controlador 3D compatible con sombreadores . [21]
El ajuste del rendimiento de Glamour fue aceptado para Google Summer of Code 2014. [22] Glamour es compatible con Xephyr y DRI3 , [23] y puede impulsar 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ó el desarrollo de Glamour y se publicaron parches para la versión 1.17. [25]
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
En Debian, los controladores relacionados con la entrada se encuentran en /usr/lib/xorg/modules/input/. Estos 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, libratbag se presentó como una biblioteca genérica para admitir ratones configurables. [27] [28] 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 gamepad. [29] [30]
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) .
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, y cada "asiento" tiene asignado un teclado, un ratón y un monitor. Un "asiento" está formado por 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 fuera del -box para la distribución habitual de Linux pero requiere una configuración especial.
Existen estos métodos para configurar un ensamblaje de varios asientos:
Las opciones de línea de comandos utilizadas del servidor xorg son:
-isolateDevice bus-idRestrinja los reinicios del dispositivo (salida) al dispositivo en bus-id. La cadena bus-id tiene el formato bustype:bus:device:function (por ejemplo, 'PCI:1:0:0'). Actualmente, sólo se admite el aislamiento de dispositivos PCI; es decir, esta opción se ignora si el tipo de bus no es 'PCI'.vtXXel valor predeterminado, por ejemplo, para Debian 9 Stretch es 7, es decir, al presionar Ctrl+ + el usuario puede cambiar al VT que ejecuta el servidor xorg.AltF7Solo el usuario en el primer monitor tiene el uso de consolas vt y puede usar + + x para seleccionarlas. Los otros usuarios tienen una pantalla de inicio de sesión de GDM y pueden usar el servidor xorg normalmente, pero no tienen vt.CtrlAltF
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. [37]
También está Xdmx (Distributed Multihead X).
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 . [43] X11R6.7.0, la primera versión del servidor X.Org, se bifurcó 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 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] dando como resultado 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 /usr/X11R6árbol de subdirectorios al /usrárbol global 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 . [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 aquí 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 que los desarrolladores ya estarían familiarizados y con las que serían productivos en otros proyectos. El proyecto Modularization, que dividió X.Org de un árbol gigante en más de 200 árboles pequeños, tenía como objetivo hacer posible corregir un error en una sola biblioteca o controlador sin tener que descargar y crear muchos megabytes de software y fuentes 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 la base de código principal de 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 . [47]
Servidor X de Windows basado en las fuentes xorg git (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}