Archivo

Entradas Etiquetadas ‘x.org’

Xgl y la revolución gráfica en Linux

Sábado, 11 de marzo de 2006 116 comentarios

Mucho se ha hablado sobre Xgl este ultimo tiempo, y pareciera que todos quieren instalarlo en sus escritorios, pero también veo que hay mucha confusión acerca de que se pretende con Xgl, incluso algunos creen que es una suerte de 3ddesktop pero más espectacular. Hace tiempo que quería escribir sobre el tema, y podría haber escrito varios artículos, pero como la próxima semana no voy a tener mucho tiempo, decidí escribirlo todo en uno solo. Sé que esto llegará a Planeta GNOME Hispano en donde hay gente que sabe mucho más del tema, agradezco si me envían correcciones al artículo por mail privado.

X-Server

El sistema gráfico utilizado en Linux es X-Window, este sistema asume que las aplicaciones actúan como un cliente (x-client) de un servidor X-Window (x-server). El x-server se encarga de lograr la interacción entre el usuario y la aplicación, el rol del servidor es desplegar la imagen en pantalla, y recibir los eventos de teclado, mouse y otros dispositivos. Hay distintas implementaciones de x-servers, los hay para Linux, MacOSX y también para Windows.

Mientras mejor sea el x-server, mejor es la representación de la aplicación. Para ir mejorando un servidor x-server se van proponiendo extensiones (x extensions) y con el tiempo estas extensiones se van implementando en los distintos x-server y drivers. Ejemplos de x-server son XFree86 y Xorg.

Aunque normalmente tanto los x-client y el x-server se ejecutan en un mismo computador, la separación entre x-client y x-server también permite que una aplicación que se ejecuta en un computador, pueda utilizarse desde otro computador en forma remota con un x-server corriendo en el computador local al usuario en forma independiente del sistema operativo.

X Server y X Clients

X Server y X Clients

Modelo de composición

El dibujado de las aplicaciones en pantalla se llama composición. En los sistemas tradicionales, cada ventana es un rectángulo en donde se dibuja la aplicación. Cuando una ventana cubre a otra, no es necesario dibujar el contenido de la ventana no visible. Cuando una ventana que cubre a otra se mueve, la nueva superficie visible de la ventana debe ser redibujada por la aplicación. Si ustedes mueven una ventana en el escritorio rápidamente, verán como las aplicaciones intentan redibujar las ventanas. Este es el modelo de composición utilizado tanto en Windows como en Linux

Una de las desventajas es que las aplicaciones constantemente tienen que estar redibujando las ventanas aunque no hayan sufrido cambios. Si la aplicación no responde, lo único que veremos sera un rectángulo vacío, o si la aplicación se demora en redibujar, se verá un retraso en el despliegue. Otra desventaja es que una ventana que quiera utilizar áreas no rectangulares o áreas semitransparentes, tienen “conciencia” limitada de lo que esta dibujado detrás de ellas, por lo tanto cualquier ventana que no sea 100% opaca y rectangular, no se dibujará correctamente. Si han visto como funcionan gDesklets o SuperKaramba, entenderán de lo que estoy hablando.

Comparación entre modelos de composición

Comparación entre modelos de composición

Composite Managers : xcompmgr, luminocity, looking glass

Un modelo de composición mas evolucionado consiste en dibujar las ventanas completamente fuera de pantalla (off-screen). Cada aplicación dibuja solamente cuando necesita cambiar algo de su ventana, y el contenido completo de cada ventana siempre está disponible, aunque no sea visible. Una aplicación especializada se encarga de transferir la imagen de cada ventana al área visible de video, es decir al escritorio que vemos en pantalla. En esta transferencia puede aplicar cualquier transformación, por ejemplo cambiar el tamaño, rotar, mezclar con el fondo, etc. Esta aplicación especializada es lo que se conoce como Composite Manager. Mientras que un Window Manager debe posicionar y manipular (move/resize) las ventanas en el escritorio, un Composite Manager se encarga de renderizar las ventanas en el escritorio.

Un Composite Manager radical podría por ejemplo dibujar las ventanas como una textura sobre un polígono a través de OpenGL, y pedirle a la tarjeta de video que dibuje el polígono en pantalla, considerando que hoy en dia las tarjetas de video son hábiles en renderizar polígonos en un entorno 3D, se podría delegar gran parte del trabajo a una tarjeta con aceleración 3D. Si por ejemplo se quisiera obtener una vista minituarizada o ampliada de la ventana, bastaría simplemente con cambiar el tamaño del polígono y la tarjeta de video se encargaría de hacer el render, y Uds. saben: “sí, son rápidas”. Al mover una ventana sobre otra, son simplemente dos polígonos que se superponen, y se pueden mover “como si nada”.

Keith Packard trabajó en una nueva x-extension llamada Composite. Esta extensión permite cambiar el modelo de composición tradicional en donde cada ventana dibuja solo las áreas visibles, y redibuja las que se van “descubriendo”, por el descrito en el párrafo anterior en donde las ventanas se dibujan siempre off-screen. El trabajo se inicio en el x-server experimental kdrive, también conocido como el x-server de freedesktop.org, y posteriormente se implementó en el servidor Xorg, que es el que viene con la mayoría de las distribuciones de Linux. Hay un paper sobre los cambios necesarios para cambiar al nuevo modelo de composición.

X Server de FreeDesktop

X Server de FreeDesktop

El primer Composite Manager conocido se llama xcompmgr, y era un Composite Manager de ejemplo que implementaba cosas simples como agregar sombras y transparencias a las ventanas. Para realizar estas sombras y transparencias se utilizaron funciones de la extensión XRender (también de K.P.), un obstáculo es que prácticamente ningún driver de Xorg acelera(ba) correctamente la extensión XRender, a excepción del driver propietario de nvidia. El problema es que la arquitectura de aceleración de Xorg (XAA) no es muy adecuada para tener XRender acelerado por hardware, mientras que la arquitectura de kdrive (KAA) si permite una buena implementación de XRender pero no hay muchos drivers compatibles con kdrive. Por lo tanto, xcompmgr solo era usable si eras propietario de una nvidia, o bien utilizabas kdrive pero sin aceleración por hardware.

Para solucionar este problema, surgió la iniciativa de EXA, que vendría siendo algo así como KAA aplicado a Xorg. La idea era que lentamente los drivers XAA se fueran convirtiendo en EXA, y el usuario puede escoger si usar EXA o el modelo tradicional XAA. Mientras tanto, en RedHat se comenzó a experimentar modificando Metacity, que es el Window Manager de GNOME, para que incluyera funciones de un Composite Manager. Este desarrollo tomo el nombre de Luminocity. Este Composite Manager era mas ambicioso que xcompmgr e incluía funciones de transformación de ventanas, uso inteligente de transparencias para destacar ventanas en transición, y un selector de escritorios en donde se podia ver cada ventana minituarizada en tiempo real.

Luminocity

Luminocity

Si buscamos otra aplicación de Composite conocida, tenemos el famoso proyecto Looking Glass de Sun. Ellos aprovecharon la extensión composite para poder hacer un Window Manager/Composite Manager que pudiera manipular las ventanas en un entorno 3D.

Looking Glass de Sun Microsystems

Xgl y Compiz

Otro camino posible para obtener buenos resultados era olvidarse de Xorg y crear un nuevo x-server que facilitara el trabajo considerando el nuevo modelo de composición, y aprovechando las características de las tarjetas de video modernas que han sido diseñadas para utilizar operaciones gráficas 3D aceleradas por hardware. Es ahi donde aparece el x-server Xgl, publicado recientemente por Dave Reveman de Novell. Este x-server realiza sus operaciones de render no utilizando un driver propio, sino que utilizando un driver OpenGL. El x-server Xgl mas común es el Xglx, y lo que hace es conectarse a otro servidor X que tenga soporte de OpenGL a través de la extensión GLX (OpenGL/X). Entonces si levantamos Xorg + Xglx tendremos un x-server con operaciones OpenGL aprovechándose de la infraestructura de otro x-server con drivers OpenGL a través de GLX. Es esta combinación la que hemos tenido oportunidad de ver últimamente en los alucinantes videos.

El Composite Manager creado para aprovechar las características de Xgl se llama Compiz, además de ser un Composite Manager también es un Window Manager. Una de las cosas interesantes de Compiz es que funciona en base a plugins, entonces cada plugin agrega un nuevo efecto especial a Compiz. Los plugins que existen a la fecha permiten hacer fade de las ventanas al aparecer/desaparecer, rotar los escritorios virtuales como un cubo, visualizar las ventanas como Exposé de MacOSX, mover las ventanas como si fueran de papel. etc.

Xgl + Compiz

Xgl + Compiz

Aiglx y Xair

No todos eran partidarios de construir un nuevo x-server como se hizo con Xgl, porque era harto trabajo. Entonces surgió un proyecto alternativo llamado Aiglx, publicado por RedHat. Aiglx permite utilizar aceleración OpenGL para realizar la composición, pero modificando suavemente Xorg. Aiglx se apoya en un Composite Manager llamado Xair, que al parecer es una evolución de Luminocity.

Soporte de Hardware

Para utilizar el nuevo modelo de composición en nuestros computadores, necesitamos hardware que sea compatible con las distintas combinaciones de x-servers y composite managers. Hoy en día la mejor alternativa es utilizar alguna tarjeta de video que utilice un chip de nvidia. El soporte va a ir mejorando a medida que se implementen las funciones necesarias por cada x-server y composite manager, específicamente el soporte de EXA, y la nueva extensión GLX_EXT_texture_from_pixmap son claves para la expansión de estas nuevas tecnologías.

El cambio en la forma en que se perciben las ventanas, y el hecho de que las aplicaciones ya no tienen que redibujar, hacen que el cambio realmente valga la pena, inclusive si solamente se utiliza xcompmgr en su forma mas básica.

Las esperanzas son altas, por ejemplo tengo una tarjeta de video integrada Intel i855 de 64MB, xcompmgr funciona perfectamente con Xorg, es suficientemente usable como para tenerlo diariamente en mi escritorio. Compiz+Xgl funcionan bien, pero con algunos “glitches”, y hay cosas que funcionan lentas debido a la falta de soporte de GLX_EXT_texture_from_pixmap en la versión actual de mi driver.

¿Como estan los otros sistemas?

MacOSX cambió el modelo de composición hace bastante tiempo, a través de Quartz Extreme . Windows cambiará el modelo de composición en Windows Vista, pero requerirán un hardware mucho mas potente para poder aprovechar estas características.

Alucinen

Viernes, 24 de febrero de 2006 9 comentarios

Dicen que una imagen vale más que mil palabras, y un video.. pues mucho mas. Voy a comentarlo más tarde, por ahora disfruten el video de la presentación de Xgl publicado por David Reveman

Update: También en YouTube

Imagen de previsualización de YouTube
Tags: ,

No es tan simple!

Lunes, 6 de febrero de 2006 6 comentarios

En los comentarios de mi artículo anterior sobre el video de Xgl, mi amigo Sebastian Beeche plantea algunas dudas que son muy frecuentes entre los usuarios de Linux y que muchos se autoresponden en forma equivocada o simplemente no consiguen respuesta. Lo que voy a comentar aqui lo hago desde lo que me ha tocado conocer, tanto desde el punto de vista de desarrollador, como el de un simple mortal suscrito a listas de desarrollo, asi que no lo tomen como “la verdad”, solo como lo que he observado.

Seba: “Para que Linux sea realmente LA alternativa, además de mejorar la gráfica, hay que hacer que el sistema sea más amable con todo tipo de periféricos”.

Esto NO es posible asi como estan las cosas. Linux no va a tener soporte de todo el hardware sin la cooperación de los fabricantes de hardware. Para que un dispositivo pueda ser soportado en Linux se necesita de un driver, y para que exista un driver se debe cumplir una de las siguientes condiciones

  • El fabricante desarrolla el driver para Linux
  • El fabricante entrega las especificaciones del hardware para que un tercero desarrolle el driver para Linux
  • Un tercero, mediante ingeniería inversa, deduce las especificaciones del hardware y escribe su driver para Linux

Salvo honrosos casos, los fabricantes no desarrollan drivers para Linux. Esto tiene diversas explicaciones, una de ellas es no contar con los recursos y/o el know-how de cómo escribir un driver para Linux… y hay que decirlo.. con suerte hacen el driver para Windows, no es raro que el driver para Windows sea muy malo, con mayor razon poco les queda para otros sistemas. Otra explicacion es la masa critica : muchos de ellos esperan que hayan mas usuarios utilizando Linux, mientras que los usuarios esperan a que el fabricante desarrolle los drivers, en esas condiciones es muy dificil que el fabricante desarrolle el driver.

Ok, si el fabricante no desarrolla el driver, entonces por que no entrega las especificaciones? Aqui siempre es el mismo caso, hay un temor del fabricante de revelar “los secretos” de su hardware, estos secretos consideran tanto tecnología que no desean publicar asi como tambien mejoras que se hacen en los drivers para que el hardware se comporte mejor en ciertos tipos de benchmark conocidos. Otro motivo para no entregar las especificaciones es el licenciamiento de tecnologías de terceros, que impide a un fabricante revelar como funciona el 100% del hardware.

Queda entonces una sola alternativa, tratar de adivinar cómo funciona el hardware, pero esta es tan costosa como imposible, ademas que es muy poco el beneficio versus el esfuerzo. Te puedes demorar 1 año en aprender como funciona el 5% de un cierto tipo de hardware, que despues sera desplazado por otro. Por eso si el hardware no tiene driver, es mejor botarlo a la basura o prenderle fuego.

Seba: “No se xq Linux se ha demorado tanto en ese paso final, cuando la gente de Jobs lo sacó en un plazo de un par de años siendo que son un grupo pagado pero MUCHO más reducido que la comunidad total de gente que aporta a Linux”

No es tan asi. Si bien el grupo de gente involucrada con el desarrollo de Linux es muy grande, esta distribuido en muchos proyectos, por lo tanto cada proyecto cuenta con un grupo no tan numeroso de gente (kernel, gcc, Xorg, GNOME, KDE, OpenOffice, etc). Por ejemplo los desarrolladores principales de OpenOffice no son mas de 15, el resto son personas que contribuyen ocasionalmente. Si quieren ver la gente que trabaja en GNOME, y donde viven, pueden ver el mapa de desarrolladores de GNOME, ahora dividan por el número de proyectos que conforman GNOME. Por eso se hace tanto énfasis en las RFDG.

El hecho de que sea un grupo pagado también cambia harto las cosas, te aseguras de que puedan dedicarse 100% al tema. Actualmente en Linux los principales desarrolladores son pagados, pero todos son independientes entre si, no hay una “orden superior” que señale una senda a seguir, sino que todo se debe discutir y acordar, y ponerse de acuerdo no es tan facil. Es quizas una de las principales complicaciones cada vez que se quiere hacer un cambio grande, por lo mismo los grandes avances a veces se han desarrollado sin preguntar mucho a los demas, de paso se evita el fenómeno de Stop Energy.

Si lo llevamos al tema de los drivers, para Apple es un tema mucho mas facil de resolver, simplemente si quiere incluir un tipo determinado de hardware a su propio hardware, puede financiar el desarrollo negociando directamente con el fabricante del hardware y listo. Total el fabricante de hardware se esta jugando la venta de su hardware como parte de las maquinas de Apple, o por ultimo como periférico compatible.

A nivel de software, algo similar esta haciendo Novell mediante una encuesta para saber que aplicación podría portarse a linux llegando a un acuerdo directamente con sus desarrolladores originales.

Seba: “Ahora, siendo super honestos, hay 3 tarjetas de video en el mercado (Ati, Nvidia e Intel) y con eso de más que se puede dar un soporte digno”

Actualmente Nvidia desarrolla un driver para Linux ocultando su código fuente para evitar problemas legales como los mencionados arriba. Su driver es 100% funcional y el soporte es tan bueno como en Windows. Ellos anteriormente habian donado un driver opensource pero esta bastante recortado, por motivos legales solo implementa lo que se podia publicar, además que está intencionalmente ofuscado. El problema es que hasta no hace mucho, nvidia era muy bueno haciendo hardware, pero muy malo escribiendo drivers para Linux, lo que causaba que a muchos usuarios se les colgara el sistema por bugs del driver. Y como no son open source, nadie los puede corregir salvo nvidia. Hoy en dia la situación es muy distinta, y si alguien me pregunta por qué tarjetas de video son las mejores soportadas en Linux, mi respuesta es nvidia. Por ejemplo, su driver propietario con aceleración de la extensión RENDER por hardware hizo posible que xcompmgr funcionara super bien desde el principio, y no me extrañaría que los videos de la demo estén utilizando hardware de nvidia, o bien otro hardware pero con driver que utilice EXA.

En ATI no me queda muy clara la situación. Ellos también tienen una mezcla entre propietario y open source. Hay un driver propietario, que aprovecha casi el 100% el hardware pero que tiene problemas con bugs. También han cooperado para que se puedan escribir drivers open source aunque no se aproveche 100% su funcionalidad. Según entiendo, ellos han ayudado en la construcción del driver open source para sus chips, mediante acuerdos directos entre ellos y algunos (o un) desarrollador(es).

El caso de intel es similar, pero sin driver binario. No puedo decir mucho de esos drivers, mi notebook los usa pero no tengo como compararlo con el de windows (tarea para mas adelante).

Seba: “El sistema de apple de como maneja la data, las instalaciones, los programas y las opciones de usuarios son realmente buenas, en las que hasta un diputado podría hacer uso de ellas (bueno.. no se si tanto :D )”

No puedo comentar mucho, porque no conozco como funcionan estas cosas en MacOSX. Pero si puedo decir que al menos en una buena distribución (como Ubuntu), el tema de la instalación de aplicaciones es lo mas sencillo que he visto, siempre y cuando sean aplicaciones open source. Y cuando no son open source, la responsabilidad es unicamente del desarrollador de software, ya que las herramientas para empaquetar, instalar y publicar existen, son de libre uso y son simples de utilizar, si “hasta el Bruno las sabe usar” ;) . En Linux cualquier aplicación es simple de instalar siempre y cuando exista un paquete para ella.

Sobre el manejo de “la data” no se a que se refiere exactamente Sebastián, y sobre las opciones de usuario tampoco se que calificaría como “buena”, como para ver en que estado esta Linux.

Videos de Xgl en demostración de Novell Linux Desktop

Sábado, 4 de febrero de 2006 10 comentarios

Ayer hizo noticia una demostración que hizo Novell de su próxima versión de Novell Linux Desktop. Mostraron cosas que no son tan nuevas para los seguidores de GNOME como Evolution, F-Spot y Banshee, pero lo que causo mayor sorpresa fue la presentación del estado actual de Xgl, la implementacion de X sobre OpenGL.

Xgl junto a otros avances como la extension Composite significarán un cambio radical en lo que se conoce hoy en dia como el entorno gráfico de Linux. Las personas que han ido a mis charlas, han podido ver algo, pero los videos de la demostración de Novell muestran que ya se ha avanzado bastante y es impresionante ver que los usuarios de Linux podremos disfrutar de cosas que ya se habían experiementado en MacOSX y seguramente incluirá Windows Vista.

En linea se pueden encontrar los videos que muestran Xgl, y también encontre uno en YouTube para verlo directamente.

Imagen de previsualización de YouTube

Encuentro Nacional de Linux y tip SSH

Martes, 18 de octubre de 2005 6 comentarios

Prácticamente no falta nada para el Sexto Encuentro Nacional de Linux que este año se realizará en la Universidad Arturo Prat de Iquique. Si bien no tengo lista mi charla 100%, al menos ya tengo funcionando las demos mínimas que pienso mostrar.

El titulo de mi charla no dice mucho : “Nueva generación de gráficos en Linux”. Lo que tratare de hacer es mostrar lo que se esta haciendo en el área gráfica de Linux, tanto en el lado del xserver (composite, EXA, Xgl) como en las bibliotecas gráficas (cairo), mostrando algunos ejemplos que ya están funcionando.

German y Alvaro tienen la idea de hacer un track de charlas alternativas, será algo asi como un bonus track enfocado a publico mas especialista, charlas que de otra forma no hubiesen sido seleccionadas para el Encuentro, pero que si son interesantes para los mas avanzados. Esperamos que se nos unan otros secuaces como Max y Daniel Serpell.

Mañana parto a Iquique y por lo visto nos encontraremos con un grupo grande en el aeropuerto. Estos encuentros son una gran oportunidad para compartir con amigos que uno no ve muy seguido pero que tienen muchos intereses en común.

Tips de SSH (Túnel TCP)

Alejandro da unos tips para usar un tunnel de X por ssh de forma bastante cómoda. En palabras simples, solo basta tener una conexión ssh para poder ejecutar aplicaciones gráficas en forma remota y segura. Básicamente lo que hace ssh es crear una especia de proxy en el equipo remoto, que redirige el trafico de X a través de la conexión ssh hasta el servidor X local. Una pequeña observación al tip es que el primer paso (xhost +) no es necesario, ya que la conexión que llegara por X aparecerá como efectuada desde el equipo local :

xserver local - ssh cliente - ssh servidor - x remoto (ssh) - aplicación

El servidor ssh automáticamente setea la variable DISPLAY para que apunte al extremo “x remoto (ssh)”, usualmente DISPLAY=:10.0 (11, 12, 13, etc).

No solo se pueden usar conexiones a X por tunel, sino que cualquier conexión TCP, esto permite que con solo tener acceso ssh podamos acceder a cualquier recurso desde la red remota, como si fuera local.

Supongamos que tenemos un servidor de correo en la red remota, que solamente se puede acceder al interior de esa red. El servidor se llama correo.localdomain, y atiende IMAP por el puerto 143. Entonces por ssh se puede establecer la siguiente conexión:

ssh -L143:correo.localdomain:143 servidorssh

Esto creara un tunel desde el puerto 143/tcp local hacia el puerto 143/tcp en correo.localdomain a través de la conexión ssh con el “servidorssh”.

Luego si configuramos localmente nuestro cliente de correo para que los recupere desde localhost:143, la conexión se realizara a traves de ssh con el servidor correo.localdomain:143.

Fin de semestre

Jueves, 23 de junio de 2005 5 comentarios

En un par de semanas termina el primer semestre para mis alumnos de la sede Viña del Mar de la UTFSM. En este tiempo que queda están presentando sus trabajos de investigación, hay alumnos que han absorbido bastante bien los conceptos que traté de transmitir. Para mi esta asignatura ha sido una oportunidad para acercar a los estudiantes al estado del arte del diseño y construcción de aplicaciones, les ha costado un poco lograr el cambio en la forma de pensar en un diseño, pero con satisfacción veo que algunos ya comienzan a aplicar estos nuevos conocimientos.

Charla en Rancagua

El 9 de Julio estoy invitado a dar una charla en Rancagua. En un principio querían que fuera solo, pero eso no le conviene ni a mi ni a la organización, así que les pedí que invitaran a mas expositores. Como antes he comentado, ademas de interactuar con la gente, la oportunidad de conversar en persona con otros miembros de la “mafia Linux” en Chile es muy atractiva. A la fecha no he podido participar en ninguna Reunion de Formacion de Desarrolladores de GNOME , y me siento en deuda.

Mono SQL Sharp

Ahora que termina el semestre voy a tener mas tiempo libre para volver a involucrarme en algun proyecto Open Source. Me interesa mucho lo que se esta haciendo con Mono, la plataforma es lo suficientemente productiva como para hacer cosas rapidamente, ideal para casos de escaso tiempo libre como el mio. Queria partir con alguna aplicacion de juguete, por ejemplo SQLAdmin la porté a SWT para aprender a trabajar con este toolkit, era un buen candidato para aprender Mono, pero me encontré con la grata sorpresa de que ya hay un trabajo similar, se llama Mono SQL Sharp y es bastante parecido a SQLAdmin.

tvnauta

En tvnauta mostramos la instalación de Fedora Core 4, tuve harto espacio para hablar y lo ocupe revisando las aplicaciones que vienen incluidas en la distribución, como Evince y OpenOffice 2.

El programa de este lunes lo grabamos ayer, fui a reemplazar a Sebastian que se encuentra trabajando a esa hora, por lo tanto esta semana el dia de Linux sera el lunes y no el miercoles. Que aprovechen los que estan usualmente trabajando a esa hora!!. Como adelanto les puedo contar que mostraré (o mostré?) Luminocity en vivo.

Hoy estuve probando otra aplicacion vistosa para mostrar, encontre algunos blogs en donde daban algunas “paltas” para instalar y ejecutar 3desktop. Lo acabo de probar y funciona bastante bien, de paso aprendi a asociar teclas a comandos, de inmediato asocie system-config-monitor para esos casos de emergencia.