Pantalla Linux
El sistema de visualización de Linux utiliza múltiples tecnologías, protocolos, extensiones, aplicaciones, servidores (daemon), controladores y conceptos para lograr el sistema de ventanas, por ejemplo:Xorg, Wayland, X11, OpenGL, RandR, XrandR, Resolución de pantalla, DPI, Servidor de visualización , etc. Esto puede ser abrumador de entender por completo, pero cada lado tiene un propósito específico y no se usan todos juntos al mismo tiempo.
Protocolo X
El sistema de ventanas X, X11 (X versión 11) es un sistema de ventanas para pantallas de mapa de bits, común en sistemas operativos similares a Unix, X proporciona el marco básico para un entorno GUI:dibujar y mover ventanas en el dispositivo de visualización e interactuar con un mouse y un teclado. X no exige la interfaz de usuario, esto lo manejan los programas individuales. Como tal, el estilo visual de los entornos basados en X varía mucho; diferentes programas pueden presentar interfaces radicalmente diferentes. X se originó en el Proyecto Athena en el Instituto de Tecnología de Massachusetts (MIT) en 1984. El protocolo X ha estado en la versión 11 (de ahí "X11") desde septiembre de 1987. La Fundación X.Org lidera el proyecto X, con la implementación de referencia actual , X.Org Server, disponible como software gratuito y de código abierto bajo la licencia MIT y licencias permisivas similares.
Implementación X
La mayoría de las distribuciones de Linux utilizan servidor X.Org que es la implementación gratuita y de código abierto del servidor de visualización para el Sistema X Window (X11) administrado por la Fundación X.Org. Xorg/X por sí solo no admite varias funciones proporcionadas, como escalado o renderizado, para eso Xorg usa extensiones como XFixes, RandR (RandR es administrado por xrandr puede, por ejemplo, configurar la panorámica, la resolución o el escalado), GLX (extensión de OpenGL), Render o Composite, lo que hace que un subárbol completo de la jerarquía de ventanas se represente en un búfer fuera de la pantalla, las aplicaciones pueden tomar el contenido de ese búfer y hacer lo que quieran, el búfer fuera de la pantalla se puede fusionar automáticamente en la ventana principal o fusionado por programas externos, llamados administradores de composición para hacer la composición por su cuenta como algunos administradores de ventanas hacer; P.ej. Compiz, Enlightenment, KWin, Marco, Metacity, Muffin, Mutter y Xfwm. Para otros "sin composición " administradores de ventanas, se puede usar un administrador compuesto independiente, por ejemplo:Picom, Xcompmgr o Unagi. Extensiones compatibles con Xorg se puede enumerar con:xdpyinfo -display :0 -queryExtensions | awk '/^number of extensions:/,/^default screen number/' .
Por otro lado Wayland está pensado como un reemplazo más simple para Xorg / X11, más fácil de desarrollar y mantener, pero a partir de 2020, el soporte de escritorio para Wayland aún no está completamente listo aparte de Gnome (por ejemplo, KDE Kwin y soporte de Wayland); en el lado de las distribuciones, Fedora usa Wayland por defecto. Tenga en cuenta que Wayland y Xorg pueden funcionar simultáneamente, este puede ser el caso dependiendo de la configuración utilizada. XWayland es una serie de parches sobre el código base del servidor X.Org que implementa un servidor X que se ejecuta en el protocolo Wayland. Los parches son desarrollados y mantenidos por los desarrolladores de Wayland para que sean compatibles con las aplicaciones X11 durante la transición a Wayland, y se incluyeron en la versión 1.16 del servidor X.Org en 2014. Cuando un usuario ejecuta una aplicación X desde Weston, llama a XWayland para atender la solicitud.
Todo el alcance
Un servidor de visualización o el servidor de ventanas es un programa (como Xorg o Wayland) cuya tarea principal es coordinar la entrada y salida de sus clientes hacia y desde el resto del sistema operativo, el hardware y entre sí. El servidor de pantalla se comunica con sus clientes a través del protocolo del servidor de pantalla, un protocolo de comunicaciones, que puede ser transparente a la red o simplemente compatible con la red. Por ejemplo, X11 y Wayland son protocolos de comunicación de servidores de visualización.
Como se muestra en el diagrama, un administrador de ventanas es otro elemento importante del entorno de escritorio que es un software de sistema que controla la ubicación y apariencia de las ventanas dentro de un sistema de ventanas en una interfaz gráfica de usuario. La mayoría de los administradores de ventanas están diseñados para ayudar a proporcionar un entorno de escritorio. Trabajan en conjunto con el sistema gráfico subyacente que proporciona el soporte de funcionalidad necesario para el hardware de gráficos, los dispositivos señaladores y un teclado, y a menudo se escriben y crean utilizando un kit de herramientas de widgets. KDE usa KWin como administrador de ventanas (tiene un soporte limitado para Wayland a partir de 2020), de manera similar, Gnome 2 usa Metacity y Gnome 3 usa Mutter como administrador de ventanas.
Otro aspecto importante de un administrador de ventanas es el compositor o administrador de ventanas de composición , que es un administrador de ventanas que proporciona a las aplicaciones un búfer fuera de pantalla para cada ventana. El administrador de ventanas compone los búferes de ventana en una imagen que representa la pantalla y escribe el resultado en la memoria de visualización. Los administradores de ventanas de composición pueden realizar un procesamiento adicional en ventanas almacenadas en búfer, aplicando efectos animados 2D y 3D, como mezcla, desvanecimiento, escalado, rotación, duplicación, flexión y contorsión, barajado, desenfoque, redirección de aplicaciones y traducción de ventanas a una de varias pantallas. y escritorios virtuales. La tecnología de gráficos por computadora permite que los efectos visuales se representen en tiempo real, como sombras paralelas, vistas previas en vivo y animaciones complejas. Dado que la pantalla tiene doble búfer, no parpadea durante las actualizaciones. Los administradores de ventanas de composición más utilizados incluyen:Linux, BSD, Hurd y OpenSolaris-Compiz, KWin, Xfwm, Enlightenment y Mutter. cada uno tiene su propia implementación, por ejemplo, el compositor de KWin de KDE tiene muchas funciones/configuraciones como velocidad de animación, prevención de desgarros (vsync), miniaturas de ventana, método de escala y puede usar OpenGLv2/OpenGLv3 o XRender como un backend de renderizado junto con Xorg. (XRender/Render no debe confundirse con XRandR/RandR).
OpenGL (Biblioteca de gráficos abiertos) es una interfaz de programación de aplicaciones (API) multiplataforma y multilenguaje para renderizar gráficos vectoriales 2D y 3D. La API generalmente se usa para interactuar con una unidad de procesamiento de gráficos (GPU), para lograr una representación acelerada por hardware. OpenGL es una biblioteca de renderizado que se puede usar con Xorg, Wayland o cualquier aplicación que lo implemente. La instalación de OpenGL se puede verificar con glxinfo | grep OpenGL .
La resolución de la pantalla o modos de visualización de un monitor de computadora o dispositivo de visualización es el número de píxeles distintos en cada dimensión que se pueden mostrar. Por lo general, se cita como ancho × alto, con unidades en píxeles:por ejemplo, 1024 × 768 significa que el ancho es 1024 píxeles y la altura es 768 píxeles. xrandr se puede usar para agregar o renderizar/simular una nueva resolución de pantalla.
El PPD representa puntos por pulgada y es una medida de impresión/visualización espacial , en particular, el número de puntos individuales que se pueden colocar en una línea dentro del intervalo de 1 pulgada (2,54 cm). Las pantallas de las computadoras no tienen puntos, pero tienen píxeles, el concepto estrechamente relacionado es píxeles por pulgada o PPI y, por lo tanto, DPI se implementa con el concepto PPI. El 96 predeterminado Medida DPI media 96x96 vertical y horizontalmente. Además, ¿la configuración X DPI (punto por pulgada) solo está diseñada para escalar texto? El control de calidad es muy informativo.
Notas
Algunas herramientas de interfaz gráfica de usuario de KDE: systemsettings5> pantalla, kcmshell5 xserver y kinfocenter .
Referencias
Enlaces y fuentes: 1,2,3,4,5,6,7,8,9,10,11 y 12.
La pregunta es bastante amplia y se podría escribir mucho más sobre el tema de lo que cubre esta respuesta. He tratado de proporcionar una perspectiva histórica sobre la evolución de los gráficos de Linux. Los gráficos, los sistemas de ventanas y las interfaces gráficas de usuario (GUI) en Linux han sufrido muchos cambios desde principios de la década de 1990, cuando el sistema X Window (X11) se trasladó a Linux.
El sistema de ventanas X
El sistema X Window fue desarrollado en el MIT en la década de 1980. El nombre X11 se refiere a la versión 11 del protocolo X, pero X10 también se usó fuera del MIT antes de ser reemplazado por la versión 11 en 1987.
El sistema X Window fue diseñado para funcionar en sistemas gráficos que eran lo último en la década de 1980. Una estación de trabajo típica tenía un búfer de cuadro único conectado a un controlador CRT simple que mostraba el contenido del búfer de cuadro en un monitor de pantalla. La computación antes de la era de la PC y la estación de trabajo se realizaba a través de terminales de línea en serie ("tontos") conectados a computadoras centrales ubicadas en salas de máquinas de computadoras. Este contexto histórico influyó en el diseño de X11:las aplicaciones gráficas podían ejecutarse en computadoras remotas con el usuario interactuando con el programa usando terminales con capacidades gráficas. La "terminal" podría ser una estación de trabajo o una terminal X dedicada.
X11 fue diseñado como un sistema cliente-servidor. El servidor X era la única parte que se comunicaba directamente con el hardware de gráficos. Los clientes X son programas de aplicación que se comunican con el servidor mediante el protocolo X, ya sea utilizando un socket de dominio Unix local o una conexión TCP/IP. El cliente utiliza el protocolo X para enviar solicitudes al servidor y recibir mensajes de eventos del servidor.
Las solicitudes incluyen mensajes para:
- creación de ventana
- asignar/desasignar una ventana:hacer que la ventana sea visible/invisible
- dibujar en la ventana:dibujar píxeles, líneas, arcos, óvalos, mapas de píxeles, etc.
- mostrar texto usando una fuente, tamaño y estilo específicos
- mover y cambiar el tamaño de las ventanas, cambiar el orden de apilamiento de las ventanas, etc.
Los clientes reciben mensajes (no es una lista exhaustiva):
- respuestas a solicitudes
- eventos de pulsación de tecla y clic del ratón
- exponer eventos (se debe volver a dibujar un área de una ventana)
- enfocar eventos de ganancia/pérdida
Para permitir que el usuario maneje las ventanas en pantalla, por ejemplo, mover, cambiar el tamaño, cerrar, subir y bajar una ventana, se proporciona una aplicación particular llamada administrador de ventanas. El administrador de ventanas también puede mostrar decoraciones de ventanas como bordes, barras de título y menús globales.
Se podría decir que el servidor X11 es bastante "de alto nivel", ya que maneja (o al menos maneja tradicionalmente) todo tipo de recursos:ventanas, fuentes, mapas de píxeles, mapas de colores, contextos gráficos (cosas como color de primer plano/fondo, ancho de línea, etc. ). Además de esto, el servidor se encarga de cosas como las relaciones padre-hijo de las ventanas y el orden de apilamiento de las ventanas.
El protocolo X está diseñado para ser extensible. Se puede enseñar al servidor X a hacer nuevos trucos, y se agregan nuevos códigos de operación al protocolo para que el servidor realice esos trucos. Por ejemplo, la extensión XRender presenta una forma de manejar la transparencia ("mezcla alfa"). Esta extensión se introdujo principalmente para admitir fuentes suavizadas, pero también se ha utilizado para efectos de escritorio como sombras paralelas en las ventanas. La extensión RandR ("Redimensionar y rotar") permite cambiar el tamaño, rotar y reflejar la ventana raíz en la pantalla. Esto le permite proyectar la pantalla con un proyector al revés o con un monitor inclinado.
La extensión GLX (OpenGL Extension to the X Window System) hace posible usar OpenGL en una ventana proporcionada por el servidor X. Las llamadas a OpenGL están incrustadas en las solicitudes del protocolo X.
En algún momento de la evolución de X11, el manejo de fuentes pasó a ser manejado por el cliente. Las razones detrás de este cambio se analizan en Nuevas evoluciones en el sistema X Window.
Representación directa
A principios de la década de 2000, el hardware de visualización había recorrido un largo camino desde las simples pantallas de mapa de bits en blanco y negro que existían cuando comenzó el desarrollo de X en la década de 1980. La sobrecarga relativa de X11 del modelo de comunicación entre procesos (IPC) había crecido demasiado, incluso cuando se usaba un socket local. La solución a esto fue abandonar el principio de que el servidor X es la única parte que se comunica directamente con el hardware y dejar que los clientes se comuniquen directamente con la tarjeta gráfica. Nació la Infraestructura de Representación Directa (DRI).
DRI permite que una aplicación de cliente X omita el servidor X y renderice directamente en el adaptador de gráficos. Debido a que varias aplicaciones de representación directa, además del servidor X tradicional, pueden estar activas al mismo tiempo, se introdujo un componente del núcleo denominado Administrador de representación directa para arbitrar el acceso al hardware. Hay tres versiones de la arquitectura DRI, la DRI original (obsoleta), DRI2 y DRI3.
Administradores de ventanas de composición
La siguiente innovación que ingresó a la escena gráfica de Linux fue el administrador de ventanas de composición. Tradicionalmente, cada aplicación de cliente X era responsable de volver a pintar sus ventanas (parcialmente o toda la ventana) a pedido. El servidor X envió a la aplicación un evento Expose cuando se necesitaba volver a pintar como resultado de la asignación de la ventana en la pantalla, o si ya no está oculta por alguna otra ventana. Cuando se elimina una ventana superpuesta, la ventana debajo de ella queda expuesta. Si no se vuelve a pintar esta área, se seguirán mostrando los contenidos antiguos. https://en.wikipedia.org/wiki/Artefacto_visual
Un administrador de ventanas de composición cambia esto. Las aplicaciones representan sus propios búferes fuera de la pantalla, cada uno de los cuales es una especie de pantalla separada con acceso exclusivo de la aplicación propietaria del búfer. Es tarea del administrador de ventanas de composición mostrar estos búferes en ventanas en una pantalla real, recortando cualquier ventana que esté oculta por otras ventanas o parcialmente fuera de la pantalla. El administrador de ventanas muestra una "composición" de las ventanas.
Un administrador de composición normalmente también puede mostrar efectos animados, como escalar, deformar, desvanecer, rotar, desenfocar las ventanas. Por ejemplo, mover una ventana puede hacer que se tambalee, o los escritorios virtuales pueden mostrarse al costado de un cubo giratorio.
Configuración del modo de núcleo
El servidor X tradicionalmente también se ocupaba de configurar los modos del adaptador de gráficos, como la resolución y las tasas de actualización. Desde entonces, la configuración del modo se ha movido a un componente del kernel de Linux llamado Configuración del modo del kernel (KMS). Esto resolvió muchos problemas al cambiar entre las consolas virtuales de Linux.
Evdev
El servidor X también tenía conocimiento de los dispositivos de entrada y, por ejemplo, el tipo de mouse debía especificarse en la configuración X. El servidor X se ha liberado de esta tarea con la introducción del subsistema evdev del kernel de Linux, que proporciona una interfaz de eventos de entrada genérica.
Wayland
Con todos estos desarrollos, muchas de las tareas realizadas por el servidor X se han trasladado fuera del servidor X. Al usar la representación directa, los clientes ya no usan el protocolo X. Gracias a KMS, el servidor X no necesita meterse con la programación de bajo nivel de los adaptadores de gráficos. Con evdev, el manejo de dispositivos de entrada se simplificó en el servidor X. Cuando se usa un administrador de ventanas de composición que reorganiza y deforma las ventanas, el servidor X ya no tiene idea de lo que está pasando en la pantalla. "El gestor de ventanas es el nuevo servidor X".
Wayland surgió como resultado de darse cuenta de que el proceso del servidor X tenía poco que hacer y, al eliminar al intermediario (el servidor X), se podía lograr un sistema de gráficos de escritorio mucho más simple. La compatibilidad con versiones anteriores se proporciona a través de Xwayland, un servidor Xorg modificado que muestra ventanas X de nivel superior utilizando superficies Wayland.
Estrictamente hablando, Wayland es solo un protocolo que define cómo los clientes se comunican con el servidor de visualización. El protocolo Wayland es bastante diferente al protocolo X:el protocolo Wayland no define mensajes para dibujar gráficos o texto, ni maneja fuentes.
En la arquitectura de Wayland, el administrador de ventanas y el servidor de visualización se fusionan en un componente de software, el administrador de ventanas de composición. Los clientes pueden solicitar, a través de una biblioteca de software que utiliza el protocolo Wayland, una superficie para dibujar. Una "superficie es un objeto que representa un área rectangular en la pantalla, definida por una ubicación, tamaño y contenido de píxeles".
Los clientes procesan en búferes fuera de la pantalla, que luego se adjuntan a una superficie, produciendo una salida en la pantalla. El cliente puede usar varias API para hacer el renderizado:OpenGL, OpenGL ES, etc. ("¿Qué es la API de dibujo? Lo que quieras que sea"). Se usa el doble búfer:un cliente actualiza su imagen usando un segundo búfer, y cuando esa memoria intermedia contiene una imagen coherente, se cambia para visualizarse en el siguiente intervalo de supresión vertical del monitor de visualización. El lema de Wayland es:"Todos los marcos son perfectos", es decir, las ventanas no se rasgan, parpadean ni parpadean.
El manejo de entrada en Wayland pasa por el compositor, que es el único componente que sabe qué ventana está debajo del cursor del mouse (recuerde, el compositor también puede haber distorsionado las ventanas). El compositor transforma las coordenadas de la pantalla en coordenadas locales de la ventana correspondiente y envía el evento al cliente.
Si te interesa la historia que condujo a la creación de Wayland, te recomiendo ver la hilarante presentación de Daniel Stone La verdadera historia detrás de Wayland y X.