Protocolo central del sistema X Window

El protocolo central del Sistema X Window ^{[ 1 ] [ 2 ] [ 3 ]} es el protocolo base del Sistema X Window , un sistema de ventanas en red para pantallas de mapa de bits utilizado para construir interfaces gráficas de usuario en Unix , sistemas tipo Unix y otros sistemas operativos . El Sistema X Window se basa en un modelo cliente-servidor : un único servidor controla el hardware de entrada/salida , como la pantalla , el teclado y el ratón ; todos los programas de aplicación actúan como clientes , interactuando con el usuario y con los demás clientes a través del servidor. Esta interacción está regulada por el protocolo central del Sistema X Window. Existen otros protocolos relacionados con el Sistema X Window, tanto construidos sobre el protocolo central del Sistema X Window como protocolos independientes.

En el protocolo central del Sistema X Window, solo se envían cuatro tipos de paquetes, de forma asíncrona , a través de la red: solicitudes, respuestas, eventos y errores. Las solicitudes son enviadas por un cliente al servidor para pedirle que realice alguna operación (por ejemplo, crear una nueva ventana) y que le envíe los datos que contiene. Las respuestas son enviadas por el servidor para proporcionar dichos datos. Los eventos son enviados por el servidor para notificar a los clientes sobre la actividad del usuario u otros sucesos de su interés. Los errores son paquetes enviados por el servidor para notificar a un cliente sobre errores ocurridos durante el procesamiento de sus solicitudes. Las solicitudes pueden generar respuestas, eventos y errores; aparte de esto, el protocolo no impone un orden específico en el que se envían los paquetes a través de la red. Existen algunas extensiones del protocolo central, cada una con sus propias solicitudes, respuestas, eventos y errores.

X se originó en el MIT en 1984 (su actualLa versión X11 apareció en septiembre de 1987. Sus diseñadores, Bob Scheifler y Jim Gettys, establecieron como principio fundamental que su protocolo central debía "crear mecanismos, no políticas". Como resultado, el protocolo central no especifica la interacción entre clientes ni entre un cliente y el usuario. Estas interacciones son objeto de especificaciones separadas, ^{[ 4 ]} como las especificaciones ICCCM y freedesktop.org , y normalmente se aplican automáticamente mediante el uso de un conjunto de widgets determinado .

La comunicación entre el servidor y los clientes se realiza mediante el intercambio de paquetes a través de un canal . El cliente establece la conexión (el protocolo no especifica cómo se inicia). El cliente también envía el primer paquete, que contiene el orden de bytes a utilizar e información sobre la versión del protocolo y el tipo de autenticación que espera que utilice el servidor. El servidor responde enviando un paquete que indica la aceptación o el rechazo de la conexión, o bien solicitando una autenticación adicional . Si se acepta la conexión, el paquete de aceptación contiene datos que el cliente utilizará en la interacción posterior con el servidor.

Una vez establecida la conexión, se intercambian cuatro tipos de paquetes entre el cliente y el servidor a través del canal:

1. Solicitud: El cliente solicita información al servidor o le pide que realice una acción.
2. Respuesta: El servidor responde a una solicitud. No todas las solicitudes generan respuesta.
3. Evento: El servidor informa al cliente de un evento, como la entrada de teclado o ratón, el movimiento, el redimensionamiento o la exposición de una ventana, etc.
4. Error: El servidor envía un paquete de error si una solicitud no es válida. Dado que las solicitudes se ponen en cola, es posible que los paquetes de error generados por una solicitud no se envíen de inmediato.

Los paquetes de solicitud y respuesta tienen longitud variable, mientras que los paquetes de eventos y errores tienen una longitud fija de 32 bytes .

El servidor numera secuencialmente los paquetes de solicitud en cuanto los recibe: la primera solicitud de un cliente se numera como 1, la segunda como 2, etc. Los 16 bits menos significativos del número secuencial de una solicitud se incluyen en los paquetes de respuesta y de error generados por la solicitud, si los hay. También se incluyen en los paquetes de eventos para indicar el número secuencial de la solicitud que el servidor está procesando o que acaba de procesar.

Lo que normalmente se denomina ventana en la mayoría de las interfaces gráficas de usuario se llama ventana de nivel superior en el Sistema X Window. El término ventana también se utiliza para referirse a las ventanas que se encuentran dentro de otra ventana, es decir, las subventanas de una ventana principal . Elementos gráficos como botones , menús , iconos , etc., pueden implementarse mediante subventanas.

Un cliente puede solicitar la creación de una ventana. Más precisamente, puede solicitar la creación de una subventana de una ventana existente. Como resultado, las ventanas creadas por los clientes se organizan en una estructura jerárquica. La raíz de esta estructura es la ventana raíz , una ventana especial creada automáticamente por el servidor al iniciarse. Todas las demás ventanas son subventanas, directa o indirectamente, de la ventana raíz. Las ventanas de nivel superior son subventanas directas de la ventana raíz. Visualmente, la ventana raíz tiene el tamaño del escritorio virtual y se encuentra detrás de todas las demás ventanas.

No siempre se garantiza la conservación del contenido de una ventana. En particular, el contenido puede destruirse al moverla, redimensionarla, cubrirla con otras ventanas o, en general, al ocultarla total o parcialmente. El contenido se pierde si el servidor X no mantiene una copia de seguridad del contenido de la ventana. El cliente puede solicitar que se mantenga dicha copia de seguridad, pero el servidor no tiene la obligación de hacerlo. Por lo tanto, los clientes no pueden dar por sentado que se mantiene la copia de seguridad. Si una parte visible de una ventana tiene contenido no especificado, se envía un evento para notificar al cliente que el contenido debe volver a dibujarse.

Cada ventana tiene un conjunto de atributos asociados , como la geometría de la ventana (tamaño y posición), la imagen de fondo, si se ha solicitado un almacenamiento de respaldo para ella, etc. El protocolo incluye solicitudes para que un cliente inspeccione y cambie los atributos de una ventana.

Las ventanas pueden ser InputOutputo InputOnly. InputOutputLas ventanas pueden mostrarse en la pantalla y se utilizan para dibujar. InputOnlyLas ventanas nunca se muestran en la pantalla y se utilizan solo para recibir entrada.

El marco decorativo y la barra de título (que posiblemente incluyan botones) que suelen verse alrededor de las ventanas son creados por el gestor de ventanas , no por el cliente que crea la ventana. El gestor de ventanas también gestiona la entrada relacionada con estos elementos, como el redimensionamiento de la ventana cuando el usuario hace clic y arrastra el marco. Los clientes suelen operar sobre la ventana que crearon sin tener en cuenta los cambios realizados por el gestor de ventanas. Un cambio que debe considerar es que los gestores de ventanas que cambian de padre, como casi todos los gestores de ventanas modernos, modifican el padre de las ventanas de nivel superior a una ventana que no es la raíz. Desde el punto de vista del protocolo principal, el gestor de ventanas es un cliente, igual que las demás aplicaciones.

Se pueden obtener datos sobre una ventana ejecutando el xwininfoprograma. Al pasarle el -treeargumento de línea de comandos , este programa muestra el árbol de subventanas de una ventana, junto con sus identificadores y datos geométricos.

Un mapa de píxeles es una región de memoria que se puede usar para dibujar. A diferencia de las ventanas, los mapas de píxeles no se muestran automáticamente en la pantalla. Sin embargo, el contenido de un mapa de píxeles (o parte de él) se puede transferir a una ventana y viceversa. Esto permite técnicas como el doble búfer . La mayoría de las operaciones gráficas que se pueden realizar en ventanas también se pueden realizar en mapas de píxeles.

Las ventanas y los mapas de píxeles se denominan colectivamente elementos gráficos (drawable) , y sus datos de contenido residen en el servidor. Sin embargo, un cliente puede solicitar que el contenido de un elemento gráfico se transfiera del servidor al cliente o viceversa.

El cliente puede solicitar diversas operaciones gráficas, como borrar un área, copiar un área en otra, dibujar puntos, líneas, rectángulos y texto. Excepto borrar, todas las operaciones son posibles en todos los elementos gráficos, tanto ventanas como mapas de píxeles.

La mayoría de las solicitudes de operaciones gráficas incluyen un contexto gráfico , que es una estructura que contiene los parámetros de dichas operaciones. Un contexto gráfico incluye el color de primer plano, el color de fondo, la fuente del texto y otros parámetros gráficos. Al solicitar una operación gráfica, el cliente incluye un contexto gráfico. No todos los parámetros del contexto gráfico afectan a la operación; por ejemplo, la fuente no afecta al trazado de una línea.

El protocolo principal especifica el uso de fuentes del lado del servidor. Estas fuentes se almacenan como archivos , y el servidor accede a ellas directamente a través del sistema de archivos local o a través de la red mediante otro programa llamado servidor de fuentes . Los clientes pueden solicitar la lista de fuentes disponibles para el servidor y solicitar que el servidor cargue (si aún no lo ha hecho) o descargue (si no está siendo utilizado por otros clientes) una fuente. Un cliente puede solicitar información general sobre una fuente (por ejemplo, el estilo de la fuente) y el espacio que ocupa una cadena específica al dibujarse con una fuente determinada.

Los nombres de las fuentes son cadenas arbitrarias a nivel del protocolo central X. Las convenciones de descripción de fuentes lógicas X ^{[ 5 ]} especifican cómo deben nombrarse las fuentes según sus atributos. Estas convenciones también especifican los valores de las propiedades opcionales que se pueden adjuntar a las fuentes.

El xlsfontsprograma imprime la lista de fuentes almacenadas en el servidor. xfontselMuestra los glifos de las fuentes y permite al usuario seleccionar el nombre de una fuente para pegarla en otra ventana.

Actualmente, el uso de fuentes del lado del servidor se considera obsoleto en favor de las fuentes del lado del cliente. ^{[ 6 ]} Dichas fuentes son renderizadas por el cliente, no por el servidor, con el apoyo de las bibliotecas Xft o cairo y la extensión XRender . El protocolo principal no incluye ninguna especificación sobre fuentes del lado del cliente.

Todos los datos sobre ventanas, mapas de píxeles, fuentes, etc., se almacenan en el servidor. El cliente conoce los identificadores de estos objetos: números enteros que utiliza como nombres al interactuar con el servidor. Por ejemplo, si un cliente desea crear una ventana, solicita al servidor que la cree con un identificador determinado. Posteriormente, el cliente puede utilizar este identificador para solicitar, por ejemplo, que se dibuje una cadena de texto en la ventana. Los siguientes objetos residen en el servidor y el cliente los reconoce mediante un identificador numérico:

• Window
• Pixmap
• Font
• Colormap(una tabla de colores, descrita a continuación)
• Graphic context

Estos objetos se denominan recursos . Cuando un cliente solicita la creación de uno de estos recursos, también especifica un identificador para él. Por ejemplo, para crear una nueva ventana, el cliente especifica tanto los atributos de la ventana (padre, ancho, alto, etc.) como el identificador que se asociará a la ventana.

Los identificadores son enteros de 32 bits con sus tres bits más significativos iguales a cero. Cada cliente tiene su propio conjunto de identificadores que puede usar para crear nuevos recursos. Este conjunto lo especifica el servidor como dos enteros incluidos en el paquete de aceptación (el paquete que envía al cliente para informarle que la conexión ha sido aceptada). Los clientes eligen identificadores de este conjunto de forma que no haya conflictos: dos objetos entre ventanas, mapas de píxeles, fuentes, mapas de color y contextos gráficos no pueden tener el mismo identificador.

Una vez creado un recurso, el cliente utiliza su identificador para solicitar al servidor operaciones relacionadas con él. Algunas operaciones afectan al recurso en sí (por ejemplo, solicitudes para mover ventanas); otras solicitan datos del recurso almacenados en el servidor (por ejemplo, solicitudes de los atributos de las ventanas).

Los identificadores son únicos para el servidor, no solo para el cliente; por ejemplo, no hay dos ventanas con el mismo identificador, aunque hayan sido creadas por dos clientes diferentes. Un cliente puede acceder a cualquier objeto dado su identificador. En particular, también puede acceder a los recursos creados por cualquier otro cliente, incluso si sus identificadores no pertenecen al conjunto de identificadores que puede crear.

Como resultado, dos clientes conectados al mismo servidor pueden usar el mismo identificador para referirse al mismo recurso. Por ejemplo, si un cliente crea una ventana con un identificador 0x1e00021y pasa este número 0x1e00021a otra aplicación (por cualquier medio disponible, por ejemplo, almacenando este número en un archivo al que también tenga acceso la otra aplicación), esta otra aplicación puede operar en la misma ventana. Esta posibilidad es aprovechada, por ejemplo, por la versión X de Ghostview : este programa crea una subventana, almacena su identificador en una variable de entorno y llama a Ghostscript ; este programa dibuja el contenido del archivo PostScript para mostrarlo en esta ventana. ^{[ 7 ]}

Los recursos se destruyen normalmente cuando el cliente que los creó cierra la conexión con el servidor. Sin embargo, antes de cerrar la conexión, un cliente puede solicitar al servidor que no los destruya.

Los eventos son paquetes que el servidor envía a un cliente para comunicarle que ha ocurrido algo que podría interesarle. Por ejemplo, se envía un evento cuando el usuario pulsa una tecla o hace clic con el ratón. Los eventos no solo se utilizan para la entrada de datos: por ejemplo, se envían para indicar la creación de nuevas subventanas dentro de una ventana determinada.

Cada evento es relativo a una ventana. Por ejemplo, si el usuario hace clic cuando el puntero está dentro de una ventana, el evento será relativo a esa ventana. El paquete de eventos contiene el identificador de esa ventana.

Un cliente puede solicitar al servidor que envíe un evento a otro cliente; esto se utiliza para la comunicación entre clientes. Por ejemplo, se genera un evento de este tipo cuando un cliente solicita el texto que está seleccionado actualmente: este evento se envía al cliente que está gestionando la ventana que contiene la selección.

El Exposeevento se envía cuando se destruye un área de una ventana y se hace visible su contenido. El contenido de una ventana puede destruirse en ciertas condiciones, por ejemplo, si la ventana está cubierta y el servidor no mantiene un almacenamiento de respaldo. El servidor genera un Exposeevento para notificar al cliente que se debe dibujar una parte de la ventana.

La mayoría de los eventos se envían solo si el cliente ha manifestado previamente su interés. Esto se debe a que los clientes pueden estar interesados ​​únicamente en ciertos tipos de eventos. Por ejemplo, un cliente puede estar interesado en eventos relacionados con el teclado, pero no con el ratón. Sin embargo, algunos tipos de eventos se envían a los clientes incluso si no los han solicitado específicamente.

Los clientes especifican qué tipo de eventos desean recibir configurando un atributo de la ventana. Por ejemplo, para redibujar una ventana cuando su contenido se ha destruido, el cliente debe recibir los Exposeeventos que le informan de que la ventana necesita ser redibujada. Sin embargo, el cliente solo recibirá Exposeestos eventos si previamente ha manifestado su interés en ellos, lo cual se realiza configurando adecuadamente el atributo de máscara de eventos de la ventana.

Diferentes clientes pueden solicitar eventos en la misma ventana. Incluso pueden configurar diferentes máscaras de eventos en la misma ventana. Por ejemplo, un cliente puede solicitar solo eventos de teclado en una ventana, mientras que otro solo solicita eventos de ratón en la misma ventana. Esto es posible porque el servidor mantiene una máscara de eventos independiente para cada cliente en cada ventana. Sin embargo, existen algunos tipos de eventos que solo un cliente puede seleccionar a la vez para cada ventana. En particular, estos eventos informan sobre clics de botones del ratón y algunos cambios relacionados con la gestión de ventanas.

El xevprograma muestra los eventos relativos a una ventana. En concreto, xev -id WIDsolicita todos los eventos posibles relativos a la ventana con el identificador especificado WIDy los imprime.

A continuación se muestra un posible ejemplo de interacción entre un servidor y un programa que crea una ventana con un recuadro negro y se cierra al pulsar una tecla. En este ejemplo, el servidor no envía ninguna respuesta porque las solicitudes del cliente no generan respuestas. Estas solicitudes podrían generar errores.

1. El cliente abre la conexión con el servidor y envía el paquete inicial especificando el orden de bytes que está utilizando.
2. El servidor acepta la conexión (en este ejemplo no se requiere autorización) enviando un paquete apropiado, que contiene otra información como el identificador de la ventana raíz (por ejemplo, 0x0000002b) y qué identificadores puede crear el cliente.
3. El cliente solicita la creación de un contexto gráfico predeterminado con identificador 0x00200000(esta solicitud, al igual que las demás solicitudes de este ejemplo, no genera respuestas del servidor).
4. El cliente solicita al servidor que cree una ventana de nivel superior (es decir, especifica que el padre sea la ventana raíz 0x0000002b) con identificador 0x00200001, tamaño 200x200, posición (10,10), etc.
5. El cliente solicita un cambio en los atributos de la ventana 0x00200001, especificando que está interesado en recibir Exposeeventos KeyPress.
6. 0x00200001El cliente solicita que se muestre la ventana en la pantalla.
7. Cuando la ventana se hace visible y su contenido debe dibujarse, el servidor envía un Exposeevento al cliente.
8. En respuesta a este evento, el cliente solicita que se dibuje un cuadro enviando una PolyFillRectanglesolicitud con 0x00200001contexto de ventana y gráfico.0x00200000

Si la ventana está cubierta por otra ventana y luego se descubre de nuevo, suponiendo que no se mantiene el almacenamiento subyacente:

1. El servidor envía otro Exposeevento para indicarle al cliente que la ventana debe dibujarse de nuevo.
2. El cliente vuelve a dibujar la ventana enviando una PolyFillRectanglesolicitud.

Si se pulsa una tecla:

1. El servidor envía un KeyPressevento al cliente para notificarle que el usuario ha pulsado una tecla.
2. El cliente reacciona de forma apropiada (en este caso, rescinde el contrato).

A nivel de protocolo, un color se representa mediante un entero sin signo de 32 bits, llamado valor de píxel . Los siguientes elementos afectan la representación de los colores:

1. la profundidad del color
2. el mapa de colores , que es una tabla que contiene valores de intensidad de rojo, verde y azul.
3. el tipo visual , que especifica cómo se utiliza la tabla para representar los colores

En el caso más sencillo, el mapa de colores es una tabla que contiene una tripleta RGBx en cada fila. Un valor de píxel representa el color contenido en la xfila -ésima de la tabla. Si el cliente puede modificar las entradas del mapa de colores, esta representación se identifica mediante la PseudoColorclase visual . La clase visual StaticColores similar, pero el cliente no puede modificar las entradas del mapa de colores.

Hay un total de seis clases visuales posibles, cada una identifica una forma diferente de representar una tripleta RGB con un valor de píxel. PseudoColory StaticColorson dos. Otras dos son GrayScaley StaticGray, que se diferencian en que solo muestran tonos de gris.

Las dos clases visuales restantes difieren de las anteriores porque dividen los valores de los píxeles en tres partes y utilizan tres tablas separadas para la intensidad del rojo, el verde y el azul. Según esta representación del color, un valor de píxel se convierte en una tripleta RGB de la siguiente manera:

1. El valor del píxel se considera una secuencia de bits.
2. Esta secuencia se divide en tres partes.
3. Cada uno de estos tres grupos de bits se considera un número entero y se utiliza como índice para encontrar un valor en cada una de las tres tablas separadas.

Este mecanismo requiere que el mapa de colores esté compuesto por tres tablas separadas, una para cada color primario . El resultado de la conversión sigue siendo una tripleta de valores de intensidad. Las clases visuales que utilizan esta representación son DirectColory TrueColor, que difieren en si el cliente puede cambiar los mapas de colores o no.

Estos seis mecanismos para representar colores con valores de píxeles requieren parámetros adicionales para funcionar. Dichos parámetros se agrupan en un tipo visual , que contiene una clase visual y otros parámetros de la representación de colores. Cada servidor dispone de un conjunto fijo de tipos visuales, cada uno asociado a un identificador numérico. Estos identificadores son enteros sin signo de 32 bits, pero no necesariamente difieren de los identificadores de recursos o átomos.

Cuando se acepta la conexión de un cliente, el paquete de aceptación enviado por el servidor contiene una secuencia de bloques, cada uno con información sobre una pantalla específica. Para cada pantalla, el bloque correspondiente contiene una lista de otros bloques, cada uno relacionado con una profundidad de color específica compatible con la pantalla. Para cada profundidad compatible, esta lista contiene una lista de tipos visuales. Como resultado, a cada pantalla se le asocian varias profundidades posibles, y a cada profundidad de cada pantalla se le asocian varios tipos visuales posibles. Un tipo visual determinado puede utilizarse para varias pantallas y para diferentes profundidades.

Para cada tipo visual, el paquete de aceptación contiene tanto su identificador como los parámetros correspondientes (clase visual, etc.). El cliente almacena esta información, ya que no puede solicitarla posteriormente. Además, los clientes no pueden modificar ni crear nuevos tipos visuales. Las solicitudes para crear una nueva ventana incluyen la profundidad y el identificador del tipo visual que se utilizará para representar los colores de dicha ventana.

Los mapas de color se utilizan independientemente de si el hardware que controla la pantalla (por ejemplo, una tarjeta gráfica ) utiliza una paleta , que es una tabla que también se usa para representar colores. Los servidores utilizan mapas de color incluso si el hardware no utiliza una paleta. Cuando el hardware utiliza paletas, solo se puede instalar un número limitado de mapas de color. En concreto, se instala un mapa de color cuando el hardware muestra los colores según él. Un cliente puede solicitar al servidor que instale un mapa de color. Sin embargo, esto puede requerir la desinstalación de otro mapa de color: el efecto es que las ventanas que utilizan el mapa de color desinstalado no se muestran con el color correcto, un efecto conocido como parpadeo de color o tecnicolor . Este problema se puede solucionar utilizando mapas de color estándar , que son mapas de color con una asociación predecible entre los valores de los píxeles y los colores. Gracias a esta propiedad, los mapas de color estándar pueden ser utilizados por diferentes aplicaciones.

La creación de mapas de color se rige por la convención ICCCM . Los mapas de color estándar se rigen por la convención ICCCM y por la especificación Xlib .

El sistema de gestión del color X (Xcms) forma parte del sistema de color X. Este sistema se introdujo con la versión 5 de X11R6 en 1991. Incluye varias funciones adicionales en xlib, que se encuentran en la serie de funciones Xcms*. Define esquemas de color independientes del dispositivo, que pueden convertirse en sistemas RGB dependientes del dispositivo. El sistema consta de las funciones Xcms* de xlib y de la Convención de Caracterización del Color del Dispositivo X (XDCCC), que describe cómo convertir los distintos sistemas de color independientes del dispositivo en sistemas de color RGB dependientes del dispositivo. Este sistema admite los sistemas de color CIEXYZ , xyY , CIELUV , CIELAB y TekHVC . Archivado el 5 de octubre de 2011 en Wayback Machine .

Los átomos son enteros de 32 bits que representan cadenas . Los diseñadores del protocolo introdujeron los átomos porque representan cadenas en un tamaño corto y fijo: ^{[ 8 ]} mientras que una cadena puede ser arbitrariamente larga, un átomo siempre es un entero de 32 bits. La brevedad de los átomos se aprovechó al exigir su uso en los tipos de paquetes que probablemente se envíen muchas veces con las mismas cadenas; esto resulta en un uso más eficiente de la red. El tamaño fijo de los átomos se aprovechó al especificar un tamaño fijo para los eventos, a saber, 32 bytes: los paquetes de tamaño fijo pueden contener átomos, pero no pueden contener cadenas largas.

Precisamente, los átomos son identificadores de cadenas almacenadas en el servidor. Son similares a los identificadores de recursos (ventanas, mapas de píxeles, etc.), pero se diferencian de ellos en dos aspectos. En primer lugar, los identificadores de los átomos los elige el servidor, no el cliente. Es decir, cuando un cliente solicita la creación de un nuevo átomo, solo envía al servidor la cadena que se almacenará, no su identificador; este identificador lo elige el servidor y lo envía de vuelta como respuesta al cliente. La segunda diferencia importante entre recursos y átomos es que los átomos no están asociados a clientes. Una vez creado, un átomo permanece activo hasta que el servidor se cierra o se reinicia (este no es el comportamiento predeterminado de los recursos).

Los átomos son identificadores y, por lo tanto, únicos. Sin embargo, un átomo y un identificador de recurso pueden coincidir. La cadena asociada a un átomo se denomina nombre del átomo . El nombre de un átomo no se puede cambiar después de su creación, y no puede haber dos átomos con el mismo nombre. Por consiguiente, el nombre de un átomo se utiliza comúnmente para indicarlo: «el átomo ABCD» significa, más precisamente, «el átomo cuya cadena asociada es ABCD» o «el átomo cuyo nombre es ABCD». Un cliente puede solicitar la creación de un nuevo átomo y solicitar el átomo (el identificador) de una cadena determinada. Algunos átomos están predefinidos (creados por el servidor con un identificador y una cadena dados).

Los átomos se utilizan para diversos fines, principalmente relacionados con la comunicación entre diferentes clientes conectados al mismo servidor. En particular, se utilizan en combinación con las propiedades de las ventanas, que se describen a continuación.

La lista de todos los átomos que residen en un servidor se puede imprimir usando el programa xlsatoms. En particular, este programa imprime cada átomo (el identificador, es decir, un número) con su nombre (su cadena asociada).

Cada ventana tiene un conjunto predefinido de atributos y propiedades, almacenados en el servidor y accesibles para los clientes mediante las solicitudes correspondientes. Los atributos son datos sobre la ventana, como su tamaño, posición, color de fondo, etc. Las propiedades son datos arbitrarios asociados a una ventana. A diferencia de los atributos, las propiedades no tienen significado a nivel del protocolo central X. Un cliente puede almacenar datos arbitrarios en una propiedad de una ventana.

Una propiedad se caracteriza por un nombre, un tipo y un valor. Las propiedades son similares a las variables en los lenguajes de programación imperativos , ya que un cliente puede crear una nueva propiedad con un nombre y un tipo determinados y almacenar un valor en ella. Las propiedades están asociadas a ventanas: dos propiedades con el mismo nombre pueden existir en dos ventanas diferentes, aunque tengan tipos y valores distintos.

El nombre, el tipo y el valor de una propiedad son cadenas de texto; más precisamente, son átomos, es decir, cadenas almacenadas en el servidor y accesibles para los clientes mediante identificadores. Una aplicación cliente puede acceder a una propiedad determinada utilizando el identificador del átomo que contiene el nombre de la propiedad.

Las propiedades se utilizan principalmente para la comunicación entre clientes. Por ejemplo, la propiedad denominada WM_NAME(la propiedad a la que pertenece el átomo cuya cadena asociada es "WM_NAME") se utiliza para almacenar el nombre de las ventanas. Los gestores de ventanas suelen leer esta propiedad para mostrar el nombre de las ventanas en su barra de título.

Algunos tipos de comunicación entre clientes utilizan propiedades de la ventana raíz. Por ejemplo, según la especificación del gestor de ventanas freedesktop , ^{[ 9 ]} los gestores de ventanas deben almacenar el identificador de la ventana activa en la propiedad denominada _NET_ACTIVE_WINDOWde la ventana raíz. Los recursos X , que contienen parámetros de los programas, también se almacenan en propiedades de la ventana raíz; de esta forma, todos los clientes pueden acceder a ellos, incluso si se ejecutan en equipos diferentes.

El xpropprograma imprime las propiedades de una ventana determinada; xprop -rootimprime el nombre, el tipo y el valor de cada propiedad de la ventana raíz.

En el sistema X Window, cada tecla física tiene asociado un número entre 8 y 255, denominado código de tecla . Este código solo identifica la tecla, no un carácter o término específico (por ejemplo, "Re Pág") entre los que puedan estar impresos en ella. Cada uno de estos caracteres o términos se identifica mediante un símbolo de tecla . Mientras que un código de tecla depende únicamente de la tecla pulsada, un símbolo de tecla puede depender, por ejemplo, de si también se pulsó la tecla Mayús u otra tecla modificadora .

Cuando se presiona o se suelta una tecla, el servidor envía eventos de tipo KeyPresso KeyReleasea los clientes correspondientes. Estos eventos contienen:

1. el código de la tecla pulsada
2. el estado actual de las teclas modificadoras (Mayús, Control, etc.) y los botones del ratón

Por lo tanto, el servidor envía el código de tecla y el estado del modificador sin intentar convertirlos en un carácter específico. Es responsabilidad del cliente realizar esta conversión. Por ejemplo, un cliente puede recibir un evento que indica que se presionó una tecla determinada mientras la tecla Mayús estaba presionada. Si esta tecla normalmente generaría el carácter "a", el cliente (y no el servidor) asocia este evento con el carácter "A".

Si bien el cliente realiza la traducción de códigos de tecla a símbolos de tecla, el servidor mantiene la tabla que representa esta asociación. Almacenar esta tabla en una ubicación centralizada la hace accesible a todos los clientes. Los clientes típicos solo solicitan esta asignación y la utilizan para decodificar el código de tecla y los campos de modificadores de un evento de tecla en un símbolo de tecla. Sin embargo, los clientes también pueden modificar esta asignación a su antojo.

Una tecla modificadora es aquella que, al pulsarla, cambia la función de otras teclas. Un ejemplo común es la tecla Mayús : al pulsarla junto con Mayús, se obtiene una letra mayúscula. Otras teclas modificadoras comunes son Control, Alt y Meta.

El servidor X trabaja con un máximo de ocho modificadores. Sin embargo, cada modificador puede asociarse a más de una tecla. Esto es necesario porque muchos teclados tienen teclas duplicadas para algunos modificadores. Por ejemplo, muchos teclados tienen dos teclas "Shift" (una a la izquierda y otra a la derecha). Estas dos teclas generan dos códigos de tecla diferentes al pulsarlas, pero el servidor X asocia ambos con el modificador "Shift".

Para cada uno de los ocho modificadores, el servidor X mantiene una lista de los códigos de tecla que considera que corresponden a dicho modificador. Por ejemplo, si la lista del primer modificador (el modificador "Shift") contiene el código de tecla 0x37, entonces la tecla que produce dicho código 0x37es considerada una tecla Shift por el servidor X.

El servidor X mantiene la lista de asignaciones de modificadores, pero cada cliente puede modificarla. Por ejemplo, un cliente puede solicitar que se añada la tecla F1 a la lista de modificadores "Shift". A partir de ese momento, esta tecla se comporta como cualquier otro modificador Shift. Sin embargo, el código de tecla correspondiente a F1 se sigue generando al pulsarla. Como resultado, F1 funciona como antes (por ejemplo, se puede abrir una ventana de ayuda al pulsarla), pero también funciona como la tecla Shift (al pulsar "a" en un editor de texto mientras se mantiene pulsada F1, se añade "A" al texto actual).

El servidor X mantiene y utiliza una asignación de modificadores para los botones del ratón. Sin embargo, los botones solo se pueden permutar . Esto resulta útil principalmente para intercambiar el botón izquierdo y el derecho para usuarios zurdos .

El xmodmapprograma muestra y modifica la asignación de teclas, modificadores y botones del ratón.

Un "captura" es una condición en la que todos los eventos de teclado o ratón se envían a un único cliente. Un cliente puede solicitar la captura del teclado, del ratón o de ambos: si el servidor atiende la solicitud, todos los eventos de teclado/ratón se envían al cliente que realizó la captura hasta que esta se libere. Los demás clientes no recibirán estos eventos.

Al solicitar una captura, un cliente especifica una ventana de captura : todos los eventos se envían al cliente que realiza la captura como si fueran relativos a la ventana de captura. Sin embargo, los demás clientes no reciben eventos, incluso si los han seleccionado en la ventana de captura. Existen dos tipos de capturas:

• activo: la captura se realiza inmediatamente
• pasivo: la acción de agarre se produce solo cuando se pulsa una tecla o botón del ratón previamente especificado y finaliza cuando se suelta.

Un cliente puede establecer una captura sobre el teclado, el puntero o ambos. Una solicitud de captura puede incluir una solicitud para congelar el teclado o el puntero. La diferencia entre capturar y congelar es que capturar cambia el destinatario de los eventos, mientras que congelar detiene su entrega por completo. Cuando un dispositivo se congela, los eventos que genera se almacenan en una cola para ser entregados normalmente cuando finalice la congelación.

En el caso de los eventos de puntero, un parámetro adicional afecta a la entrega de eventos: una máscara de eventos, que especifica qué tipos de eventos deben entregarse y cuáles deben descartarse.

Las solicitudes de captura incluyen un campo para especificar qué sucede con los eventos que se enviarían al cliente de captura, incluso si este no hubiera establecido la captura. En concreto, el cliente puede solicitar que se envíen de forma habitual o según la captura. Estas dos condiciones no son lo mismo, como podría parecer. Por ejemplo, un cliente que normalmente recibiría los eventos de teclado en una primera ventana puede solicitar que una segunda ventana capture el teclado. Los eventos que normalmente se enviarían a la primera ventana pueden o no redirigirse a la ventana de captura, dependiendo del parámetro especificado en la solicitud de captura.

Un cliente también puede solicitar la captura de todo el servidor. En este caso, el servidor no procesará ninguna solicitud, excepto las que provengan del cliente que realiza la captura.

Existen otras solicitudes y eventos en el protocolo principal. El primer tipo de solicitud se refiere a la relación de parentesco entre ventanas: un cliente puede solicitar cambiar el padre de una ventana o información sobre la jerarquía de ventanas. Otras solicitudes se refieren a la selección , que, sin embargo, se rige principalmente por otros protocolos. Otras solicitudes se refieren al foco de entrada y a la forma del puntero . Un cliente también puede solicitar que se elimine el propietario de un recurso (ventana, mapa de píxeles, etc.), lo que provoca que el servidor finalice la conexión con él. Finalmente, un cliente puede enviar una solicitud de no operación al servidor.

El protocolo central X fue diseñado para ser extensible. Este protocolo especifica un mecanismo para consultar las extensiones disponibles y cómo se realizan las solicitudes de extensión, los eventos y los paquetes de errores.

En concreto, un cliente puede solicitar la lista de todas las extensiones disponibles para obtener datos relacionados con una extensión específica. Los paquetes de extensiones son similares a los del protocolo principal. Este protocolo especifica que los paquetes de solicitud, evento y error contienen un número entero que indica su tipo (por ejemplo, la solicitud para crear una nueva ventana se numera como 1). Un rango de estos números enteros está reservado para las extensiones.

Cuando el cliente establece inicialmente una conexión con el servidor, este puede responder aceptando o rechazando la conexión, o solicitando autenticación . Una solicitud de autenticación contiene el nombre del método de autenticación que se utilizará. El protocolo principal no especifica el proceso de autenticación, que depende del tipo de autenticación empleada, salvo que finaliza con el envío por parte del servidor de un paquete de aceptación o de rechazo.

Durante la interacción habitual entre un cliente y un servidor, las únicas solicitudes relacionadas con la autenticación se refieren al método de acceso basado en el host . En concreto, un cliente puede solicitar que se habilite este método y puede solicitar la lectura y modificación de la lista de hosts ( clientes ) autorizados a conectarse. Las aplicaciones típicas no utilizan estas solicitudes; el xhostprograma las utiliza para otorgar a un usuario o a un script acceso a la lista de acceso de hosts. El método de acceso basado en el host se considera inseguro.

La mayoría de los programas cliente se comunican con el servidor a través de la biblioteca cliente Xlib . En particular, la mayoría de los clientes utilizan bibliotecas como Xaw , Motif , GTK+ o Qt , que a su vez utilizan Xlib para interactuar con el servidor. El uso de Xlib tiene los siguientes efectos:

1. Xlib hace que el cliente sea síncrono con respecto a las respuestas y los eventos:
   1. Las funciones de Xlib que envían solicitudes se bloquean hasta que se reciben las respuestas correspondientes, si es que se esperan; en otras palabras, un cliente X que no utiliza Xlib puede enviar una solicitud al servidor y luego realizar otras operaciones mientras espera la respuesta, pero un cliente que utiliza Xlib solo puede llamar a una función de Xlib que envía la solicitud y esperar la respuesta, bloqueando así al cliente mientras espera la respuesta (a menos que el cliente inicie un nuevo hilo antes de llamar a la función);
   2. Mientras que el servidor envía eventos de forma asíncrona , Xlib almacena los eventos recibidos por el cliente en una cola ; el programa cliente solo puede acceder a ellos llamando explícitamente a funciones de la biblioteca X11; en otras palabras, el cliente se ve obligado a bloquearse o a esperar activamente si espera un evento.
2. Xlib no envía las solicitudes al servidor inmediatamente, sino que las almacena en una cola, llamada búfer de salida ; las solicitudes en el búfer de salida se envían realmente cuando:
   1. El programa lo solicita explícitamente llamando a una función de biblioteca como por ejemplo XFlush:
   2. El programa llama a una función que da como resultado algo que implica una respuesta del servidor, como por ejemplo XGetWindowAttributes:
   3. El programa solicita un evento en la cola de eventos (por ejemplo, llamando a XNextEvent) y la llamada se bloquea (por ejemplo, XNextEventse bloquea si la cola está vacía).

Las bibliotecas de nivel superior, como Xt (que a su vez utilizan Xaw y Motif ), permiten que el programa cliente especifique las funciones de devolución de llamada asociadas a ciertos eventos; la biblioteca se encarga de consultar la cola de eventos y llamar a la función adecuada cuando sea necesario; algunos eventos, como los que indican la necesidad de redibujar una ventana, son gestionados internamente por Xt.

Las bibliotecas de nivel inferior, como XCB , proporcionan acceso asíncrono al protocolo, lo que permite una mejor ocultación de la latencia.

El protocolo central del Sistema X Window no impone ninguna norma sobre la comunicación entre clientes ni especifica cómo se utilizan las ventanas para formar los elementos visuales comunes en las interfaces gráficas de usuario ( botones , menús , etc.). Los elementos de la interfaz gráfica de usuario se definen mediante bibliotecas cliente que implementan conjuntos de herramientas de widgets . La comunicación entre clientes está cubierta por otros estándares, como las especificaciones ICCCM y freedesktop . ^{[ 9 ]}

La comunicación entre clientes es relevante para las selecciones, los búferes de corte y la función de arrastrar y soltar , que son los métodos que utiliza un usuario para transferir datos de una ventana a otra. Dado que las ventanas pueden estar controladas por diferentes programas, es necesario un protocolo para el intercambio de estos datos. La comunicación entre clientes también es relevante para los gestores de ventanas X , que son programas que controlan la apariencia de las ventanas y el aspecto general de la interfaz gráfica de usuario.

• Protocolos y arquitectura del sistema X Window
• Xlib
• Intrínsecos
• Xnee se puede utilizar para analizar el protocolo del sistema X Window.

• Fundación X.Org (página web oficial) - Enlace alternativo con el dominio 'freedesktop.org'.
• El sistema X Window System Internals se archivó el 19 de junio de 2024 en la Wayback Machine.
• Páginas de Kenton Lee sobre X y Motif archivadas el 20 de mayo de 2013 en la Wayback Machine.
• Protocolo del sistema X Window, versión 11 (versión actual)