El driver nv fue una iniciativa de NVIDIA para proveer de drivers de código abierto al sistema operativo Linux hace más de una década.  Como una forma de proteger su propiedad intelectual, implementaron un subconjunto mínimo de operaciones con un código escrito para ser difícil de entender.

En paralelo NVIDIA tiene un driver con funcionalidad completa que comparte una base común con el driver de otros sistemas operativos, y le hace pequeños cambios para adaptarlo a las diferencias propias de cada sistema.  Lo que buscan con detener el desarrollo de su driver de código abierto es enfocar los esfuerzos en el driver de código cerrado, de una forma similar a lo que está haciendo ATI con su driver Catalyst.

Aunque en principio esta noticia parece ser negativa, lo cierto es que el driver de código abierto de NVIDIA cada vez tenía menos sentido, ya que el sistema gráfico ha cambiado radicalmente y la comunidad ha desarrollado el driver Nouveau que hace tiempo dejó atrás al driver nv.

A pesar del impresionante avance de Nouveau con todas las dificultades que tiene no contar con documentación oficial de cómo funciona el hardware, NVIDIA no piensa entregar ningún tipo de ayuda, actitud que lo diferencia de su competido ATI quien ya entregó una buena dosis de documentación, entrega que pronto dará sus frutos a los sufridos usuarios de ATI en Linux.

Aunque Nouveau ya fue integrado al kernel y las distribuciones lo están usando en forma natural, NVIDIA prefiere recomendar el uso del driver VESA, se trata de un driver genérico que no usa aceleración pero asegura un funcionamiento mínimo del sistema gráfico:

Las necesidades de rendering de un sistema de escritorio moderno con X Window han cambiado drásticamente en los últimos años apoyándose fuertemente en la extensión X Render, que no está acelerada en el driver nv.  En este punto, en un escritorio moderno, el driver nv no ofrece mucho más allá de lo que provee el driver VESA.  Proveer aceleración de Render en el driver nv es una tarea sustancial, y requeriría desviar significativos recursos del driver cerrado de NVIDIA.

Link: Deprecation of xf86-video-nv (lista de correo de X.org)

El hecho no pasó desapercibido entre los participantes de las listas de correo de X.org y originó un hilo de discusión para tratar de entender qué pasó exactamente y por qué no se había intentado hacer algo por recuperar el dinero.  Para sorpresa de muchos, este tipo de “quitada” de dinero no es algo nuevo en PayPal.

Lo que sucedió exactamente fue que X.org Foundation tenía US$5.000 en PayPal para cancelar parte de los costos de X Developers’ Summit 2007, y PayPal cerró la cuenta por considerarlos como sospechosos de ser scammers.  En estos casos, PayPal actúa en forma totalmente arbitraria, ya que de acuerdo a los términos de uso del servicio PayPal, la compañía decide por sí misma si toma o no el dinero de la cuenta.   En este caso, PayPal simplemente dijo que X.org era sospechoso de fraude y tomó todo el dinero.

Inocentemente los miembros europeos de X.org Foundation preguntaron por qué no se inició una acción legal para recuperar el dinero, pero como la fundación tiene base legal en Estados Unidos, iniciar un juicio contra PayPal por “sólo” USD$5.000 es perder el tiempo, sobre todo considerando que una compañía tan grande y probablemente acostumbrada a juicios de este tipo tiene abogados con mucha experiencia para ganar estos casos.

Daniel Stone también indicó que en la organización de la misma conferencia se perdieron otros US$5.000 en el sistema bancario braslieño, cuando se estaban cancelando los costos para traer a dos desarrolladores de ese país.

Pese a esta pérdida total de US$10.000, la fundación aún cuenta con fondos para unos tres años más, incluso tomando en cuenta de que este año no se hicieron esfuerzos para recolectar dinero debido a la crisis económica.

Otros afectados por PayPal

Lo ocurrido con X.org no es un caso aislado y existe un sitio web llamado PayPal Sucks creado por usuarios que iniciaron un juicio colectivo el año 2004 contra PayPal por abusos del mismo tipo.  Si bien se llegó a un acuerdo, como es usual en este tipo de acción legal, fueron tantos los afectados que cada uno recibió una proporción minúscula del total que PayPal acordó pagar.

En PayPal Sucks se pueden encontrar historias de horror de personas o negocios pequeños a quienes PayPal les quitó su dinero sabiendo que el costo de recuperarlo era mucho mayor que el dinero ya perdido.  En el sitio también se incluye información sobre las condiciones legales que dejan al usuario totalmente indefenso ante estas acciones.

En general lo que se puede ver es que dejar la cuenta PayPal con saldo positivo es un riesgo.  Otro modus operandi de PayPal es quitarle el dinero a los que venden utilizando el servicio como medio de pago, favoreciendo siempre al comprador cuando se produce una situación dudosa.  En estos casos el vendedor no tiene como defenderse de usuarios abusivos que piden su dinero de vuelta y PayPal simplemente le quita el dinero al vendedor, no sólo el que corresponde a la venta sino que también puede congelar la cuenta si lo desea y quitarle todo el dinero como lo hizo con X.org Foundation.

Obtener respuesta con PayPal es otra odisea según lo relatan los usuarios afectados, ya que hasta hace poco sólo se podía establecer una comunicación por internet con PayPal y se recibía una respuesta genérica para nunca más volver a saber de ellos.  Hace poco y gracias a un cambio en la legislación norteamericana, se logró que PayPal entregara otros medios de contacto como el teléfono y su dirección física.

Actualización : Germán Póo de GNOME Foundation me indica que Google Checkout es una opción más confiable.  Para organizaciones como X.org y GNOME Foundation su uso no tiene costo.

Link: Board voting ends today, but… (Mensaje de Daniel Stone en lista de correo de X.org Foundation)

Hace un tiempo les contamos que VIA no tenía ninguna intención de cooperar con el código abierto, y había dado tímidos pasos liberando parte de la documentación necesaria para que la comunidad escribiera los drivers.  Y esta vez no se puede celebrar mucho, ya que la documentación liberada en esta ocasión es bienvenida, sólo tiene el “pequeño inconveniente” de venir con varios meses de retraso.

Los documentos fueron liberados este 12 de Enero, pero tienen fecha de publicación a mediados del 2009, y se sospecha que durante estos meses estuvieron en manos de los desarrolladores de openChrome, pero no los podían utilizar sino hasta que VIA resolviera los posibles conflictos legales de liberar esta información a toda la comunidad.

Los documentos fueron liberados bajo Creative Commons y contienen información de referencia sobre los puertos y comandos con los que se programan estos chips.  La información si bien es detallada,  dista mucho de ser un manual de programación.  Si recién llega a las manos de los desarrolladores de openChrome, tomará un tiempo antes de que se aplique el nuevo conocimiento en estos drivers de código abierto.

Link: VIA Releases new documentation, bit it’s old (Phoronix)

El soporte de multitouch se había implementado desde hace bastante tiempo en Linux, pero no había sido integrado de una forma que cualquier persona lo pudiera usar.  Por ejemplo, se pueden encontrar videos de multitouch corriendo sobre Linux desde hace más de dos años, pero se trata de desarrollos específicos y no de un componente que pueda ser utilizado por todo el mundo.

Inicialmente se trabajó en MPX o MultiPointer X, una modificación de X.org para dar soporte a multitouch, del que también se pueden encontrar algunos videos que datan de mediados de 2007.  Posteriormente MPX fue integrado en XInput2 y a su vez éste fue integrado oficialmente en X.org en Junio de este año, dejando esta tecnología lista para ser publicada por las distribuciones de Linux.

Fedora 12 es una de las primeras distribuciones que incluyen esta versión de X.org y por lo tanto soporte de multitouch al instante, y el Interactive Computer Lab preparó un video mostrando varios dispositivos multitouch con Fedora 12.  Aunque tuvieron que realizar cambios para que las aplicaciones actuales pudieran hacer uso de multitouch.

Previamente se habían presentado videos con aplicaciones diseñadas para multitouch, y también algunos en donde sólo se enviaban comandos directos a Compiz para procesar los eventos.  Ahora que MPX está disponible en las distribuciones como parte de X.org, deberían aparecer nuevas aplicaciones que le saquen provecho, especialmente aquellas que corren en dispositivos móviles como las que se pueden encontrar en Maemo.

Click aqui para ver el video.

Multitouch en Fedora 12

Click aqui para ver el video.

Multitouch con Compiz

Link: A video to show off X.Org multitouch support (Phoronix)

Kristian Høgsberg / Wayland / Linux Foundation

A principios de año les contamos sobre un nuevo sistema gráfico para Linux llamado Wayland. La idea es crear un nuevo sistema gráfico más pequeño, sencillo y eficiente que X, el sistema gráfico actual. Si bien Wayland no ha avanzado tan rápido por si mismo, si ha provocado cambios que afectan en forma positiva a todos los sistemas gráficos que pudieran existir.

X.org, la implementación de X que se usa en Linux, cada vez se reduce más en tamaño y complejidad.  Atrás quedaron los días en donde podíamos hablar de una gran cantidad de código en donde podíamos encontrar desde protocolos de comunicaciones hasta sistemas de render de fonts y control del bus PCI/AGP. Hoy en día, X.org se ha ido simplificando, delegando algunas tareas al kernel y otras a bibliotecas o aplicaciones que funcionan en forma independiente.  Gracias a estos cambios, se ha logrado mejorar enormemente la arquitectura de aceleración, el tipo de aplicaciones que se pueden crear y la convivencia con otras aplicaciones que también necesitan acceder al hardware de video.

Esto ha producido que el código que usa X.org y que se encarga de varios aspectos complejos, ahora esté centralizado y compartido, lo que permite ser reutilizado en Wayland (u otro sistema gráfico).  De esta forma el desarrollo de Wayland se simplifica ya que no es necesario construir y probar código desde cero.

Si se revisa el código de Wayland, se puede ver que no hay mucho avance, pero esto lleva a engaños ya que su principal desarrollador ha estado trabajando en la funcionalidad que ahora es compartida con X.org.  Esto quiere decir que en vez de trabajar en mejoras que afectan a Wayland, se está trabajando en mejoras que afectan a todos los sistemas gráficos, incluyendo a X.org y por supuesto Wayland.

Como parte de este trabajo se está mejorando la forma en que se produce el dibujado de las aplicaciones y el dibujado final en la pantalla visible, con el objetivo de eliminar completamente el dibujado parcial (tearing) que ocurre cuando no hay una sincronización entre lo que se está dibujando y cómo esto se lleva a la pantalla visible.

Gracias a Wayland, en el kernel se han creado los mecanismos necesarios para que las aplicaciones y el sistema gráfico puedan notificar y ser notificados cuando el área de dibujo está lista para ser desplegada y cuando se ha desplegado finalmente.  Esta nueva funcionalidad está planificada para ser integrada en el kernel 2.6.33, por lo que es muy probable que el famoso tearing sea cosa del pasado dentro de los próximos meses.

Presentación de Wayland en Linux Plumbers Conference

Link: Wayland – a new display server for Linux (Linux Foundation)

En el grupo de discusión de los desarrolladores, uno de ellos planteó la inquietud de por qué el navegador se percibe ridículamente más rápido en Linux comparado a las versiones para Windows y Mac, lo que originó un interesante debate acerca de cómo el sistema operativo influye en una aplicación de este tipo.

En la discusión se exponen algunos detalles de implementación que hacen que en Linux algunas aplicaciones corran con ventaja gracias a decisiones de diseño tanto por el lado del sistema operativo como de la misma aplicación.  Por ejemplo indican que crear un proceso en Windows es mucho más caro en términos de uso de recursos y esto afecta la creación de nuevos tabs, ya que justamente en Chrome se trata de nuevos procesos.  En el caso de Linux, el sistema en general es más ligero y por lo tanto hace menos cosas en operaciones de este tipo.  Una de las posibles soluciones planteadas es tener siempre un proceso creado en forma anticipada, de tal forma de que cuando se necesite no tenga que esperar el proceso de inicialización.

X.org comienza a mostrar su nueva cara

Otro aspecto importante es la forma en que se manejan los gráficos.  En el caso de Windows se pueden usar dos tipos de gráficos : DIB (independientes del dispositivo) y DDB (dependientes del dispositivo).  En el primer caso se crean en memoria normal y luego se copian a la memoria de video, con el problema adicional de que se deben aplicar transformaciones desde una representación genérica a la representación física o final que se requiere y no siempre puede usar aceleración por hardware.  En el segundo caso, los DDB,  no se requiere tal transformación y una copia puede hacerse con un simple comando ejecutado por la GPU (bitblt), pero el diseño de Windows pone un límite artificial a la cantidad de gráficos que se pueden manejar como DDB, lo que lo convierte en un recurso escaso y poco apetecible por los desarrolladores de aplicaciones.

En el caso de Linux y pese a todo lo que la intuición puede decirnos acerca del tamaño y complejidad de X.org, este tipo de operaciones está muy optimizado, sobre todo en la última generación de drivers que utilizan gestión de memoria unificada en el kernel (GEM), específicamente usando la arquitectura de aceleración UXA.  En este caso las copias de bloques de memoria se reducen al mínimo, y dejar disponible un gráfico en la GPU es una operación acelerada por hardware.  Es tanto así que cuando se inició el desarrollo experimental de UXA en X.org se midieron mejoras en el rendimiento de hasta un 60%.

Por otra parte, según los mismos desarrolladores de Chromium, la forma en que se están creando los gráficos no siempre usa aceleración por hardware, mientras que en el caso de Linux, gracias a las nuevas arquitecturas de aceleración, primero EXA y luego UXA, todas las operaciones comunes se realizan con aceleración por hardware.

En el caso de Mac, los desarrolladores de Chromium dicen que aún no se han enfocado en optimizar el rendimiento, por lo que no tiene mucho sentido discutirlo en este momento.  De todas formas, los usuarios de Windows no deben preocuparse porque ya se han creado los registros en el sistema de seguimiento de bugs de Chromium para solucionar los problemas de rendimiento percibidos.

Links:
- Why is Linux Chrome so fast? (Chromium-dev)
- GEM The Graphics Execution Manager (LWN.net)
- Chrome más rápido en Linux que en Windows y Mac OS (CHW.net)

La implementación de aceleración gráfica para ATI se incluyó en el kernel 2.6.32, pero se hizo un backport al kernel 2.6.31 que incluirá Fedora 12. Gracias a esto se contará con aceleración 2D y Kernel Mode Setting en ATI sin que el usuario tenga que hacer nada especial, es decir, out-of-the-box.

Por otra parte, el código para aceleración 3D de los chips R600/700 ya se encuentra en Mesa, la implementación libre de OpenGL, pero por estabilidad se incluirá una versión anterior en Fedora 12, sin este soporte de aceleración.

Sin embargo, los desarrolladores de Red Hat saben que muchos usuarios están ansiosos de usar el hardware de ATI con Fedora, por lo que incluirán un paquete llamado mesa-dri-drivers-experimental listo para instalar, reiniciar y disfrutar de la última versión de Mesa con aceleración 3D para R600/700 de ATI.

Según las pruebas realizadas en Phoronix, el rendimiento de esta implementación es más que aceptable, aunque hay algunas aplicaciones y juegos en donde se pueden ver algunos defectos menores con el código actual.  Para facilitar la vida y evitar la frustración, en el wiki de X.org hay un documento en donde los usuarios van reportando qué tan bien funcionan los juegos con el soporte 3D para ATI. En esta lista se incluyen juegos nativos y juegos que pueden correr sobre WINE.

ATI siempre estuvo en deuda con los usuarios de Linux, sin que la comunidad pudiera hacer nada al respecto.  Al liberar la documentación de su hardware dieron la oportunidad de que se programaran drivers de código abierto, y poco a poco esta negra etapa va quedando en el pasado.

Links:
- Open Source ATI R600/700 support in Fedora 12 (Phoronix)
- Supported program list for free radeon driver (X.Org wiki)