Thread by @devruso

¿Queríais rant sobre el lamentable estado del stack gráfico de Linux? ¡Pues allá vamos! ⬇

⚠ hilo extremadamente largo y algo técnico (aunque he intentado simplificar)

Antes de nada, para los despistados: el "stack gráfico" es esa parte del OS que te permite ver porno ventanas e interactuar con ellas (moverlas. minimizarlas, etc...) usando el ratón, el teclado, un lápiz táctil, etc...

MacOS lo tiene. Windows lo tiene. Arrancas el ordenador, enchufas una o varias pantallas (a lo mejor con distinta resolución / DPI, a lo mejor con HDR). Se pintan las ventanas. Se pintan los colores...

... Interactúas con el ratón y el teclado, haces scroll. Reproduces videos con aceleración gráfica. Sin dramas, sin complicaciones. Fin.

... y luego esta Linux...

Quiero abrir con una cita:

"Si los creadores de X diseñasen coches, habría al menos 5 volantes escondidos por el habitáculo y ninguno de ellos funcionaria de la misma manera que el resto, pero podrías cambiar las marchas con los botones de la radio."
- Marcus J. Ranum

Todo empezó allá por el siglo XIII cuando los "PCs" no tenían capacidad ni para calcular 2+2, y la gente se conectaba a servidores externos (normalmente de la universidad o del trabajo) para trabajar en ellos.

Como esa manera de usar los PCs era lo normal, los X-m̶e̶n̶devs diseñaron un protocolo llamado "X" [0], que iba a servir para pintar interfaces en los "PCs" de la gente desde esos servidores externos.

[0] - en.wikipedia.org/wiki/X_Window_…

"Y todo de manera transparente a la red", que significaba algo así como que ibas a poder arrancar una app en un ordenador y poder usarla en otro, ya que X se encargaría de enviar por la tarjeta de red lo que hiciera falta para que eso funcionara "sin mas" ™.

Las apps (que ejecutarías en esas maquinas remotas) se llamarían "clientes de X" y en tu PC (que pintaría las interfaces de esas apps) ejecutarías un "servidor de X".

Porque para los X-devs lo que se ejecuta en remota es "cliente" y lo que se ejecuta en tu pc es "servidor".

Pero X era solo un protocolo, se necesitaba que algo lo implementara. Ahí nace XFree86 [1] (que en realidad se llamaba X386, pero por problemas de licencias, tras un impresionante despliegue de creatividad, cambiaron el "X-three-86" por "X-free-86").
[1] - en.wikipedia.org/wiki/XFree86

XFree86 implementa tanto el <servidor> como el <cliente>. Y funciona como prometieron. El cliente X (mediante una librería llamada "Xlib") le dice al servidor X "píntame un cuadradito de 50x50 pixeles en las coordenadas (100,400)" y el servidor lo pinta (y aparece en la pantalla)

Pero hay un problema. El protocolo de X no entiende qué es un "botón" o un "texto". El protocolo entiende de pixeles. ¿Quieres dibujar un botón? Pues tienes que decirle al servidor de X que quieres dibujar un cuadradito de tal tamaño en tal coordenada.

Y que luego quieres pintar una linea de tal color en tal coordenada (para simular una sombra). Y que luego quieres pintar <estos pixeles con forma de letras> en tal coordenada (para simular un texto encima del botón).

Para tener un campo de texto tienes que crear una ventana (sin bordes / barra superior / los botones de minimizar / maximizar) y embeberla donde te haga falta. ¿Quieres tener una app-formulario con 12 campos de texto? Pues tienes que crear 12 ventanas + la ventana de la app en sí

Básicamente, para dibujar un formulario con 4 botones, 10 campos de texto con sus 10 labels, sus sombras y sus bordes tienes que hacer 236347 peticiones desde el cliente X al servidor X. Como os podéis imaginar, todo era extremadamente rápido.

Ahí nace el concepto de "toolkit", que viene a ser una "librería" que esconde todas esas llamadas detrás de cómodas funciones tipo "creame_un_botón()", "creame_un_label()", etc... Y nace el primer toolkit: Motif.

Recapitulemos: tu app ➡ Motif ➡ Xlib ➡ servidor X
Facil, ¿no?

¡Seguimos!

Pero hay otro problema. El protocolo de X, <que fue creado para adaptarse al futuro gráfico de los ordenadores>, tampoco entiende los conceptos de "mover una ventana", "seleccionar un texto", "recibir entrada de un teclado/ratón", etc... El protocolo solo entiende como dibujar px

Vaya despiste más tonto por parte de los X-devs...

No pasa nada, porque cualquier problema se puede solucionar.

Simplemente modificaron el servidor de X y el protocolo para que pudieran entender esos conceptHAJHJAHJAHJAHJAJHAHJAHJAHJAAHJHJAAHJHJAHJAHJAHJAHJAHJAHJAHJAHJAHJAJHAJ

Crean un nuevo componente llamado "window manager" ("WM" de aquí en adelante), que se encargaría de "encapsular" todos los clientes X. Básicamente, se encargaría de saber donde están, cual de ellos tiene el foco, etc...

Y también crean un nuevo protocolo, ICCCM, que los WM usarían para hablar con el servidor X. [2]

[2] - en.wikipedia.org/wiki/Inter-Cli…

Motif, que hasta ahora era un toolkit, pasa a ser también un WM... 🤦‍♂️

Recapitulemos de nuevo:

tu app ➡ toolkit (Motif) ➡ Xlib (protocolo X) ➡ servidor X
y en paralelo
tu app ➡ WM (también Motif; protocolo ICCCM) ➡ servidor X

¿Por que tener un único WM que haga las cosas bien cuando puedes tener 100? Empiezan a salir decenas de WMs. KWin de KDE, GDM de Gnome, hasta Emacs (si, el editor de texto) se apunta a la fiesta con EXWM.
¿O creías que lo de que Emacs es prácticamente un OS era una exageración?

Pasan unos años, estamos a principios de los 2000, y XFree86 entra en una espiral de dramas y decadencia. Nace X.Org, que es exactamente lo mismo que XFree86, pero ahora llamado de otra manera. En aquel momento la realidad había cambiado radicalmente.

Los PCs habían avanzado hasta el punto de tener tarjetas gráficas integradas (ya no era necesario que la gente se conectara a servidores remotos para ejecutar ahí sus apps).

¿Y cómo arreglaron ese diseño de X, Xlib, ICCCM, los WM y todo eso que estaba mal de base (dada la nueva situación)? Obviamente tuvieron que reescribir todo el protocolo de 0 y plantearlHJAJAHHJAHJAHJAHJAHJAHAJHJAJAHHJAJHAJHAHJAHJAHJ

Cambiaron "tarjeta de red" por "IPC con unix sockets" y ahora tu PC ejecutaba tanto el servidor X como los clientes X.

Por si no lo has entendiendo bien: para que una app dibuje algo en la pantalla tiene que hacer peticiones (asíncronas) por un socket a un servidor (que también se esta ejecutando en tu PC), para que este a su vez dibuje eso.

Empiezan a aparecer problemas para los cuales el diseño de X no estaba preparado en absoluto. Pantallas con resolución que puede cambiar, varias pantallas, distinta tasa de refresco, GPUs capaces de acelerar el proceso de renderizado 2D/3D...

La gente empieza a pedir <mas>. Motif es feo, así que nacen otros toolkits (Qt, GTK, EFL, ...), y obviamente cada uno tiene que implementar todas las llamadas sobre Xlib de 0 y a su manera.

A estas alturas ya no era posible dar marcha atrás. Nadie quería reescribir esa bola de 💩. From lost to the river: la solución que se les ocurrió a los X-devs para "seguir adelante" fue meter "extensiones" en el servidor de X y que los clientes X usasen esas extensiones.

P. ej., para cambiar la resolución de la pantalla definieron un concepto llamado "display manager". Y luego implementaron 3 extensiones distintas para eso (Core X11, Xinerama, RandR). Cuando tu entorno de escritorio ("KDE", p. ej.) quería cambiar la resolución, tenía que...

... implementar 3 distintas maneras para hacerlo, una para cada extension (porque en Linux lo que importa no es que algo funcione, sino que tengas la libertad de poder elegir entre varias alternativas).

Otro ej.: Que los toolkit tuviesen que hacer 823663 llamadas para pintar un par de ventanitas no era muy optimo (se generaba un trafico de datos enorme entre los clientes X y el servidor X), así que definieron otro concepto llamado "buffer manager" que permitía a los clientes X

... compartir memoria con el servidor X para no tener que mandar cosas por el IPC... Y luego implementaron 3 extensiones distintas para eso (Core X11, SHM, DRI). Es decir, que ahora todos los toolkits hablaban con el servidor X a través de Xlib y a través de un buffer manager.

Recapitulemos:

tu app ➡ toolkit [ Motif | Qt | GTK | ... ] ➡ Xlib (protocolo X) ➡ servidor X
y en paralelo
tu app ➡ toolkit [ Motif | Qt | GTK | ... ] ➡ buffer manager ➡ servidor X
y en paralelo
tu app ➡ WM ([ Motif | KWin | GDM | ... ]; protocolo ICCCM) ➡ servidor X

Se definieron extensiones, con sus propios sub-protocolos, hasta para teclados con pantallas integradas (eran lo más en aquella época!) y para ventanas con formas no rectangulares...

Y X.Org implementó cada una de esas extensiones (y sus múltiples versiones). Nada más y nada menos que 5 arquitecturas distintas de aceleración 2D (XAA, EXA, UXA, SNA, UMA). Y también 2 distintos tipos de sistemas de input (Core X11, XInput)...

... Los 3 display managers y 3 buffer managers previamente mencionados...

...y un servidor de impresión (Xprint [3]) (porque que cojones, hemos venido a jugar, el servidor gráfico también va a hablar con las impresoras!)...

[3] - en.wikipedia.org/wiki/Xprint

...y un gestor de fuentes (Xft)...

...y un gestor energético (DPMS [4])...

[4] - x.org/releases/X11R7…

...y un gestor del bus PCI [5]...

[5] - x.org/wiki/PciRework…

...y un interprete de binarios (ELF, COFF y a.out)... [6]

[6] -

La cosa se desmadró. Mucho. Muchísimo. Hasta tal punto que X.Org se convirtió en un monstrenco que no había ni por dónde agarrarlo. Y los X-devs hicieron una propuesta para "trocearlo".

La propuesta tenía mas cosas en contra que a favor [7], pero the show must go on... Y entre aplausos y JAJOTAS X.Org se dividió en la friolera de 345 módulos [8]

[7] - x.org/wiki/Modulariz…
[8] - x.org/wiki/ModuleDes…

Como ahora X.Org era modular se podían cambiar cosas por separado! Así que los X-devs aprovecharon eso para reescribir y mejorar componentes clave, diseñándolos bien y documentanAHHJAHJAHJAHJAHJAJHAJHJHAHJAHJA.

Crearon otro Xlib, llamado XCB. Que también era asíncrono. Y estaba incluso peor documentado que Xlib. Y ahora todos los toolkits (Qt, GTK, EFL...) tuvieron que implementar soporte para XCB + Xlib. Porque lo importante en Linux es poder elegir. K las cosas funcionen en secundario

En cualquier caso, X a estas alturas estaba lleno de extensiones puestas por encima de otras extensiones y no había ninguna manera de garantizar la inter-compatibilidad entre cada extension. Tu navegador podía soportar "XInput 2.2", pero tu WM "Core X11".

¿Cuál se iba a usar? Se decidía con una tirada de dados al arrancar el PC.

¿Y la historia esa de que X era transparente a la red? 😂 si... la mitad de los buffer managers no soporta(ba)n eso ni en broma y la otra mitad estaban deprecados.

¿Y cuando enchufabas una pantalla externa? Pues... Tu entorno gráfico (KDE p. ej.), uno de los display managers (RandR p. ej.) y el servidor X empezaban a negociar la resolución adecuada, pero dada la naturaleza asíncrona de todo, y dado que tu entorno gráfico podía no estar

preparado para negociar con <ese> display manager en particular que tu servidor X tenía, y/o <esa> versión concreta de <ese> display manager, la negociación iba mas a menos así:

Tu entorno, usando Xlib, a RandR: Oye, pon la resolución 1024x768
RandR al servidor X: Oye, dicen que pongas la resolución 1024x768
X a RandR: Voy, dame un momento
RandR a tu entorno: Dice que va, que le des un momento
Tu entorno a RandR: Oye, pon 1280x1024

RandR a X: Oye, dicen que pongas 1280x1024
X a RandR: Eh? Pero... y la 1024x768? Esa va bien!
RandR a tu entorno: Dice que va bien!
Tu entorno a RandR: Vale, que se quede con esa!
RandR a X: Vale, quedate con esa!
X a RandR: Pero si 1280x1024 no va!!

RandR a tu entorno: Ahora dice que no va
Tu entorno: Si
RandR a tu servidor X: Si
X: ¿?¿Cómo que "si"?¿? Pero que coño me estas contando???¿!!

¿Y cuando enchufas una pantalla que es HDR? Pues no va. Sin más. No hay una extension para el servidor X que implemente eso. Habría que hacer la extensión, modificar todos los toolkits existentes (Qt, GTK, EFL, ...), todos los buffer managers, todas las

arquitecturas de aceleración y Xlib / XCB.
Intel lo ha intentado [9] , NVIDIA lo ha intentado [10] ...

[9] - lists.freedesktop.org/archives/dri-d…
[10] - lists.x.org/archives/xorg-…

... AMD lo ha intentado [11] , Red Hat lo quiere intentar [12] . Nadie lo ha conseguido a fecha 08/nov/2021.

[11] - lists.freedesktop.org/archives/amd-g…
[12] - global-redhat.icims.com/jobs/89344/sen…

... Y hablando de arquitecturas de aceleración... Como ya dije antes, la gente pedía <mas>. Quería sombras. Quería colores. Quería animaciones. Los finales de los 2000 en el escritorio eran un putiferio lumínico y los diseñadores eran Satanas personificado.

Estas obras de arte no eran baratas de pintar (en términos de recursos), así que los X-devs debían dar acceso al hardware a las apps, para que estas pudiesen usar aceleración 2D / 3D. Así que decidieron, por fin, poner fin a toda esta locura y reescribAHJHJAHJAJHAJHAHJJHAAJHAHJAH

Apañaron "libDRM", que "unificaba" (ni por asomo) todos los buffer managers que existían y luego crearon el proyecto "DRI" (si, como la extensión de buffer manager que he mencionado antes, solo que no tenía nada que ver).

El proyecto tenía por un lado una librería llamada "Mesa", por otro lado un modulo dentro del kernel llamado DRM. [13]

[13] - blog.mecheye.net/2016/01/dri/

La teoría es que tu app usaría Mesa (con OpenGL), y Mesa invocaría libDRM, y libDRM se hablaría con DRM y que DRM hablaría con la GPU (usando el driver correspondiente) para que hiciera lo que tuviera que hacer, y que luego el resultado se le pasaría de nuevo a libDRM, que...

... se lo pasaría a Mesa, que se lo mandaría al servidor X usando un buffer manager, y el servidor X lo pintaría por pantalla.

Y ahí es cuando dijeron "pos oye... esto a lo mejor... no va muy fino". Y lo solucionaron quitando piezas intermediaJAHHJAHJAHJAHJAJHAHJAHJAHJJAH. Crearon otra pieza a mayores, llamada "Compositor", que formaría parte del WM.

¿Para que? Porque ahora en vez de que el servidor de X pinte en la pantalla, sería el WM quién lo haría.

Recapitulemos

app ➡ toolkit ➡ Xlib/XCB ➡ servidor X
y en paralelo
app ➡ toolkit ➡ buf manager ➡ servidor X
y en paralelo
app ➡ WM ➡ servidor X
y a lo mejor
app con OpenGL ➡ Mesa ➡ libDRM ➡ DRM ➡ <driver GPU> ➡ DRM ➡ libDRM ➡ Mesa ➡ servidor X ➡ Compositor / WM

Entran en escena los 2 grandes fabricantes de GPUs (de ese momento): ATI y NVIDIA.
ATI saca su driver FGLRX que... bueno... intenta seguirle el juego a todo este pantano, aunque sin grandes resultados.

NVIDIA directamente dice que toda esa pila de 💩 no la toca ni con un palo, y saca su driver que desactiva, reimplementa o sustituye algo así como el 90% de todo eso. Va en contra de todo el stack que la comunidad ha montado, pero parece que da un rendimiento decente.

Dejo al lector adivinar cuál de los 2 drivers prefería la comunidad.

Ni siquiera me voy a molestar en desarrollar más sobre el tema de que en algún momento se añadieron "KMS" y "DMA" después del "DRM".

"AIGLX", "Gallium" y "Vesa" tirados por todo el stack, extensiones sobre los Compositores ("COW", "TFP", ...), etc... [14]

[14] - blog.mecheye.net/2012/06/the-li…

Todo se volvió tan ridículamente complejo, inestable, innecesario y disfuncional que literalmente todo el mundo que aportaba de alguna manera a X/Xorg se retiró [15] [16].

[15] - phoronix.com/scan.php?page=…
[16] - ajaxnwnk.blogspot.com/2020/10/on-aba…

A principios de los 2010 aparecen 2 alternativas a X / Xorg que, esta vez si, están planteadas, diseñadas y programadas de 0. Mir [17] y Wayland [18]

[17] - en.wikipedia.org/wiki/Mir_(soft…
[18] - en.wikipedia.org/wiki/Wayland_(…

Mir cuenta con el apoyo de Canonical (los creadores de Ubuntu) y sobretodo con el apoyo económico de Mark Shuttleworth. Está dispuesta a verter volquetes de billetes en Mir. Y ni siquiera tiene intenciones de hacerlo de código cerrado o algo por el estilo.

De hecho, la licencia es GPLv2 / v3. Por fin Linux tiene una esperanza para tener un stack gráfico decente!

La respuesta de la comunidad es unánime:

Bueno, no pasa nada. Rechazaron Mir, pero aceptaron Wayland con los brazos abiertos, así que algo es algo.
Wayland... ¿Que es Wayland?... Bueno... 🤔 Wayland en realidad es otro protocolo. Y... ese protocolo lo tienen que implementar unas cosas llamadas "Compositores", que...

... luego tienen que delegar en otras cosas llamadas "Window Managers" para que puedan pintar en a pantalla, que luego se comunicarían con "DRM" a traves de ...

No no no... espera.... esto me suena de algo...

Fast forward 12 años: a fecha 8/nov/2021 Wayland todavía tiene serias deficiencias, carece de las funcionalidades necesarias para reemplazar Xorg y solo un puñado de distribuciones grandes (Ubuntu/Debian, Fedora y OpenSuse) lo activan por defecto (únicamente con Gnome) y...

... aún así activan una capa de compatibilidad (XWayland) ya que no todas las apps están adaptadas.

Quizás algún dia. Mientras tanto...

Notas del autor: He dejado fuera del hilo multitud de cosas. Xorg tiene fallos de diseño que son imposibles de arreglar: refresco alto, varias pantallas con distinto DPI, completamente inseguro, los hot keys están fundamentalmente rotos, el concepto de "exclusive grab" del...

... hardware de entrada es plenamente disfuncional, "multihilo" y Xorg en la misma frase es básicamente un unicornio, y un extremadamente largo etc... [19]

[19] - itvision.altervista.org/why.linux.is.n…

Como sus propios creadores explicaron cuando lo abandonaron: "Xorg funciona de maravilla para ser un software de 40 años. Pero es un software de 40 años."