David Airlie, long-time X.Org/Mesa contributor at Red Hat, added, "They should call the next Ubuntu Jumping Sharks." Airlie followed up with,"they barely have anyone competent enough to write a display server, the fact that they are actually quite ignorant of how wayland works makes it even more apparent."
For those wondering, the C++ code-base that makes up Mir does require Canonical's CLA (Contributor License Agreement). Canonical also hasn't
approached the upstream X.Org/Wayland developers officially. Using the open-source Mesa/Gallium3D driver does require a new EGL DRI2 driver that they currently have packaged in a Mesa PPA on Launchpad, but haven't yet attempted to upstream (or announce) its existence to Mesa developers.
nevat escribió:David Airlie, long-time X.Org/Mesa contributor at Red Hat, added, "They should call the next Ubuntu Jumping Sharks." Airlie followed up with,"they barely have anyone competent enough to write a display server, the fact that they are actually quite ignorant of how wayland works makes it even more apparent."
Toma puya
Ah, y desarrollo pelín cerrado:For those wondering, the C++ code-base that makes up Mir does require Canonical's CLA (Contributor License Agreement). Canonical also hasn't
approached the upstream X.Org/Wayland developers officially. Using the open-source Mesa/Gallium3D driver does require a new EGL DRI2 driver that they currently have packaged in a Mesa PPA on Launchpad, but haven't yet attempted to upstream (or announce) its existence to Mesa developers.
The vibrant IRC discussion then came about Chris Halse Rogers saying Canonical was unsure if their contributions would be accepted into upstream Wayland, followed by the Canonical developer admitting, "I'm unfamiliar with wayland's input handling." Kristian ended up responding to Rogers saying that he doesn't think Canonical meant to "piss" on Wayland by saying, "so don't go and tell the world it's broken if you don't know what it is." Kristian additionally said, "I'll have fun explaining how that's not the case to everybody for the next few months."
Open-source graphics driver developer Jerome Glisse got in on the conversation by saying, "if you look at mir example it's scary...doesn't seems to have the notion of atomic commit...or frame synchronisation...there is a bunch of usleep in them with bogus value to supposedly do 60fps."
Ronbin escribió:Interesante comentario de Aaron Seigo, desarrollador de KDE.
https://plus.google.com/107555540696571 ... SL2C21DJt7
La verdad es que no le veo mucho sentido a portar untity a QT. No sería más cómodo pasarse a KDE? Hay mucha gente que ha replicado el comportamiento de unity con plasma.
. Y todo esto a menos de 2 meses de la salida programada Endher escribió:Ten en cuenta que quieren unificar las interfaces de todos los dispositivos, por lo que pasarse a KDE implicaría portar KDE a todos los sistemas.
rongorongo escribió:De hecho, en sentido absoluto, si estás utilizando Qt no te hace falta servidor gráfico para nada, en realidad lo mínimo que te hace falta es un /dev/fbX donde pintar, yo mismo lo he hecho alguna que otra vez cuando haciendo algún que otro encargo para la empresa, hemos hecho correr sistemas con Linux en 8 megas de RAM con entorno gráfico, sonido, animaciones y todo corriendo como un rayo.
Qt permite que le indiques incrementalmente las capacidades gráficas de las que dispone el hardware, por ejemplo si hay disponible un blitter o openGl. De hecho viene con su propio sistema de ventanas, QWS, y una vez configurado te maneja hasta los punteros del raton o la pantalla táctil.
Es casi trivial echar a andar un sistema utilizando un framebuffer con aceleración gráfica OpenGL ***DENTRO*** de una ventana, hacer es sistema completo sobre opengl es un poco más complicado porque tienes que mapear las primitivas que utiliza Qt para dibujar los widgets y evitar tener que copiar todo dentro de texturas cada vez que uno hace una operación, pero esto lo iban a resolver en Qt5. hay que reseñar que Android te proporciona drivers que funcionan de ambas maneras, y creo que por ahí van los tiros.
Para aplicaciones que no están basadas en Qt basta lanzar un servidor X en modo rootless, lo único que tienes que hacer es mapear las primitivas del servidor a las de Qt (que a su vez las mapea al hardware). Esto lo hice una vez en 2005 o 2006, y se puede lanzar las X bajo demanda, por ejemplo, aunque el hecho de lanzar las X te multiplique por 2 las necesidades de memoria (nosotros nunca la hemos tenido corriendo con menos de 16 Megas de RAM, y eso las X solas).
Si es esto lo que van a hacer, me parece un poco carota llamarle servidor gráfico, en realidad van a usar el que Qt incorpora.
JanKusanagi escribió:Endher escribió:Ten en cuenta que quieren unificar las interfaces de todos los dispositivos, por lo que pasarse a KDE implicaría portar KDE a todos los sistemas.
?
Portar que, a donde?
KDE Plasma Desktop, KDE Plasma Netbook, KDE Plasma Active... si alguien es el rey en adaptarse a todo tipo de form-factors, ese es KDE Plasma
Ronbin escribió:He estado leyendo los comentarios en barrapunto y este me ha parecido realmente interesante.
http://barrapunto.com/comments.pl?sid=89582&cid=1332373rongorongo escribió:De hecho, en sentido absoluto, si estás utilizando Qt no te hace falta servidor gráfico para nada, en realidad lo mínimo que te hace falta es un /dev/fbX donde pintar, yo mismo lo he hecho alguna que otra vez cuando haciendo algún que otro encargo para la empresa, hemos hecho correr sistemas con Linux en 8 megas de RAM con entorno gráfico, sonido, animaciones y todo corriendo como un rayo.
Qt permite que le indiques incrementalmente las capacidades gráficas de las que dispone el hardware, por ejemplo si hay disponible un blitter o openGl. De hecho viene con su propio sistema de ventanas, QWS, y una vez configurado te maneja hasta los punteros del raton o la pantalla táctil.
Es casi trivial echar a andar un sistema utilizando un framebuffer con aceleración gráfica OpenGL ***DENTRO*** de una ventana, hacer es sistema completo sobre opengl es un poco más complicado porque tienes que mapear las primitivas que utiliza Qt para dibujar los widgets y evitar tener que copiar todo dentro de texturas cada vez que uno hace una operación, pero esto lo iban a resolver en Qt5. hay que reseñar que Android te proporciona drivers que funcionan de ambas maneras, y creo que por ahí van los tiros.
Para aplicaciones que no están basadas en Qt basta lanzar un servidor X en modo rootless, lo único que tienes que hacer es mapear las primitivas del servidor a las de Qt (que a su vez las mapea al hardware). Esto lo hice una vez en 2005 o 2006, y se puede lanzar las X bajo demanda, por ejemplo, aunque el hecho de lanzar las X te multiplique por 2 las necesidades de memoria (nosotros nunca la hemos tenido corriendo con menos de 16 Megas de RAM, y eso las X solas).
Si es esto lo que van a hacer, me parece un poco carota llamarle servidor gráfico, en realidad van a usar el que Qt incorpora.
Como no tengo ni idea, no puedo opinar
