Sistema X Window

Para ejecutar una aplicación cliente X en una máquina remota, el usuario puede hacer lo siguiente:

• En la máquina local, abre una ventana de terminal.
• Utilice ssh -Xel comando para conectarse a la máquina remota.
• solicitar un servicio de entrada/visualización local (por ejemplo, si no se utiliza SSH con el reenvío X habilitado)export DISPLAY=[user's machine]:0

La aplicación cliente X remota establecerá entonces una conexión con el servidor X local del usuario, proporcionándole visualización y entrada de datos.

Como alternativa, la máquina local puede ejecutar un pequeño programa que se conecta a la máquina remota e inicia la aplicación cliente.

Algunos ejemplos prácticos de clientes remotos son:

• Administrar una máquina remota gráficamente (similar a usar el escritorio remoto, pero con ventanas individuales).
• Utilizar una aplicación cliente para unirse a un gran número de otros usuarios de terminales en grupos de trabajo colaborativos.
• ejecutar una simulación computacionalmente intensiva en una máquina remota y mostrar los resultados en una máquina de escritorio local.
• Ejecutar software gráfico en varias máquinas a la vez, controladas por una sola pantalla, teclado y ratón.

Un terminal X es un cliente ligero que solo ejecuta un servidor X. Esta arquitectura se popularizó para crear parques de terminales económicos que permitieran a muchos usuarios utilizar simultáneamente el mismo servidor para ejecutar programas como clientes de sus terminales X. Este uso se ajusta plenamente a la intención original del proyecto del MIT.

Los terminales X exploran la red (el dominio de difusión local ) utilizando el Protocolo de Control del Administrador de Pantallas X para generar una lista de hosts disponibles que pueden actuar como clientes. Uno de los hosts clientes debe ejecutar un administrador de pantallas X.

Una limitación de los terminales X y la mayoría de los clientes ligeros es que no admiten ninguna entrada ni salida de datos más allá del teclado, el ratón y la pantalla. Se presupone que todos los datos relevantes residen exclusivamente en el servidor remoto, y el usuario del terminal X no dispone de métodos para guardar o cargar datos desde un dispositivo periférico local .

Los terminales X dedicados (de hardware) han caído en desuso; un PC o un cliente ligero moderno con un servidor X suele proporcionar la misma funcionalidad al mismo coste, o incluso a un coste inferior.

La falta de directrices de diseño en X ha dado lugar a varias interfaces muy diferentes y a aplicaciones que no siempre han funcionado bien juntas. El Manual de Convenciones de Comunicación entre Clientes (ICCCM), una especificación para la interoperabilidad de clientes, tiene fama de ser difícil de implementar correctamente. Otros esfuerzos de estandarización, como Motif y CDE, no aliviaron los problemas. Esto ha frustrado a usuarios y programadores. ^{[ 9 ]} Los programadores de gráficos ahora suelen abordar la coherencia de la apariencia y la comunicación de las aplicaciones codificando para un entorno de escritorio específico o para un conjunto de herramientas de widgets específico, lo que también evita tener que lidiar directamente con el ICCCM.

X tampoco ofrece soporte nativo para procedimientos almacenados definidos por el usuario en el servidor X, a diferencia de NeWS ; no dispone de una herramienta de scripting Turing-completa . Por lo tanto, los distintos entornos de escritorio pueden ofrecer sus propias funcionalidades (generalmente incompatibles entre sí). 

Los sistemas basados ​​en X pueden presentar problemas de accesibilidad que dificultan el uso del ordenador para usuarios con discapacidad, como el clic derecho , el doble clic , el clic central , el desplazamiento del ratón y el robo de foco . Algunos clientes de X11 gestionan mejor los problemas de accesibilidad que otros, por lo que las personas con dificultades de accesibilidad no quedan excluidas del uso de X11. Sin embargo, no existe un estándar ni directrices de accesibilidad para X11. Dentro del proceso de estandarización de X11 no hay un grupo de trabajo sobre accesibilidad; no obstante, los proyectos de software están abordando las necesidades de accesibilidad para proporcionar estas funcionalidades sobre X.

El proyecto Orca añade soporte de accesibilidad al sistema X Window, incluyendo la implementación de una API ( AT-SPI ^{[ 10 ]} ). Esto se combina con ATK de GNOME para permitir que las funciones de accesibilidad se implementen en programas X utilizando las API de GNOME/GTK. ^{[ 11 ]} KDE proporciona un conjunto diferente de software de accesibilidad, incluyendo un convertidor de texto a voz y un magnificador de pantalla. ^{[ 12 ]} Los otros escritorios principales (LXDE, Xfce y Enlightenment) intentan ser compatibles con ATK.

Un cliente X generalmente no puede desconectarse de un servidor y conectarse a otro a menos que su código lo permita específicamente ( Emacs es uno de los pocos programas comunes con esta capacidad). Por lo tanto, generalmente no es posible mover una sesión completa de un servidor X a otro. Sin embargo, enfoques como Virtual Network Computing (VNC), NX y Xpra permiten acceder a una sesión virtual desde diferentes servidores X (de manera similar a GNU Screen en relación con las terminales), y otras aplicaciones y conjuntos de herramientas proporcionan funcionalidades relacionadas. ^{[ 13 ]} También existen soluciones alternativas como x11vnc ( visores VNC :0 ), el modo sombra de Xpra y el modo sombra nxagent de NX para que la pantalla del servidor X actual esté disponible. Esta capacidad permite cambiar la interfaz de usuario (ratón, teclado, monitor) de una aplicación en ejecución de una ubicación a otra sin detener y reiniciar la aplicación.

El tráfico de red entre un servidor X y clientes X remotos no está cifrado por defecto. Un atacante con un analizador de paquetes puede interceptarlo, lo que le permite ver todo lo que se muestra o se envía desde la pantalla del usuario. La forma más común de cifrar el tráfico X es establecer un túnel SSH ( Secure Shell ) para la comunicación.

Como ocurre con todos los clientes ligeros , al usar X en una red, las limitaciones de ancho de banda pueden dificultar el uso de aplicaciones con uso intensivo de mapas de bits que requieren actualizar rápidamente grandes secciones de la pantalla con baja latencia, como la animación 3D o la edición de fotos. Incluso una transmisión de vídeo relativamente pequeña sin comprimir de 640 × 480 × 24  bits a 30 fps (~211 Mbit/s) puede superar fácilmente el ancho de banda de una red de 100 Mbit/s para un solo cliente. En cambio, las versiones modernas de X suelen tener extensiones como Mesa que permiten optimizar la visualización local de los gráficos de un programa local para evitar el modelo de red y controlar directamente la tarjeta gráfica, para su uso con vídeo a pantalla completa, aplicaciones 3D renderizadas y otras aplicaciones similares.   

El diseño de X requiere que los clientes y el servidor operen por separado, y la independencia del dispositivo y la separación del cliente y el servidor generan sobrecarga. La mayor parte de la sobrecarga proviene del tiempo de retardo de ida y vuelta de la red entre el cliente y el servidor ( latencia ) más que del protocolo en sí: las mejores soluciones a los problemas de rendimiento dependen de un diseño de aplicación eficiente. ^{[ 14 ]} Una crítica común a X es que sus características de red resultan en una complejidad excesiva y un rendimiento reducido si solo se usan localmente.

Las implementaciones modernas de X utilizan sockets de dominio Unix para conexiones eficientes en el mismo host. Además, se puede emplear memoria compartida (mediante la extensión MIT-SHM ) para una comunicación cliente-servidor más rápida. ^{[ 15 ]} Sin embargo, el programador debe activar y utilizar explícitamente la extensión de memoria compartida. También es necesario proporcionar rutas alternativas para mantener la compatibilidad con implementaciones anteriores y para comunicarse con servidores X no locales.

Varios sistemas de visualización de mapas de bits precedieron a X. De Xerox surgieron el Alto (1973) y el Star (1981). De Apollo Computer surgió Display Manager (1981). De Apple surgieron el Lisa (1983) y el Macintosh (1984). El mundo Unix contaba con el Proyecto Andrew (1982) y el terminal Blit de Rob Pike (1982).

La Universidad Carnegie Mellon desarrolló una aplicación de acceso remoto llamada Alto Terminal, que mostraba ventanas superpuestas en el Xerox Alto y hacía que los hosts remotos (normalmente sistemas DEC VAX que ejecutaban Unix) se encargaran de gestionar los eventos de visualización de ventanas y de actualizar el contenido de las mismas según fuera necesario.

X debe su nombre a que es sucesor de un sistema de ventanas anterior a 1983 llamado W (la letra que precede a la X en el alfabeto inglés ). W se ejecutaba bajo el sistema operativo V. W utilizaba un protocolo de red que admitía ventanas de terminal y gráficas, y el servidor mantenía las listas de visualización.

La idea original de X surgió en el MIT en 1984 como una colaboración entre Jim Gettys (del Proyecto Athena ) y Bob Scheifler (del Laboratorio de Ciencias de la Computación del MIT ). Scheifler necesitaba un entorno de visualización utilizable para depurar el sistema Argus. El Proyecto Athena (un proyecto conjunto entre DEC , el MIT e IBM para facilitar el acceso a los recursos informáticos a todos los estudiantes) necesitaba un sistema gráfico independiente de la plataforma para conectar sus sistemas heterogéneos de múltiples proveedores; el sistema de ventanas que se estaba desarrollando entonces en el Proyecto Andrew de la Universidad Carnegie Mellon no ofrecía licencias, y no existían alternativas.

El proyecto solucionó este problema creando un protocolo que permitía ejecutar aplicaciones locales y acceder a recursos remotos. A mediados de 1983, una primera versión de W para Unix funcionaba a una quinta parte de su velocidad en V; en mayo de 1984, Scheifler reemplazó el protocolo síncrono de W por uno asíncrono y las listas de visualización por gráficos en modo inmediato para crear X versión 1. X se convirtió en el primer entorno de sistema de ventanas que ofrecía verdadera independencia de hardware e independencia del proveedor.

Scheifler, Gettys y Ron Newman se pusieron manos a la obra y X progresó rápidamente. Lanzaron la versión 6 en enero de 1985. DEC, que por entonces se preparaba para lanzar su primera estación de trabajo Ultrix , consideró que X era el único sistema de ventanas que probablemente estaría disponible a tiempo. Los ingenieros de DEC adaptaron X6 a la pantalla QVSS de DEC en MicroVAX .

En el segundo trimestre de 1985, X adquirió soporte para color para funcionar en la DEC VAXstation -II/GPX, dando lugar a lo que se convertiría en la versión 9.

Un grupo de la Universidad de Brown adaptó la versión 9 al IBM RT PC , pero los problemas con la lectura de datos no alineados en el RT obligaron a un cambio de protocolo incompatible, lo que llevó a la versión 10 a finales de 1985. X10R1 se lanzó en 1985. ^{[ 23 ]} Para 1986, organizaciones externas habían comenzado a solicitar X. X10R2 se lanzó en enero de 1986, y luego X10R3 en febrero de 1986. Aunque el MIT había licenciado X6 a algunos grupos externos por una tarifa, decidió en ese momento licenciar X10R3 y versiones futuras bajo lo que se conoció como la Licencia MIT , con la intención de popularizar X aún más y, a cambio, esperando que muchas más aplicaciones estuvieran disponibles. X10R3 se convirtió en la primera versión en lograr una amplia implementación, con DEC y Hewlett-Packard lanzando productos basados ​​en ella. Otros grupos adaptaron X10 a Apollo y a estaciones de trabajo Sun e incluso al IBM PC/AT . En aquella época, durante la feria Autofact, se realizaron demostraciones de la primera aplicación comercial de X (un sistema de ingeniería mecánica asistida por ordenador de Cognition Inc. que funcionaba en VAX y se visualizaba remotamente en PC con un servidor X adaptado por Jim Fulton y Jan Hardenbergh). La última versión de X10, X10R4, apareció en diciembre de 1986. Se intentó habilitar los servidores X como dispositivos de colaboración en tiempo real, de forma similar a como la Computación de Red Virtual (VNC) permitiría más tarde compartir un escritorio. Uno de estos primeros intentos fue la herramienta SharedX de Philip J. Gust .

Aunque X10 ofrecía una funcionalidad interesante y potente, se hizo evidente que el protocolo X necesitaba un rediseño más independiente del hardware antes de su implementación generalizada, pero el MIT por sí solo no disponía de los recursos necesarios para un rediseño tan completo. Casualmente, el Laboratorio de Software Occidental de DEC se encontraba entre proyectos con un equipo experimentado. Smokey Wallace, de DEC WSL, y Jim Gettys propusieron que DEC WSL desarrollara X11 y lo pusiera a disposición del público de forma gratuita bajo las mismas condiciones que X9 y X10. Este proceso comenzó en mayo de 1986, y el protocolo se finalizó en agosto. Las pruebas alfa del software comenzaron en febrero de 1987, las pruebas beta en mayo; el lanzamiento de X11 tuvo lugar finalmente el 15 de septiembre de 1987. ^{[ 24 ]}

El diseño del protocolo X11, liderado por Scheifler, se debatió ampliamente en listas de correo abiertas de la incipiente Internet, conectadas a los grupos de noticias de USENET. Gettys se trasladó a California para colaborar en el desarrollo de X11 en WSL, procedente del Centro de Investigación de Sistemas de DEC, donde Phil Karlton y Susan Angebrandt dirigieron el diseño e implementación del servidor de ejemplo X11. Por lo tanto, X representa uno de los primeros proyectos de software libre y de código abierto distribuidos a gran escala .

A finales de la década de 1980, X era "el logro individual más importante de Athena hasta la fecha", como escribió Simson Garfinkel en 1989. Según se informa, DEC creía que su desarrollo por sí solo había justificado la donación de la compañía al MIT. Gettys se unió al equipo de diseño de la VAXstation 2000 para asegurar que X, que DEC denominó DECwindows , funcionara en ella, y la compañía asignó 1200 empleados para portar X tanto a Ultrix como a VMS. ^{[ 25 ] [ 26 ]} En 1990, IBM y Motorola anunciaron sus propios terminales X. Bill Joy, de Sun Microsystems , que fabricaba estaciones de trabajo sin disco que competían con los terminales X, argumentó que X tenía fallos técnicos y podía saturar las redes. ^{[ 27 ]}

En 1987, con el éxito de X11 ya evidente, el MIT deseaba ceder la gestión de X, pero en una reunión celebrada en junio de ese mismo año con nueve proveedores, estos manifestaron al MIT su convicción de que era necesaria una entidad neutral para evitar la fragmentación de X en el mercado. En enero de 1988, se formó el Consorcio MIT X como un grupo de proveedores sin ánimo de lucro, con Scheifler como director, para dirigir el desarrollo futuro de X en un entorno neutral que incluyera intereses comerciales y educativos.

Jim Fulton se unió en enero de 1988 y Keith Packard en marzo de 1988 como desarrolladores sénior . Jim se centró en Xlib , fuentes , gestores de ventanas y utilidades, mientras que Keith reimplementó el servidor. Donna Converse, Chris D. Peterson y Stephen Gildea se unieron más tarde ese mismo año, centrándose en kits de herramientas y conjuntos de widgets, trabajando en estrecha colaboración con Ralph Swick del Proyecto Athena del MIT. El Consorcio X del MIT produjo varias revisiones significativas de X11, la primera (Versión 2 – X11R2) en febrero de 1988. Jay Hersh se unió al equipo en enero de 1991 para trabajar en la funcionalidad PEX y X113D. Poco después se unieron Ralph Mor (quien también trabajó en PEX) y Dave Sternlicht. En 1993, cuando el Consorcio X del MIT se preparaba para separarse del MIT, se unieron al equipo R. Gary Cutbill, Kaleb Keithley y David Wiggins. ^{[ 28 ]} 

En 1993, se formó el X Consortium, Inc. (una corporación sin fines de lucro) como sucesor del MIT X Consortium. Lanzó X11R6 el 16 de mayo de 1994. En 1995 asumió el desarrollo del conjunto de herramientas Motif y del Entorno de Escritorio Común para sistemas Unix. El X Consortium se disolvió a finales de 1996, produciendo una revisión final, X11R6.3, y un legado de creciente influencia comercial en el desarrollo. ^{[ 29 ] [ 30 ]}

En enero de 1997, el Consorcio X cedió la gestión de X a The Open Group , un grupo de proveedores formado a principios de 1996 mediante la fusión de la Open Software Foundation y X/Open .

The Open Group lanzó X11R6.4 a principios de 1998. De manera controvertida, X11R6.4 se apartó de los términos de licencia liberales tradicionales, ya que The Open Group buscaba asegurar la financiación para el desarrollo de X, y citó específicamente a XFree86 como no contribuyendo significativamente a X. ^{[ 31 ]} Los nuevos términos habrían hecho que X dejara de ser software libre : cero costo para uso no comercial, pero una tarifa en otros casos. Después de que XFree86 parecía estar a punto de bifurcarse , ^{[ 32 ]} The Open Group volvió a licenciar X11R6.4 bajo la licencia tradicional en septiembre de 1998. ^{[ 33 ]} El último lanzamiento de The Open Group fue X11R6.4 parche 3.

XFree86 se originó en 1992 a partir del servidor X386 para PC compatibles con IBM , incluido con X11R5 en 1991, escrito por Thomas Roell y Mark W. Snitily y donado al Consorcio X del MIT por Snitily Graphics Consulting Services (SGCS). Con el tiempo, XFree86 evolucionó desde una simple adaptación de X hasta convertirse en la implementación líder y más popular, y en el estándar de facto para el desarrollo de X. ^{[ 34 ]}

En mayo de 1999, The Open Group formó X.Org. X.Org supervisó el lanzamiento de las versiones X11R6.5.1 en adelante. El desarrollo de X en ese momento se había vuelto moribundo; ^{[ 35 ]} la mayor parte de la innovación técnica desde que el Consorcio X se había disuelto había tenido lugar en el proyecto XFree86. ^{[ 36 ]} En 1999, el equipo de XFree86 se unió a X.Org como miembro honorario (no remunerado), ^{[ 37 ]} alentado por varias compañías de hardware ^{[ 38 ]} interesadas en usar XFree86 con Linux y en su estatus como la versión más popular de X.

Para 2003, mientras la popularidad de Linux (y por lo tanto la base instalada de X) aumentaba vertiginosamente, X.Org permaneció inactivo, ^{[ 39 ]} y el desarrollo activo se llevó a cabo principalmente dentro de XFree86. Sin embargo, se desarrolló una considerable disidencia dentro de XFree86. El proyecto XFree86 sufría de la percepción de un modelo de desarrollo demasiado rígido ; los desarrolladores no podían obtener acceso de confirmación de CVS ^{[ 40 ] [ 41 ]} y los proveedores tenían que mantener conjuntos de parches extensos . ^{[ 42 ]} En marzo de 2003, la organización XFree86 expulsó a Keith Packard, quien se había unido a XFree86 después del fin del Consorcio X del MIT original, con considerable resentimiento. ^{[ 43 ] [ 44 ] [ 45 ]}

X.Org y XFree86 comenzaron a discutir una reorganización adecuada para fomentar el desarrollo de X. ^{[ 46 ] [ 47 ] [ 48 ]} Jim Gettys había estado impulsando con fuerza un modelo de desarrollo abierto desde al menos el año 2000. ^{[ 49 ]} Gettys, Packard y varios otros comenzaron a discutir en detalle los requisitos para la gobernanza efectiva de X con desarrollo abierto.

Finalmente, en un eco de la disputa de licencias de X11R6.4, XFree86 lanzó la versión 4.4 en febrero de 2004 bajo una licencia más restrictiva que muchos proyectos que dependían de X consideraron inaceptable. ^{[ 50 ]} La cláusula añadida a la licencia se basó en la cláusula publicitaria de la licencia BSD original, que la Free Software Foundation y Debian consideraron incompatible con la Licencia Pública General de GNU . ^{[ 51 ]} Otros grupos la vieron como contraria al espíritu del X original. Theo de Raadt de OpenBSD , por ejemplo, amenazó con bifurcar XFree86 citando preocupaciones sobre la licencia. ^{[ 52 ]} El problema de la licencia, combinado con las dificultades para introducir cambios, hizo que muchos sintieran que era el momento oportuno para una bifurcación. ^{[ 53 ]}

A principios de 2004, varias personas de X.Org y freedesktop.org formaron la Fundación X.Org , y The Open Group le cedió el control del x.orgdominio . Esto marcó un cambio radical en la gobernanza de X. Mientras que los administradores de X desde 1988 (incluida la anterior X.Org) habían sido organizaciones proveedoras, la Fundación estaba liderada por desarrolladores de software y utilizaba un modelo de desarrollo comunitario basado en el modelo de bazar , que depende de la participación externa. La membresía estaba abierta a particulares, y la membresía corporativa se realizaba mediante patrocinio. Varias grandes corporaciones, como Hewlett-Packard, apoyan actualmente a la Fundación X.Org.

La Fundación ejerce un papel de supervisión sobre el desarrollo de X: las decisiones técnicas se toman en función de sus méritos, alcanzando un consenso general entre los miembros de la comunidad. Las decisiones técnicas no las toma la junta directiva; en este sentido, se inspira en gran medida en la Fundación GNOME , que no interviene en el desarrollo técnico . La Fundación no emplea desarrolladores. La Fundación lanzó X11R6.7, el servidor X.Org , en abril de 2004, basado en XFree86 4.4RC2 con los cambios de X11R6.6 incorporados. Gettys y Packard habían adoptado la última versión de XFree86 bajo la antigua licencia y, al apostar por un modelo de desarrollo abierto y mantener la compatibilidad con la GPL, atrajeron a muchos de los antiguos desarrolladores de XFree86. ^{[ 51 ]}

Aunque X11 había recibido extensiones como la compatibilidad con OpenGL durante la década de 1990, su arquitectura se mantuvo fundamentalmente sin cambios durante esa década. Sin embargo, a principios de la década de 2000, se revisó para resolver una serie de problemas que habían surgido a lo largo de los años, incluyendo una arquitectura de fuentes "defectuosa" , un sistema de gráficos 2D "que siempre había sido concebido para ser ampliado y/o reemplazado", y problemas de latencia . ^{[ 54 ]} X11R6.8 salió en septiembre de 2004. Añadió nuevas características significativas, incluyendo soporte preliminar para ventanas translúcidas y otros efectos visuales sofisticados, lupas de pantalla y miniaturas, y facilidades para integrarse con sistemas de visualización inmersiva 3D como Project Looking Glass de Sun y el proyecto Croquet . Las aplicaciones externas llamadas gestores de ventanas de composición proporcionan políticas para la apariencia visual.

El 21 de diciembre de 2005, ^{[ 55 ]} X.Org publicó X11R6.9, el árbol de código fuente monolítico para usuarios heredados, y X11R7.0, el mismo código fuente separado en módulos independientes, cada uno mantenible en proyectos separados. ^{[ 56 ]} La Fundación publicó X11R7.1 el 22 de mayo de 2006, aproximadamente cuatro meses después de la versión 7.0, con mejoras de características considerables. ^{[ 57 ]}

El desarrollo de XFree86 continuó durante algunos años más, y la versión 4.8.0 se lanzó el 15 de diciembre de 2008. ^{[ 58 ]}

El sistema X Window utiliza una serie de términos con matices en comparación con el uso común, en particular "display" y "screen", un subconjunto de los cuales se ofrece aquí para mayor comodidad:

dispositivo

Un dispositivo gráfico, como por ejemplo una tarjeta gráfica de ordenador o el chipset gráfico integrado de la placa base de un ordenador.

monitor

Un dispositivo físico como un monitor CRT o una pantalla plana de ordenador.

pantalla

Área donde se pueden renderizar gráficos, ya sea mediante software en la memoria del sistema, como con VNC , o dentro de un dispositivo gráfico. Algunos dispositivos pueden renderizar en más de una pantalla simultáneamente, ya sea visualizándolas al mismo tiempo o de forma intercambiable. Las pantallas intercambiables suelen estar configuradas como una a la izquierda y otra a la derecha, alternando entre ellas cuando el puntero del ratón llega al borde del monitor.

pantalla virtual

Este término tiene dos significados diferentes:

• Una técnica que permite desplazar la pantalla del monitor por una pantalla que muestra una resolución mayor que la que muestra actualmente el monitor.
• Un efecto simulado por un gestor de ventanas mediante el mantenimiento de información sobre la posición de las ventanas en un sistema de coordenadas mayor que el de la pantalla, lo que permite el desplazamiento simplemente moviendo las ventanas en respuesta al usuario.

mostrar

Un conjunto de pantallas, a menudo con varios monitores, generalmente configurado para permitir que el ratón mueva el puntero a cualquier posición dentro de ellas. Las estaciones de trabajo basadas en Linux suelen tener capacidad para múltiples pantallas, entre las que el usuario puede alternar con una combinación de teclas especial como Control+Alt+ Tecla de función , cambiando simultáneamente la visualización de todos los monitores, desde las pantallas de un monitor hasta las de otro.

El término "pantalla" no debe confundirse con la jerga más especializada " pantalla Zaphod ". Esta última es una configuración poco común que permite que varios usuarios de un mismo ordenador dispongan cada uno de un conjunto independiente de pantalla, ratón y teclado, como si utilizaran ordenadores separados, pero a un menor coste por usuario.