[eside-ghost] Adiós hd*, hola sd*

[Jon Ander Hernández]

Aupi!!

On Thu, 2006-09-21 at 00:31 +0200, Juanval wrote:

> Humm cosa curiosa. Aunque ya veremos si resuelve mas problemas de los
> que puede traer xD

Jejeje, creo esto se va a poder aplicar a casi todos los cambios que van
a introducir en edgy :D

> Yep, tengo metido edgy en este portelo, y la verdad es que arranca
> mucho mas rápido (no tanto como MacOS, que arranca en 15-20 segundos,
> pero eso ya sería pedir mucho xDD). Eso si, tambien es muy poco
> verboso: en total, en todo el proceso de arranque, no llega a llenar
> una pantalla entera de texto.

Interesante. Yo creo que debería llegar a ser tan rápido como OSX, lo
que ocurre es que supongo que todavía no estará funcionado a pleno
rendimiento porque probablemente no estén reescritos la mayor parte de
los scripts de arranque y estén funcionando en modo compatibilidad. Me
imagino que tiene que ser esto porque usar el sistema de OSX era también
una opción porque también es libre, y he incluso se lo estuvieron
planteando, aunque finalmente no les convenció ni el de OSX (launchd),
ni otro sistema que también promete que se llama initng y se pusieron a
crear el suyo propio, luego entiendo que dentro de sus aspiraciones
tienen que se como mínimo rendir igual que launchd e initng.


Por cierto hay un paper que tiene que ver con el tema muy muy
interesante que se presento en la Ottawa Linux Symposium y que aún no me
he leído pero que tengo muchas ganas, y que va sobre el uso de suspend
para ahorrar casi todas las fases de inicialización del kernel. En un
principio es un sistema bastante arriesgado, pero claro estaríamos
hablando de pasar a tener tiempos de arranque de mofa. Este sistema es
el que se usa en la PDAs/sistemas empotrados con Linux para poder
arrancar en plan en menos de dos segundos.

> Por cierto, que en edgy han metido un tema de autodetección de
> resoluciones de framebuffer para poner un bootsplash mas bonito y tal.
> En este portelo no llega a pillar la resolución nativa, pero si que
> parece que el framebuffer anda por 1024x768, o algo así, y no la
> clásica resolución cerda que solía tener ubuntu por defecto en el
> arranque.

--- explicación de porque es tan chungo el modo nativo de los portelos
con gráficas intel ---

El tema del modo nativo en las intel esta un poco chungo, supongo que
por eso no podrá usar un modo nativo. De hecho seguramente habrás usado
la app rara esa, la 915resolutionalgo para conseguir el modo nativo de
la pantalla. Bueno pues te vas a mofar, pero el tema esta en que
actualmente no hay soporte nativo en los drivers para poder cambiar el
modo gráfico, y entonces lo que se hace es un hack, que es esa utilidad.
Esa utilidad lo que hace es pillar el modo que tu le indicas, ir a la
BIOS, buscar un modo de la BIOS que no uses o que no sea muy habitual y
reemplazar el modo ese de la BIOS por el modo que tu le indicas, de ese
modo las X pueden usar la BIOS para lograr el modo correcto sin
necesidad de tener soporte en el driver. La buena noticia es que esto ya
funciona, pero aún esta en una rama experimental y esto es porque antes
de que intel no cambiará su filosofía no había specs para poder crear el
driver. La mala noticia es que aún no se ha mergeado la branch al head,
luego... me da un poco de miedo de que no haya modo nativo para cuando
salga Xorg 7.2 que es dentro de dos meses :-S.

--- end explicación ---

De todas maneras odio la framebuffer xDDD, debería arder en el infierno
xDDDD, eso de tener que usar dos drivers para controlar el mismo
hardware es... es... lo peor de lo peor xDDD.
Supongo que este año tocará que se pongan con este tema, Dave Airlie
hizo un nuevo intento hace unos meses de fundir la radeonfb con el
driver drm de la radeon. Con drm me refiero al direct rendering manager,
que es el componente del kernel que actúa como pasarela entre el driver
3D de user-space y el hardware gráfico.

> Pego aqui debajo un resumen de lo que han implementado de esto. La
> verdad es que no entiendo demasiado de lo que pone, pero tiene buena
> pinta eso de poder cambiar de consola clásica a framebuffer on the fly
> :)
> 
> Hala, aqui va:
> 
> ---------------------------------------------------------------------------------------------
> Add binding/unbinding support for the VT console
> 
> This feature adds the ability to detach and attach the framebuffer
> console to and from the vt layer. With this change, it is possible to
> detach fbcon from the console layer. If it is detached, it will
> reattach the boot console driver (which is permanently loaded) back to
> the console layer so the system can continue to work. Similarly, fbcon
> can be reattached to the console layer without having to reload the
> module. Attaching and detaching fbcon is done via sysfs attributes. A
> class device entry for fbcon is created in /sys/class/graphics. The
> two attributes that controls this feature are detach and attach. Two
> other attributes that are piggybacked under /sys/class/graphics/fb[n]
> that are fbcon-specific, 'con_rotate' and 'con_rotate_all' are moved
> to fbcon. They are renamed as 'rotate' and 'rotate_all' respectively.
> Overall, this feature is a great help for developers working in the
> framebuffer or console layer as there is not need to continually
> reboot the kernel for every small change. It is also useful for
> regular users who wants to choose between a graphical console or a
> text console without having to reboot
> 
> ---------------------------------------------------------------------------------------------

Ummmm la verdad es que no estoy muy seguro de como funciona, pero voy a
explicar como __creo yo__ que funciona y cuales __creo yo__ que son los
porques de las limitaciones :

La VT es la virtual terminal, que es la abstracción que hace el kernel
que nos permite ir danzando por consolas a golpe de alt + Fn, en un
principio esa VT puede tener varios modos incluido un modo gráfico que
es por ejemplo el que usa las X, la cosa es que cuando esa VT tiene un
modo no gráfico, esa VT esa gestionada por un driver del kernel que es
quien implementa la consola, la cosa es que puede haber varios drivers
controlando esa consola, lo normal si no hacemos nada es que tengamos
una consola en modo texto de lo más sencilla, pero claro los modos de
texto son de los más cutres teniendo en cuenta las actuales pantallas,
con lo cual existen otros drivers que implementan el mismo interfaz que
ese driver genérico de texto que lo que hacen es configurar un modo
gráfico e implementar una consola, de ese modo podemos tener una consola
en un modo de 1024x768 con una frecuencia de refresco guay del paraguay.
Entre esos drivers gráficos de consola tenemos : vesafb (que usa la BIOS
para establecer el modo gráfico) o radeonfb, mgafb, etc... que son los
drivers nativos para cada tipo de gráfica. 
El tema que comentan aquí es un problema de diseño que tienen los
drivers estos que controlan las Virtual Terminals, y el problema es que
cuando cargas el modulo ese driver pasa a hacerse cargo de la
terminal... y con ello se convierte en imposible descargarlo, y si
intentas hacer un rmmod del modulo no te deja, ni tampoco te permite
cambiarlo por otro. Con lo cual lo que entiendo es que quieren poder
tener flexibilidad a la hora de poner/quitar o cambiar el driver y en
cualquier momento incluso volver al driver simple en modo texto.
La verdad es que puede tener muchas utilidades, una esta claro que es
DirectFB porque esta limitación de no poder cambiar de driver era una
****da, otra podría ser hacer que la framebuffer solo se use durante el
arranque y así hacer que el arranque sea gráfico, pero que se descargue
al pasar a las X para evitar cualquier problema entre la framebuffer y
las X pegándose entre ellos (ya sabéis míticos problemas de tener dos o
tres drivers controlando el mismo hardware a la vez xDD).

De todas maneras tampoco me hagáis mucho caso... si la explicación es un
poco cacao es porque refleja un poco el cacao que yo tengo en la cabeza
sobre el tema xDDDD.

> Y del tema de DirectFB... ¿han conseguido ya ejecutar varias
> aplicaciones a la vez sobre DirectFB sin tener que aplicar el parche
> bestia ese al kernel? 

El problema que tienen es que para correr varios aplicaciones/procesos a
la vez necesitan una IPC (InterProcess Comunication) y no la tienen. La
IPC la usan para por ejemplo notificar los eventos del ratón, y esta IPC
necesita tener un rendimiento excelente para no haya problemas respuesta
(ummm no se como decirlo... que tu pinches a la app y tarde dos
milisegundo en darse cuenta de que has pinchado xD). 
El tema es que las X tienen su propia IPC llamada ICE que esta
construida sobre el protocolo de las X y que encima hereda el sistema de
seguridad de las X, luego este sistema es necesario para que muchas
cosas puedan ser portadas fuera de las X. Un ejemplo son los sistemas de
componentes de Gnome y eso explica porque por ejemplo la mayor parte de
las aplicaciones de gnome que dependen de bonobo no están portadas a
windows (aunque esto ha cambiado hace 2 años, pero esta posibilidad aún
no es muy conocida, ni explotada).
Por lo tanto DirectFB necesita una IPC, y en vez de crear una IPC nueva
construida encima de un socket como hacen la mayoría (d-bus y las X
funcionan así), supongo que por excusa de la optimización decidieron
crear una IPC que funciona a través del kernel.. y claro este parche no
va a entrar ni de coña en Linux, y con ello se convierte en un incordio
bastante serio.
Uno también podría plantear usar d-bus como IPC, pero no valdría porque
sería matar moscas a cañonazos y el rendimiento no sería todo lo
excelente que debiera de ser. Hace tiempo navegando por internet me
encontré con otro sistema gráfico más xDDD, por si ya había pocos y
estos también habían portado GTK y habían desarrollado una IPC, durante
un tiempo medite si me sería factible intentar portar esa IPC para
usarla con DirectFB, pero esta fuera de mi alcance... mis poderes de
programación aún no están a ese nivel.. lo que me hace pensar que
debería investigar menos y estudiar más programación... pero eso es otra
batalla que tengo pendiente xDDD.

De todas maneras tampoco hay muchos proyectos importantes que estén
usando DirectFB sino supongo que esto hubiera sido una prioridad. Uno de
los proyectos importantes es el Debian-Installer, pero solo necesitan
correr una aplicación con lo cual no lo necesitaban.

> Porque si es así... para el 90% de las cosas se
> podrían dejar de lado las X, y tirar de DirectFB, que tira genial, y
> usa muchos menos recursos.

Si es cierto que usa poco recursos, pero también es un sistema muy muy
limitado, e incluso puede que un servidor de las X que use kdrive (una
arquitectura de drivers para sistemas empotrados) sea más óptimo a la
hora de hacer 2D (kdrive tiene una arquitectura de aceleración de
XRender) y Xati (driver para las radeon basado en kdrive) ocupa unos
4MBs.
Otra opción de futuro más interesante aún es mesa-egl, que es una
implementación libre de EGL que es un subconjunto de OpenGL para
dispositivos embebidos. Y de la misma manera que en teoría podrías
correr un Xegl (una versión de Xgl) encima de mesa-egl, también podrías
correr una aplicación de GTK+ que a través de cairo (que soporta como
backend OpenGL) encima de mesa-egl y ahorrarte el Xegl.. hay muchas
opciones encima de la mesa, lo que va a ser el futuro la verdad es que
aún esta bastante abierto ;-)

Buafff como me ha costado terminar el e-mail.. estoy super espeso hoy..
buah y me da la impresión de que he metido la zarpa mil veces xDDD, pero
bueno esto es todo lo que sé y así se lo hemos contado!! xDDDD

Un saludete!!

JonAn.