Buscar en La Comunidad

Hace ya varios años que Wayland, el protocolo de servidor gráfico que sustituirá al veterano X11, está "por llegar", pero sigue sin hacerlo y es que, aunque cada vez estamos más cerca y ya hay distribuciones que se atreven a incluirlo entre su paquetería, como alternativa o incluso, como servidor gráfico por defecto, aún hay muchos escollos en el camino que hay que solventar para que Wayland puede estar en el escritorio de todos los linuxeros. Entre las tareas pendientes están, como no podría ser de otra manera, la compatibilidad por parte de los distintos controladores gráficos y la adaptación de entornos gráficos, gestores de ventanas, compositores, etc al nuevo protocolo. En este sentido, desde hace más de un año viene desarrollándose y acalorado y enrevesado debate que dio origen con la presentación, por parte de Nvidia, de EGLStream. Por hacer un breve resumen, hasta ahora Wayland ha girado en torno al administrador genérico del buffer GBM, algo que Nvidia, ya por el año 2012 criticó, para un par de años más tarde presentar su alternativa, que es lo que ahora conocemos como EGLStreams. Esto no fue bien recibido por la comunidad, que ya sabemos de sobra que es de mecha corta y desde entonces el conflicto está en el aire. Lo irónico del caso es que, en esta ocasión, la empresa californiana, conocida por tener muy buen soporte pero también prácticas muy privativas, tiene razón. GBM, aún siendo software libre, es de carácter exclusivo y está atado estrictamente a los controladores mesa, mientras que EGLStream se basa en el estándar abierto EGL, es multisistema, multiplataforma y, por lo que hemos podido saber hasta el momento, en cuanto a eficiencia y capacidades técnicas también supone una mejora importante. La problemática reside, precisamente, en ese lapso de tiempo de 3-4 años desde que Nvidia hiciera públicas sus intenciones hasta que finalmente se materializaron, pues todo el trabajo se ha venido desarrollando pensando únicamente en GBM y un cambio a estas alturas significaría replantearse muchas cosas y modificar un gran número de líneas de código. Además, muchos temen que a falta de un consenso acaben teniendo que mantener simultáneamente dos métodos de manejo del buffer para cada compositor, con todo el esfuerzo que ello implica. E incluso hay quien sugiere reinventar GBM para ponerlo a la altura de las características de EGLStreams en lugar de modificar los compositores para que hagan uso de otro administrador del buffer. Aun sin haber llegado a una conclusión clara todavía, parece que Nvidia va ganado adeptos que consideran que apuntar a un estándar universal y abierto, además de más completo y eficiente, en torno a una nueva API desarrollada de manera conjunta, es el camino a seguir. Entre ellos está la gente de Gnome, que ya ha empezado a trabajar para adaptarse lo antes posible. Por si fuera poco y como reza el título de este tema, Nvidia sigue avanzando mientras la comunidad sigue debatiendo y en su última serie de controladores incluye nuevas librerías EGL para Wayland y una interfaz de plataforma externa para EGLStreams, de tal forma que manejo de buffer utilizando EGLStreams podría ser implementado de manera sencilla en cualquier sistema de ventanas sobre plataformas EGL de bajo nivel superpuestas. Concretamente sobre EGL_PLATFORM_DEVICE_EXT, utilizando extensiones EGLStream. Para rematar, nos brindan todo el código fuente de ambos, tanto de la interfaz de plataforma externa EGLStremas como de las librerías EGL para Wayland,incluyen nuevas extensiones Vulkan, sombreado multihilo GLSL y habilitan las optimizaciones OpenGL por defecto (con un sistema de autoajuste que las desactiva en caso de que no supongan una mejora del rendimiento) en el nuevo controlador 378.X. Casi nada... y de fondo la comunidad aún discutiendo:sweat: https://lists.freedesktop.org/archives/wayland-devel/2017-January/032722.html.

Aunque hace tiempo que me decidí por no sucumbir a polémicas a la hora de escribir, en este caso quiero hacer una excepción, porque es un tema que nos llega de cerca a muchos y que podría ser decisivo para el futuro de los entornos gráficos en GNU/Linux Hace muy poco, Nvidia liberó por fin una nueva serie de controladores que, no sólo nos traían Vulkan de manera estable y completamente funcional, sino que nos brindaban soporte para el servidor gráfico Wayland a través de EGL. Algo que llevábamos esperando desde hace ya mucho tiempo. Sin embargo, aunque en principio esta noticia sobre Nvidia suponía un salto importante a la hora de empezar a adoptar masivamente el servidor gráfico Wayland, dejando por fin "de lado" al veterano X11, junto a los controladores oficiales se han liberado una serie de parches de código abierto, que fueron enviados a la comunidad de desarrolladores de Wayland, que no han sido visto con buenos ojos por parte de los desarrolladores del servidor gráfico. Este código, pensado en principio para permitir que Weston, el compositor base de Wayland pueda correr sobre los controladores gráficos oficiales de Nvidia (privativos), ha sido rechazado. El origen de la polémica parece ser la implementación que ha hecho Nvidia, pues se valen directamente de EGL, haciendo uso de las extensiones EGLDevice y EGLStreams para manejar los buffers, mientras que la implementación oficial de Weston utiliza MESA GBM (Generic Buffer Manager). Si bien para algunos, incluida la propia Nvidia, esta aproximación supone un acercamiento más "agnóstico", en lugar de tener que desarrollar una versión alternativa de GBM para su línea de controladores, desde el otro lado sólo ven problemas con la alternativa propuesta por la californiana, al hacer uso de extensiones poco usuales o complicar/simplificar demasiado ciertos aspectos del renderizado. Aunque en principio esto no impide que entornos con compositores propios, como Enlightenment, Hawaii, Orbital, Orbment o incluso alguno de los más conocidos como KDE O Gnome, puedan dar soporte a Nvidia, implementándolo por cuenta propia en sus compositores, dentro del seno de Wayland y de cara al compositor Weston, por ahora las cosas están siendo discutidas de manera muy acalorada y no parece que veamos pronto ningún movimiento, al menos hasta que todos los pormenores hayan sido hablados y el código de Nvidia minuciosamente estudiado. https://lists.freedesktop.org/archives/wayland-devel/2016-March/027547.html

Mucho se ha hecho de rogar, pero finalmente tenemos lo que tanto hemos esperado. Nvidia acaba de liberar una nueva serie de sus controladores oficiales que traen, como siempre, muchas novedades interesantes, pero es que esta vez son más que eso. La nueva serie 364 culmina lo que comenzó con la serie experimental 355 y nos brinda soporte oficial estable para la nueva API gráfica de Khronos, Vulkan, en su actual versión 1.0.6, además de completar el proceso de adopción de EGL introduciendo las primeras librerías que dan soporte completo al servidor gráfico Wayland. Se cambia el patrón de instalación para hacer uso de las librerías GLVND GLX en lugar de las librerías GLX antiguas Se añade soporte inicial para DRM KMS (Direct Rendering Manager Kernel Modesetting) Esto significa la inclusión de un nuevo módulo nvidia-drm.ko, que se inscribe tanto con soporte PRIME como DRM KMS Se añade soporte para numerosas extensiones EGL EGL_EXT_platform_waylandencargada de hacer que aplicaciones Wayland corran en la implementación EGL de Nvidia EGL_WL_bind_wayland_displayencargada de hacer que compositores Wayland corran en la implementación EGL de Nvidia EGL_EXT_device_drm EGL_EXT_output_drm EGL_EXT_stream_consumer_egloutputPara permitir que los compositores Wayland muestren su contenido a través de EGLDevice, EGLOutput y EGLstreams. Se añade la librería libnvidia-egl-wayland.so, que permite a los compositores Wayland el uso de EGLDevice, EGLOutput y EGLstreams para compartir el buffer de EGL con las aplicaciones Wayland Suporte estable para la API Vulkan 1.0 Se mejora la precisión de X colormap desde 8 bits significativos a 11 en GPUs Geforce Se añade una nueva característica RandR, CscMatrix, la cual especifica una matriz de conversión de espacio de color de 3x4. Esta matriz se aplica después de X colormap y antes de gamma ramp. Es compatible con GPUs GF119 o más recientes. Así mismo se mejora el manejo de X gamma ramp en GPUs GF119 o más recientes. RandR gamma ramp cuenta siempre con 1024 entradas y ahora se aplica al cursor, VDPAU capas de estaciones de trabajo como añadido a la ventana de root de las Xs. Los registros del controlador de Nvidia han sido rediseñados con el nuevo subsistema DRM de Linux para dar soporte a PRIME. Como consecuencia de esto, es necesario contar con Linux 3.13 o superior para instalar esta nueva serie de controladores. Se mejora la interacción de aplicaciones que utilizan el cursor de hardware mientras G-SYNC está activo. Se incluye también soporte para nuevas GPUs GeForce 920MX GeForce 930MX Y, por supuesto, numerosos parches y correcciones Sobra decir que al margen de la ingente cantidad de novedades y mejoras, tanto Wayland como Vulkan son dos cosas que llevábamos mucho tiempo esperando y que por fin tenemos a nuestro alcance para sacarle todo su potencial. Nos queda aún el sabor agridulce por la falta de soporte a gráficas Fermi, esperemos que finalmente de parecer, pero igualmente hay que reconocer que, si bien no como a todos nos gustaría, Nvidia sigue siendo única a la hora de ofrecer soporte a los linuxeros más exigentes.

RebeccaBlackOS, la distribución GNU/Linux que lleva el nombre de la artista que se hizo famosa por su amor por los viernes, ha crecido desde aquel día que apareció por la blogosfera linuxera como una especie de broma al nivel de Biebian o Hannah Montana linux, pero que se ha ganado un puesto de honor entre las distribuciones GNU/Linux al ser a día de hoy el Live que nos muestra de manera más clara de lo que el servidor gráfico wayland puede ofrecernos, manteniéndose siempre al día con los avances de éste y con muchos de los entornos gráficos que lo han acogido. Entre los entornos y compositores soportados e incluidos tenemos: Escritorio de ejemplo basado en Weston Orbital Hawaii Papyros Gnome-shell Enlightenment E19 Orbment tiling Wayland DE Versión preliminar de KDE (no del todo funcional) En cuanto a librerías, toolkits y aplicaciones: Clutter SDL GTK QT EFL/Elementary FreeGLUT GLFW mpv gstreamer Aplicaciones nativas de KDE Frameworks Suite ofimática Calligra Una forma simple sencilla y actualizada de probar Wayland y estar al tanto de sus avances en espera que no tardemos mucho más en verlo como servidor gráfico por defecto en nuestra distribución de cabecera. Capturas Descarga x86 http://sourceforge.net/projects/rebeccablackos/files/2015-06-05/RebeccaBlackOS_i386.iso x86_64 http://sourceforge.net/projects/rebeccablackos/files/2015-06-05/RebeccaBlackOS_amd64.iso Web http://sourceforge.net/projects/rebeccablackos

19 de Junio de 1984 es la fecha del nacimiento del servidor gráfico que nos ha acompañado hasta el día de hoy, el día en el que Bob Scheifler daba a conocer X Window System Y aunque parezca mentira X Window system en su versión 11 (X11), a pesar de su edad y que su sustituto, Wayland, está a las puertas de ocupar su puesto, aún tiene cuerda para rato y la fundación X.Org ya se encuentra celebrando el trigésimo aniversario de su más que exitoso proyecto. Felices 30 años X y gracias a todos los que lo han hecho posible http://permalink.gmane.org/gmane.comp.freedesktop.xorg.announce/2177

Hace apenas una semana Wayland era propuesto para Fedora 21 y ya tenemos la confirmación: https://lists.fedoraproject.org/pipermail/devel/2014-May/199045.html La andadura de Wayland comienza por fin y Fedora 21 será la distribución mayor que, con Gnome 3.14, dará el primer paso para que el novedoso servidor gráfico sustituya por fin al vetusto X11 que tantos años nos ha acompañado. Ahora sólo queda saber ¿Tendrán Nvidia y AMD sus controladores listos para este acontecimiento que tendrá lugar en el último trimestre del año? https://fedoraproject.org/wiki/Changes/Wayland#Current_status

Después de mucho tiempo de desarrollo podríamos estar ante la primera gran implementación de Wayland en una distribución "mayor" de GNU/Linux y, como no, no podía ser otra que Fedora. Aunque disponible a día de hoy en muchas distros de manera experimental y en algunas menos conocidas y más modestas a modo de prueba de concepto, el hecho de contar con Gnome 3.14 para la próxima versión de Fedora, cuya compatibilidad con el nuevo servidor gráfico para GNU/Linux que está muy adelantado en este sentido y los flecos que aún quedan también tratarán de solventarlos durante el desarrollo. En el mismo hilo de discusión también se deja claro que esto no significará el destierro de las Xs sino que éstas seguirán siendo una posibilidad más a la hora de iniciar sesión y trabajar de manera gráfica. No obstante, aún quedan algunas dudas importantes que resolver en lo que concierne a la compatibilidad de los controladores gráficos de las grandes compañías de Hardware, Nvidia y AMD, que si bien han hecho algunos movimientos en este sentido aún se encuentran lejos de ofrecer soporte completo para Wayland https://lists.fedoraproject.org/pipermail/devel/2014-April/198689.html https://fedoraproject.org/wiki/Changes/Wayland

Sin querer, buscando alguna información que no viene al caso, he acabado con una pregunta en mi cabeza. ¿Y si quisiera ejecutar una aplicación gráfica, pero no en la sesión gráfica en la que me encuentro? Esto es bastante sencillo y da mucho juego. Sólo tendremos que valernos de startx y algunas de sus opciones. Para iniciar directamente una sesión de las Xs, ejecutaríamos simplemente: startx Comando que no funcionaría más que una vez, porque al segundo y posteriores intentos no iniciaría una nueva sesión al tener una ya levantada. Para levantar varias sesiones de manera simultánea podemos hacerlo especificando una terminal virtual distinta a la que estamos usando para las sesiones que ya tenemos iniciadas: Siendo X un número del 1 al 12 que corresponderá a la terminal tty elegida para albergar la nueva sesión de las Xs y a la que podremos acceder con la combinación Control + Alt + FX Para iniciar una nueva sesión con una aplicación concreta ejecutándose en ella, simplemente intercalaremos la orden en medio del comando anterior Nos puede surgir un problema y es que nuestro usuario no esté autorizado a iniciar una nueva sesión de las Xs o que sólo pueda hacerlo desde consola cuando no hay una sesión previa ya en marcha. Esto se puede solucionar editando la configuración de Xorg en el archivo /etc/X11/Xwrapper.config Para el valor de usuarios permitidos (allowed_users) tendremos tres posibles opciones root console anybody Para poder ejecutarlo como usuarios, elegiremos anybody allowed_users=anybody NOTA Los usuarios de distribuciones basadas en Debian pueden llevar a cabo este proceso mediante la orden: dpkg-reconfigure x11-common