Dada la buena respuesta que han tenido los últimos artículos conceptuales queremos continuar cubriendo algunos temas que son bastante conocidos a nivel de desarrolladores, pero poco manejados por el público general.

En esta ocasión hablaremos de un cambio realizado en Linux que a primera vista se ve poco relevante, pero que al examinar más a fondo abre nuevas oportunidades.  Se trata de Kernel Mode Setting o Configuración de Modo de Video en el Kernel.

Configurar un modo de video es una tarea que puede ser más compleja de lo que parece, sobre todo ahora que existen distintos tipos de salidas de video y hay que preocuparse de muchos más aspectos que de sólo un monitor.

En Linux el código que se encarga de configurar el modo de video se encuentra en varias partes, e incluso se puede apoyar en la BIOS para hacer este trabajo.  Pero esto provoca algunos inconvenientes:

• Algunas BIOS vienen con modos predefinidos que no se ajustan al hardware.  Sucede o sucedía con los primeros laptops que usaron modos widescreen pero cuyas BIOS sólo conocían los modos tradicionales.
• Qué tan correcto sea el manejo del modo de video y las salidas de video dependen exclusivamente de la implementación particular de la aplicación que necesita usar el video, por ejemplo X.org o el terminal en modo de texto.
• Cuando una aplicación configura el modo de video para trabajar en él, debe almacenar su estado y de alguna forma cederlo cuando otra aplicación necesita reconfigurar el modo de video.  Por ejemplo si estamos en una sesión gráfica en X.org y queremos pasar a una sesión de texto (Ctrl-Alt-F1), entonces X.org debe guardar el estado del video antes de que el terminal cambie a modo de texto.  Por otra parte el terminal de texto debe configurar el modo de video que necesita desde cero.  Cuando se vuelve a modo gráfico, se realiza el mismo proceso a la inversa: El terminal de texto guarda el estado, X.org reinicializa el video desde cero y luego restaura el estado que guardó previamente.

Todos al kernel

Con Kernel Mode Setting, la lógica de cambiar de modos de video se elimina de X.org y otras aplicaciones para implementarse únicamente en el kernel.  De esta forma hay sólo una implementación para esta funcionalidad común y todas las aplicaciones que necesiten cambiar de modo de video pueden pedir el servicio al kernel.  Por lo tanto desde el punto de vista de la calidad, ahora todas las aplicaciones compartirán la mejor implementación.

Antes, las aplicaciones no tenían cómo saber a qué modo de video se iba a cambiar, por lo tanto siempre el modo de video se reinicializaba.  Pero como ahora es el kernel quien se encarga de esta tarea, puede detectar que el modo de video que se está pidiendo es el mismo que ya se está usando, por lo que sólo bastará con limpiar la pantalla, sin necesidad de cambiar el modo de video.  Esto reduce al mínimo todos los pestañeos que un usuario de Linux está acostumbrado ver cuando se inicia el sistema.  Al mismo tiempo se asegura el correcto uso de las salidas de video adicionales como es el caso de un proyector o un monitor externo.

Otro cambio importante es que ahora el kernel puede configurar el mejor modo de video lo antes posible.  Por ejemplo, apenas se inicia el kernel, algo que toma un par de segundos, se puede iniciar el modo de video definitivo y desde ese momento en adelante nunca más cambiar, ni tampoco reinicializar.  Por lo tanto el splash de inicio, el gestor de login y el entorno de escritorio usarían todos la misma configuración de video y a ojos del usuario se verían sólo como imágenes de fondo que cambian.

El proceso de suspender el sistema y luego despertarlo se simplifica, ya que es el mismo kernel que está coordinando la suspensión y restauración quien tiene toda la información respecto al estado del video, lo que hace que el proceso entero sea más confiable y rápido como se muestra en el video que acompaña este artículo.

Nuevos horizontes

Ahora se podrán escribir nuevas aplicaciones que usen el video directamente, por ejemplo aplicaciones que funcionen en modo fullscreen y que necesiten su propia configuración.  A ojos del usuario, la aplicación se mantiene en el mismo ambiente, sin embargo se encuentra con una disponibilidad del 100% del hardware de video, sin ni siquiera un sistema de ventanas o un gestor de composición.  Estas nuevas aplicaciones podrían ser un salvapantallas, un juego, reproductor de videos, entornos gráficos livianos como Wayland, escritorios remotos, etc.

Aventurando un poco más la imaginación, se podrían tener transiciones al cambiar de una aplicación a otra, imaginen un cubo que gira como el de Compiz pero que actúa cuando se cambia a modo de texto, cuando se lanza una aplicación en modo fullscreen o cuando se cambia la sesión de usuario.

Distribuciones como Fedora ya incluyen Kernel Mode Setting pero su uso depende de la implementación de los drivers de video que se estén utilizando.  Otras distribuciones como Ubuntu lo integrarán en la siguiente versión.

Link : Artículos de Phoronix respecto a Kernel Mode Setting

En estas condiciones, lo ideal es contar con un controlador de código abierto que pueda ser extendido, corregido y mantenido tanto por el fabricante como por la comunidad, de tal forma que pueda ser integrado con la variedad de sistemas operativos existentes.  Un ejemplo de esto es el caso de compañías como Intel, quienes incluso desarrollan abiertamente controladores de productos que ni siquiera han aparecido en el mercado.

Y no se trata de que las compañías no quieran desarrollar los controlador de código abierto, sino que a veces simplemente no pueden.  No toda la tecnología es desarrollada por una misma compañía y en ocasiones ésta se licencia a terceros bajo estrictas condiciones de secretismo, es el caso de VIA y también en forma excepcional, el de los chips de video GMA 500 de Intel cuya tecnología fue adquirida a PowerVR.

En estos casos la única alternativa es desarrollar un controlador que se distribuya sin código fuente junto a lo necesario para que éste se integre con el sistema operativo, lo que se conoce como binary BLOB (binary large object).

En un mensaje enviado por Harald Welte de VIA, se pide a los desarrolladores del kernel que incorporen en él la porción de código abierto entregada por la compañía para posteriormente usar el controlador BLOB sobre esta base, indicando que éste controlador no se podrá distribuir como código abierto debido a las condiciones de licenciamiento con terceros.  Harald dice:

1. El controlador de VIA no podrá ser liberado como código abierto porque contiene código licenciado de terceros.
2. VIA apoyará a cualquier desarrollador de la comunidad que quiera trabajar en un controlador de código abierto para su tecnología.
3. VIA ha entregado toda la documentación necesaria para programar sus chips.  Sólo falta la documentación de pixel shaders que se agregará pronto.
4. VIA no tiene los recursos para escribir un nuevo controlador, especialmente considerando que los futuros productos tendrán un procesador diferente e incompatible.  Por lo tanto sus recursos están enfocados en que estos futuros productos funcionen bien.

Según Stephane Marchesin quien trabaja en Noveau, el controlador de código abierto para NVIDIA, la documentación provista por VIA es insuficiente para escribir un controlador que funcione bajo los estándares de hoy.

En el pasado, las condiciones de licenciamiento de tecnología de terceros eran absolutamente irrelevantes para el usuario final.  En la actualidad queda demostrado que tales decisiones pueden ser una traba para convivir en un mundo que ha ido cambiando rápidamente hacia una dirección en donde el trabajo colaborativo y la libertad de información son conductores del desarrollo tecnológico.

Aunque Intel también se vio afectado de forma similar con su GMA 500, tanto como para que sus drivers fueran considerados un desastre, han trabajado duro para que su propia tecnología sea un ciudadano de primer nivel en este nuevo orden mundial, incluso dictando el camino a seguir.

Link : VIA will not provide an open source Chrome 9 driver (Phoronix)

(cc) por Fr3d.org / Fred

Hace un tiempo atrás, como parte de una estrategia para ponerse al día con Intel y NVIDIA, ATI liberó especificaciones y ejemplos que permiten a la comunidad de código abierto implementar un driver para sus chips R6xx/R7xx en Linux.

Inicialmente los avances fueron lentos, pero gradualmente los desarrolladores han ido soltando la mano con el material entregado. Es sabido que para trabajar en un proyecto de este tipo no sólo se necesitan las ganas, sino que también hay que ser capaz de entender el diseño del hardware, la arquitectura de aceleración de video del sistema operativo, todo esto esto sazonado con dosis del lenguaje C a gusto.

Ahora el driver ha llegado a un estado en que puede mostrar más que sólo triángulos.  Existe un conjunto de pruebas unitarias que el driver debe pasar para medir su avance, y el driver actualmente pasa exitosamente 14 de 63 pruebas, mientras que 24 pruebas renderizan mal y las 25 restantes no renderizan o simplemente se caen. Para lo no entendidos, podemos comentar que se trata de un concepto similar a las pruebas ACID que se realizan sobre los navegadores para medir su cumplimiento de estándares.

Se espera que las piezas que integran el kernel con este driver estén listas para el próximo release 2.6.31, por lo tanto dentro de unos pocos meses este driver podrá estar disponible para ser usado por el público general.

Link : 3D support for ATI 6xx/7xx update (blog de John Bridgman)

Hace pocos días, Zhenyu Wang de Intel agregó el soporte en Linux para un nuevo procesador gráfico de Intel, que ni siquiera tiene nombre aún.  En el mensaje que se debe registrar para cualquier cambio que se realiza en los repositorios que mantienen en el código se puede leer:

Se agrega versión Desktop y Móvil de nuevos chipsets.  Además realiza configuración de memoria como los chipsets de la serie 4 de Intel.

En el código incluso se ven los identificadores que tendrán los nuevos dispositivos para que el sistema operativo los pueda detectar (PCI ID).

En los cambios agregados se puede ver la inclusión de nuevos registros que son usados para comunicarse con el hardware y la deshabilitación de la extensión Composite.  Esto se realiza para que no se activen los efectos de escritorio mientras no se asegure que el sistema funciona correctamente, se espera que de aquí a que el producto sea anunciado y llegue a los usuarios pasará el tiempo suficiente para que se asegure este soporte.

En el código de estos nuevos dispositivos se puede ver que les llaman IGDNG que según el sitio Phoronix podría tratarse de “Intel Graphics Device Next Generation”.  Más que eso no hay muchos detalles, pero es bueno ver que el soporte para el hardware se está agregando en Linux incluso antes de que los productos sean anunciados oficialmente como es este caso, o al menos antes de que esté disponible para el público en general.  Intel está marcando pauta en este sentido.

Link : Intel releases support for new, unreleased IGP (phoronix.com)

(cc) Ruth Bourne

Intel ha estado desarrollando activamente muchos cambios para mejorar el sistema gráfico de Linux, aplicando numerosas mejoras no sólo en su driver sino que a nivel de toda la infraestructura, incluyendo el kernel.

Con estos cambios, tanto el rendimiento, el uso de recursos y la experiencia del usuario se verán beneficiados a medida que los otros drivers comienzan a usar los nuevos componentes que Intel ha integrado en el sistema, como es el caso de Graphics Execution Manager (GEM), Kernel Mode Setting (KMS) y UMA Acceleration Architecture (UXA) que es la arquitectura de aceleración basada en GEM que viene a reemplazar al reciente EXA y al ya añejo XAA.

Hace un par de semanas Intel liberó la versión 2.7 de su driver xf86-video-intel, pero ya hay una nueva versión de prueba en miras a convertirse en la versión 2.8.  Normalmente, esto toma dos a tres meses, pero esta vez decidieron aplicar cambios rápidamente, y cortar por lo sano, literalmente.

Intel ha eliminado completamente el soporte de EXA en favor de la nueva arquitectura de aceleración UXA.  Por si esto no fuera poco, además han eliminado Direct Rendering Infrastructure 1 (DRI1), funcionalidad que es el soporte fundamental para la aceleración por hardware y que ya muestra sus años.

Esto quiere decir que todo lo que consideramos como estable, probado y conocido ha sido eliminado para enfocar los esfuerzos hacia la nueva arquitectura y de paso forzar su uso y estabilización.  Por lo tanto, para usar aceleración por hardware 2D, ahora sólo está disponible UXA que lamentablemente aun no está libre de bugs.  Los usuarios que han habilitado UXA dicen que el sistema es bastante más rápido que lo que se haya conocido antes en Linux, pero hay problemas de estabilidad y rendering que no han sido resueltos.  Ya hace poco les contamos que en el recién liberado Ubuntu 9.04, se prefirió mantener EXA configurado por omisión.

Como este driver se demorará un tiempo en llegar a las distribuciones, se espera que los usuarios avanzados lo instalen y reporten los bugs encontrados en UXA antes de que llegue al usuario común y corriente.

Eliminar código antiguo es una estrategia que ha resultado bastante bien para tener menos código que mantener, centralizar esfuerzos en lo que realmente vale la pena y en el fondo eliminar lastre para tener una base sencilla, sólida y limpia.

Link : Intel releases new driver, kills EXA/DRI1 (phoronix.com)

Andrew Morton y Keith Packard (cc) by Linux Foundation

Y seguimos con noticias desde Linux Collaboration Summit en San Francisco.  En esta ocasión los muchachos de Ars Technica nos cuentan que hubo un interesante panel acerca del desarrollo del kernel de Linux en donde participaron destacados hackers.  Entre los temas que se tocaron estuvieron los sistemas de archivo, la arquitectura gráfica, y el rol de “la porquería” en el desarrollo del kernel.  Así es, hablaremos de “la porquería” (the crap(tm))

El panel del kernel fue una de las discusiones más técnicas que se llevaron a cabo en el evento.  Este panel fue moderado por Jonathan Corbet, editor del prestigioso medio LWN.net .  Los convocados fueron :

• Andrew Morton : uno de los principales desarrolladores del kernel de Linux. Tiene su propia rama en donde se prueban cambios que posteriomente entran a la rama de Linus Torvalds.  Andrew fue contratado por Google en el año 2006 para dedicarse por completo al desarrollo del kernel.
• Greg Kroah-Hartman : encargado del soporte de USB y creador de udev entre otros.  Trabaja a tiempo completo para Novell en el Linux Driver Project, una iniciativa para implementar drivers de código abierto con la cooperación de los fabricantes de hardware.  Greg es el fundador de este proyecto que hoy tiene más de 200 desarrolladores.
• Theodore Ts’o (Ted) : Es el desarrollador conocido por colaborar en el área de sistemas de archivo en Linux. Es el principal culpable del veloz ext4. Trabaja bajo el alero de Linux Foundation y tiene planes de volver a IBM a fines de año.
• Keith Packard : es el hombre responsable de las impresionantes mejoras que se han realizado en el sistema gráfico de Linux en la última década.  Aceleración por hardware, escritorios 3D, alpha blending, etc.  Trabaja en X Window desde la década de los 80.  Inició revolución gráfica mientras trabajaba para HP Labs y actualmente se encuentra en las filas de Intel.

La porquería

Kroah-Hartman discutió acerca de un área especial del kernel que se incluyó en la versión 2.6.28 para mantener en forma separada un conjunto de componentes y drivers del kernel que estuvieran incompletos o inestables.  La comunidad del kernel le llamó “la porquería”.

Esta área ayuda a que estos componentes sin terminar sean mas visibles y así atraigan el interés de otros desarrolladores para completarlos y llevarlos a un nivel de madurez suficiente para su uso normal.  La gran cantidad de mejoras que se hicieron a la porquería en la versión 2.6.30 demuestra que esta definición efectivamente ha servido para su propósito original.

El kernel y su influencia en el área gráfica

Keith Packard describió algunos cambios que se han realizado a la arquitectura gráica de Linux.  Hay componentes que se han sacado desde lo que se conoce como userspace y se han incluido como parte del kernel.  Aqui encontramos la arquitectura de aceleración (UXA), la configuración de los modos de video (KMS) y la administración de memoria (GEM).

Estos cambios han reducido las barreras para crear nuevos tipos de sistemas gráficos para la plataforma Linux, incluso ya han surgido algunos experimentos interesantes como es Wayland.

Packard explicó que los drivers gráficos son extremadamente complejos y que construirlos requiere un gran compromiso de tiempo, recursos y dedicación de los fabricantes.  Intel ha hecho una inversión significativa en la arquitectura gráfica para mejorar la compatibilidad de Linux con el hardware de Intel.  Por otra parte dice que ATI ha comenzado a tomar un rol activo permitiendo que la comunidad de soporte a sus chips.  Nvidia aun no ha llegado a este nivel de compromiso.

Ext4 : un refrito de tecnología de los ‘70

Ted Ts’o habló sobre ext4 y cómo ha sido bien recibido por las distribuciones como Ubuntu y Fedora que lo incluyen como opción de instalación.  Se espera que pronto ext3 deje de ser el sistema de archivos por omisión en las distribuciones más populares.

Aunque ext4 agrega interesantes características, Ts’o no lo ve como un gran avance.  Incluso le baja el perfil a ext4 calificándolo como un refrito de tecnología de los ‘70 y lo describe como una solución de corto plazo mas bien conservadora.  Cree que el camino a seguir es Btrfs, el sistema de archivo que viene de las manos de Oracle en donde si hay mejoras significativas respecto a escalabilidad, confiabilidad y facilidad de administración.

Al concluir el panel, Linux Foundation entregó por primera vez el premio del héroe anónimo (Unsung Hero) a Andrew Morton por su rol como mantenedor de la rama mm del kernel.

Link : Panelists ponder the kernel at Linux Collaboration Summit (Ars Technica)

Cuando Ubuntu 9.04 esta próximo a llegar a su fecha de lanzamiento, Canonical dice que no habilitará por omisión la nueva arquitectura de aceleración de video UXA de Intel, dado que a pesar de mostrar notables mejoras en el rendimiento, no se encuentra suficientemente estable para ser usado por todo el mundo.

UXA (UMA Acceleration Architecture) es responsable de la aceleración 2D del sistema gráfico de Linux y se encarga de traspasar al hardware las operaciones típicas 2D de un escritorio moderno como son bitblt, rectangulos, alpha blending, etc.  Hoy en día esta responsabilidad cae en EXA Acceleration Architecture, antepasado directo e inspirador de UXA.  EXA tiene un diseño reciente pero comparado con UXA, no considera las mejoras respecto a gestión de memoria realizadas últimamente en el kernel mediante GEM (Graphics Excecution Manager).

En los benchmarks que se han realizado para comparar UXA con EXA se ha detectado que UXA es notablemente más rápido, incluso se han detectado mejoras en más de un 50% del rendimiento para algunas tareas, pero en su estado actual varios usuarios han reportado problemas de estabilidad con corrupción, caídas y bloqueos del servidor gráfico, entre otros.

Bryce Harrington, el ingeniero lider de X.org en Canonical, ha decidido que las mejoras en rendimiento no compensan los bugs que se presentan y por lo tanto no habilitarán UXA por omisión en Ubuntu 9.04.  De todas formas, a este ritmo se espera que UXA se encuentre suficientemente estable en 6 meses más cuando salga Ubuntu 9.10. Considerando que Ubuntu 9.10 incluirá el kernel 2.6.29 ya se convierte en un release que provoca grandes expectativas.

Aquellos amantes de la velocidad que no le teman a la inestabilidad, pueden probar como se comporta UXA con sus chips de video Intel, habilitándolo con las instrucciones de UxaTesting en el wiki de Ubuntu.

Links:
- Canonical not to enable UXA, too problematic (Phoronix)
- Intel UXA Acceleration performance (Phoronix)
- Lo nuevo en X Server 1.6 (FayerWayer)
- Ubuntu 9.04 no incluirá el kernel 2.6.29 (FayerWayer)

Al reducir la base de código, los desarrolladores del driver de ATI podrán enfocarse sólo en los nuevos productos sin tener que preocuparse de las antiguas arquitecturas, así tendrán menos código que mantener y podrán adaptar rápidamente el driver para los avances que se realizan en Linux, abriendo la posibilidad de mejorar la situación actual en donde NVIDIA e Intel le llevan la delantera.

Este cambio sucede pocos días después que se eliminara el driver Catalyst de los repositorios de Arch Linux, ya que estaba dando más problemas que soluciones. Irónicamente, en esa oportunidad los mantenedores de la distribución se quejaron de lo poco y nada que hacía AMD para remediar esta situación.

Y el asunto se pone más interesante al considerar que AMD tiene una estrategia para el soporte de su hardware por parte de la comunidad y sus drivers de código abierto.   Mientras AMD se enfoca en mantener un driver para R600/700 que pueda seguir el ritmo de Linux y al mismo tiempo sacar el provecho máximo del hardware, entrega lo necesario para que se puedan escribir drivers de código abierto en forma paralela, de paso dando soporte a las arquitecturas que ya no estará soportadas por Catalyst.

Desde la adquisición de AMD la relación entre ATI y los desarrolladores de drivers de código abierto ha ido mejorando de forma progresiva.  Hoy en día lo necesario para desarrollar estos drivers ha sido entregado tanto en forma de código como de especificaciones, lo que falta ahora son suficientes desarrolladores.  Hace poco uno de ellos fue afectado por los despidos en Novell, y tareas de esta complejidad necesitan perfiles muy específicos que no se pueden encontrar fácilmente.

Aun así el soporte 2D de los drivers de código abierto ha tenido avances importantes, como es la inclusión oficial de la arquitectura de aceleración EXA y el soporte de X-Video, pero el soporte de la aceleración 3D puede ser un largo camino a recorrer.

Update: AMD confirma que el último driver Catalyst que soporta la serie R300/400/500 no será compatible con X Server 1.6, por lo tanto no se podrá utilizar en las distribuciones que lo incluirán como Ubuntu 9.04 y Fedora 11.

Links:

- AMD Dropping R300-R500 support in Catalyst Driver (phoronix.com)
- AMD’s legacy driver will not support X Server 1.6 (phronix.com)

Intel quería que este release se hiciera al finalizar el año 2008, pero por todos los cambios que se necesitaban en otros componentes como es el caso del kernel de Linux, se tuvo que aplazar la fecha final y además se tuvieron que eliminar algunas características y dejarlas para el próximo release 1.7.

Todos los drivers de código abierto exitentes y el driver de NVIDIA son compatibles con esta versión 1.6, incluso algunos drivers antiguos como los del mítico chip Voodoo han sido actualizados.  Los que se quedarán atras por el momento son los usuarios de AMD/ATI.

X Server 1.6 incluye los siguientes avances:

• Direct Rendering Infraestructure 2 (DRI2) : Es una mejora a nivel de arquitectura respecto a DRI (actual). Distribuye la funcionalidad actual de DRI en otros componentes que han sido potenciados últimamente, incluyendo el uso de los nuevos gestores de memoria como Graphics Execution Manager (GEM).   DRI2 ya estaba disponible en Mesa y el driver de Intel, sólo faltaban los cambios en X Server.  Una de las mejoras que se destaca es que ahora se puede renderizar directamente via hardware en ventanas que estan operadas por un compositor como Compiz.
• X Input 1.5 : Incluye métodos para compartir información acerca de los dispositivos de entrada conectados entre drivers, aplicaciones y X Server.  En palabras sencillas mejora el “plug & play” de dispositivos como touchpad, mouse y teclados. Esta funcionalidad es parte de X Input 2.0 pero se traspasó (backport) a la versión 1.5 para que fuera liberada lo antes posible.
• Predictable Pointer Acceleration : es una mejora para que el usuario tenga mejor control de dispositivos de punteros como es el caso del mouse.  Segun dicen, muchos usuarios no notarán el cambio, pero para otros puede ser una experiencia bastante diferente a lo que existe hoy.
• RandR 1.3 : Resize and Rotate es la extensión que permite rotar la pantalla, o cambiar su tamaño “al vuelo”.  En esta versión se mejora el manejo de multiples salidas y algunas gracias como hacer panning entre varios displays.

Otros cambios son correcciones y mejoras a EXA, la arquitectura de aceleración optimizada para Render, una de las extensiones más utilizadas en las interfaces de usuario actuales.

Los cambios que deben esperar

Varias características interesantes quedaron fuera, pero se espera que se integren al release 1.7 y se puedan disfrutar oficialmente a fines de este año al integrarse junto a X.Org 7.5 en distribuciones como Ubuntu 9.04 y Fedora 11.

• X Input 2 / Multi Pointer X :  permite manejar varios punteros en forma simultánea en X, es la base de lo que se necesita para manejar pantallas multitouch.  Este trabajo comenzó hace unos 4 años pero no se ha integrado oficialmente, a pesar de que se hicieron bastante populares las demos de MPX en YouTube.
• UMA Acceleration Architecture (UXA): Se trata de una arquitectura de aceleración construida a partir de EXA pero que incluye el uso de los nuevos gestores de memoria como GEM (Graphics Excecution Manager).  Tanto UXA como EXA y GEM son tecnologías desarrolladas por Intel pero que cualquier fabricante puede (y debería) usar.

Los que nos dicen adiós ¡Hasta siempre!

Son varios los componentes de X Server que fueron eliminados a partir de esta versión porque están obsoletos, rotos, sin uso o sin nadie que los mantenga.

No seguirán con nosotros :

• Xgl : es la variante de X en donde se inició el desarrollo de Compiz y que significó por primera vez tener una plataforma completa y usable para usar las funciones de aceleración 3D del hardware.
• Xprt : era un X server que en vez de desplegar las aplicaciones en pantalla, lo hacía en un medio impreso.  Ya no tiene mucho sentido considerando que las aplicaciones pueden renderizar en su propio espacio con capacidades de WYSIWYG.
• xorgconfig y xorgxfg : utilidades que ayudaban a crear el archivo de configuración xorg.conf.  Ya no son tan necesarias debido a todo el progreso respecto a la autodetección del hardware.
• XFree86-Misc y XEvIE : Sus funciones estan cubiertas de mejor forma en X Input.

Link: X Server 1.6.0 has been released (Phoronix)

Hace poco, muchos sitios especializados hicieron eco de la noticia sobre el desarrollo de un nuevo sistema X para Linux llamado Wayland, y como ya había sucedido en otras ocasiones, se escucharon muchas voces acerca de lo innecesariamente grande y complejo del sistema existente (X.org).  La noticia era bienvenida, pero no había mucha información acerca de qué se trataba exactamente.

Un poco de historia

X Window System (o simplemente X) es el componente del sistema que se encarga fundamentalmente de dos tareas : desplegar las aplicaciones en pantalla y recibir los eventos del usuario (teclado, mouse, etc).  X no es una aplicación en particular, sino que es una específicación que puede tener múltiples implementaciones, su origen data de mediados de los años 80 y se creó inicialmente con la idea de tener una interfaz gráfica para los sistemas Unix, sin embargo su diseño es independiente de la plataforma y gracias a eso es que hoy tenemos implementaciones de X para Windows, Linux, OSX, Unix’es, etc.

Cuando se diseñó X, el hardware era bastante diferente a lo que usamos hoy en día.  En esos años los chips de aceleración de video no era algo que estaba al alcance de cualquier mortal y el uso de servidores compartidos era algo común, la computación personal era un sueño de pocos.  Para usar los sistemas Unix se acostumbraba a conectar a muchos usuarios mediante terminales de texto y X agregaba capacidades gráficas a esta interacción.  Una de las características naturales de X es poder desplegar en un sistema las aplicaciones que se están ejecutando en otro, actuando en forma remota.

Hoy en día no es necesario compartir los computadores y cada usuario puede tener uno completamente dedicado a él, tanto las aplicaciones como el servidor X corren en la misma máquina en forma local, el uso remoto es opcional.  Por otra parte el hardware de video ya no sólo despliega un conjunto de pixeles, sino que cuenta con procesadores dedicados a generar imágenes en espacios 2D y 3D.

En el caso de Linux la implementación de X más utilizada es X.org, ésta surgió cuando un grupo de desarrolladores de XFree86 se separó del proyecto porque consideraban que existían muchas restricciones para hacer fuertes cambios en X. Esto ocurió en el año 2004 cuando un cambio a un licenciamiento más restrictivo fue la gota que rebalsó el vaso.

Los cambios que se han realizado en X han sido considerables.  Por muchos años se puede decir que los cambios se limitaban a agregar drivers, pero el resto de las ideas originales se mantenían a pesar de los avances en el hardware gráfico, especialmente a finales de los 90.  Cuando surgió X.org, héroes como Keith Packard y Jim Gettys pudieron llevar adelante los cambios que se necesitaban para convertir a X en un sistema moderno.

Keith Packard y su pandilla

Uno de los cambios fuertes fue cambiar algunos aspectos del despliegue para que los pudiera realizar la aplicación y no el servidor X, es el caso del sistema de fonts.  Con eso lograron crear interfaces WYSIWYG, suavizado de fuentes, mejoras sustanciales en el rendimiento y capacidad de usar la aceleracón por hardware a la hora de desplegar texto.  La base de este cambio (xrender) también permitió mejorar la forma en que se manejan los dibujos vectoriales, dando capacidad de usar alpha blending, antialias y todo acelerado por hardware.

Otro de los cambios fuertes es el modelo de composición.  En pocas palabras se trata de una nueva forma de desplegar las ventanas para que no exista el redibujado y una aplicacion independiente se encarga de presentar todas las ventanas en la pantalla, se conoce como Composite Manager y su implementación más conocida es Compiz (+derivados).  Gracias al nuevo modelo de composición se pueden aprovechar las capacidades 3D de los procesadores modernos, que son increiblemente poderosos para las necesidades de un sistema de escritorio.

Cambios recientes en X

Recientemente se agregaron un par de cambios que permitieron mejorar dos aspectos que siempre fueron criticados en X.  Uno de ellos es que ahora X ya no se encarga de configurar el modo de video, sino que lo hace en el kernel, esta funcionalidad se le llamó ingeniosamente Kernel Mode Setting (KMS).  Los beneficios directos de este cambio son al menos dos : ya no es necesario que X se ejecute con privilegios de root, lo que siempre es un riesgo de seguridad, y el otro es que otras aplicaciones pueden solicitar un cambio en el modo de video, esto significa por ejemplo que si hay dos X server corriendo al mismo tiempo antes se tenia que “apagar y encender”  el X server para cambiar de uno a otro, en cambio ahora el kernel podría simplemente cambiar el contexto entre uno y otro, sin reiniciar el video ni causar esos molestos pestañazos.  Otra ventaja es que otras aplicaciones de despliegue podrian pedir al kernel el control del video sin pasar por X, por ejemplo un screensaver o una aplicación dedicada a la reproducción de videos en pantalla completa.

El otro cambio es relativo al manejo de memoria de las aplicaciones que usan el servidor X.  Se implementó un sistema centralizado en donde las aplicaciones pueden incluso compartir objetos gráficos.  Este sistema se conoce como Grapics Excecution Manager (GEM). ¿En donde interesa? justamente un Composite Manager es uno de los que necesita este tipo de funcionalidad.  En pruebas realizadas con hardware antiguo (i915) se produjo un incremento de más de un 50% en el performance al probar aplicaciones 3D.

Wayland entra a jugar

Con todos estos cambios, X.org se ha convertido en un sistema que cada dia se aleja más de lo que se diseño originalmente en los 80.  El problema es que por motivos de compatibilidad, y para poder ser un X con todas las de la ley, tiene que mantener una gran cantidad de funcionalidad que ya no es relevante.  Se sabe que se han eliminado algunas características obsoletas y según dicen, nadie se ha quejado, pero no se puede hacer una limpieza total porque se desconoce cuantos usuarios podrían salir afectados.

Kristian Høgsberg, un empleado de RedHat, ha comenzado a trabajar en un proyecto por su cuenta para crear un nuevo sistema gráfico llamado Wayland. Kristian ha desarrollado tanto en X.org como en el kernel así que conoce bien lo bueno y lo malo de cada uno de ellos.

Lo primero que se debe decir de Wayland es que no se trata de un X server como erróneamente lo titularon varios sitios.  Wayland busca aprovechar todas las características que ya no son parte de X para crear un nuevo sistema de despliegue con un diseño actual, este aspecto es bastante importante porque una de las limitaciones que existían hasta hace poco era que para hacer un nuevo sistema de despliegue (X u otro) se necesitaba implementar una gran cantidad de funcionalidad.

Wayland en vez de partir de cero, tiene como base todo lo que se eliminó de X para integrarse al kernel y bibliotecas externas.  No es una duplicación de trabajo, es una comienzo limpio sobre una base sólida.

Como Wayland no es un X, las aplicaciones existentes no pueden funcionar directamente en él, pero es algo que se puede solucionar ya que al usar toolkits como QT y GTK que son independientes de X, en teoría sería cosa de que hicieran los ports respectivos a Wayland.   Otra alternativa es que se ejecute un servidor X rootless sobre Wayland, y así las aplicaciones no se darían cuenta que es otro quien dibuja sobre la pantalla, es el mismo sistema que utiliza OSX en la actualidad para desplegar apicaciones que usen X.

En diciembre del 2008, Kristian ya tenía andando X.org sobre Wayland.

Wayland propone que el Composite Manager sea independiente del sistema de despliegue como es en X, pero que sea parte del mismo proceso.  Si se mezcla esta idea con la anterior de usar un X sobre Wayland, sería posible hacer transiciones de usuarios como las que hace OSX mediente este Composite Manager integrado.

Hasta ahora Wayland es un prototipo experimental muy pequeño, no tiene fines muy ambiciosos y no hay seguridad sobre su futuro, pero sin embargo puede ser un cambio radical en el área de interfaz gráfica.  Linux en un comienzo estaba en las mismas condiciones y ya sabemos lo que pasó.

Los valientes que quieran contarle a sus nietos que probaron este sistema cuando comenzó, pueden descargar, compilar y probarlo desde su repositorio oficial.

Links:

- Grupo de discusión sobre Wayland (groups.google.com)
- Preguntas frecuentes sobre Wayland (groups.google.com)
- Blog de Kristian Høgsberg (hoegsberg.blogspot.com)
- New Wayland X server looks to how a modern desktop works (Heise Online)

Respecto al hardware, las series 6 de NVIDIA GeForce incluyen una característica llamada PureVideo que se encarga del soporte de decodificación y presentación de videos a través del procesador gráfico (GPU).  Mientras que en Windows se utiliza PureVideo mediante DirectX Video Acceleration API (DxVA), en Linux se podía utilizar esta característica sólo en forma limitada.

NVIDIA viene a cambiar esta situación con el desarrollo de una API equivalente a DxVA para el mundo Unix llamada VDPAU : Video Decoding and Presentation API for Unix (API para decodificación y presentación para video).  Antes de explicar de que se trata, repasemos cuales son los sistemas actuales de aceleración de la reproducción de videos en Linux:

• Sin aceleración : la CPU se encarga de realizar todos los cálculos de decodificación de video.  Posteriormente cada frame decodificado debe ser copiado a Video RAM aplicando otros cálculos adicionales para llegar al tamaño que se quiere desplegar, ya sea agregando o eliminando pixeles.  Mientras más grande es el video original o el area de despliegue, peor es el rendimiento del sistema completo.  Si la ventana del video es cubierta por otras ventanas, la CPU tiene que hacer los cálculos necesarios para copiar sólo los bloques visibles. Independiente de la velocidad del computador, es un método bastante lento.
• X-Video (xv) : La CPU se encarga de realizar todos los cálculos de la decodificación del video, pero es la GPU quien se encarga de escalar y mostrar el video en pantalla, por lo tanto el tamaño del video es irrelevante para el rendimiento.  Originalmente se utilizaba la técnica del Chorma Key, es decir, se pinta un fondo azul y la GPU reemplaza todos esos píxeles por la imagen del vídeo, no es necesario hacer ningún cálculo relacionado con ventanas que tapan areas del video.  Cuando surgen los sistemas de despliegue basados en composición (Compiz y sus efectos 3D) se elimina el uso de Chroma Key y el video se renderiza como si fuera una textura en un polígono, aprovechando toda la capacidad de las GPU con aceleración 3D.
• X-Video Motion Compensation (XvMC) :  La GPU se hace cargo de algunas tareas de la decodificación de video, especificamente dos importantes tareas de la decodificación de MPEG-2, el codec que se usa en los DVD’s y en sistemas de televisión digital.  El hardware de NVIDIA sólo soporta XvMC con su driver propietario hasta las series 7 de GeForce mientras que ATI lo soporta sólo en forma experimental.  VIA agrega una tercera tarea de decodificación y además soporta MPEG-4 (ASP) y H.264.  Intel lo soporta completamente en sus series 8xx/9xx y dice que está trabajando en el soporte de más codecs.

VDPAU : Video Decode and Presentation API for Unix

NVIDIA no siguió con el soporte de aceleración a través de XvMC y no es que abandone el barco, sino que se dedicaron a desarrollar un nuevo esquema de aceleración que oficialmente soporte más tareas de decodificación en la GPU y que además soporte una gran cantidad de codecs.

A partir de la versión 180.06 de su driver propietario, NVIDIA comenzó el soporte de VDPAU en la series 8 de GeForce y posteriores (las anteriores tienen XvMC).  Los codecs que pueden ser acelerados son MPEG-1, MPEG-2 (DVD), MPEG-4 (H.264), VC-1 (HD DVD/BlueRay) y WMV3/WMV9.

La mejora en el rendimiento de la reproducción de videos puede ser impresionante.   En pruebas de VDPAU realizadas con hardware barato (CPU: USD$20 + GPU: USD$30) se pueden apreciar mejoras del rendimiento en la decodificación de videos HD que van desde una relación 1:2 a casos extremos con una relación 1:9.

NVIDIA además ha ayudado a desarrollar los parches para que las aplicaciones de video en Linux puedan usar VDPAU, específicamente hay soporte en MythTV, FFmpeg, MPlayer, VLC y Xine a través de parches.

Intel por su parte estaba tratando de mejorar XvMC a través de una API funcionalmente equivalente a VDPAU pero llamada simplemente Video Acceleration API (VA-API), sin embargo no ha tenido un impulso tan grande como el que esta dando NVIDIA a su tecnología.  No sólo no hay mucho código disponible, sino que el único driver de Intel que soporta VA-API es para una familia de chips que fue adquirida a PowerVR, por lo tanto es diferente a todo lo existente para sus chips más conocidos.  Este hardware conocido como Poulsbo (GMA 500) se encuentra presente en dispositivos MID’s y netbooks, sus drivers tienen componentes privativos y han sido duramente criticados por su deficiente calidad.

Afortunadamente Intel ha declarado que está considerando a VDPAU para sus drivers de X.org, y si esto sucede, se espera que ATI también se una a esta iniciativa.

Links:
- NVIDIA Driver brings PureVideo features to Linux (phoronix.org)
- Intel considering VDPAU for X.org driver (phoronix.org)
- HD Video playback with a $20 CPU & $30 GPU on Linux (phoronix.org)