[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Web Browser Svgalib]



Guenas

On Wed, Feb 16, 2000 at 01:21:30PM +0100, Grzegorz Adam Hankiewicz wrote:
>El framebuffer es un "fichero" /dev/fbx que simula la memoria gráfica de
>la tarjeta de vídeo instalada. Esto quiere decir que leyendo y escribiendo
>el fichero, se modifica la pantalla. Las ventajas de abstracción son
>evidentes.
>
>Ahora bien, para cada tarjeta hace falta código específico que cambie la
>resolución (tu puedes escribir en el framebuffer como si la pantalla
>estuviese a 1024x768, pero si está a 320x200, mal asunto). 
>
>Es por esto que hace falta un driver o como lo quieras llamar (a mí me
>gusta módulo), que controle estas operaciones "físicas". Por ahora sólo
>hay 3 o 4 módulos nativos, las matrox, ati y creo que algo más. En la
>nueva serie de kernel 2.4 habrá muchos más módulos (eso dicen). 

Seria interesante saber cuantas son esas muchas mas, y sobre todo cuales.
Masplico: un navegador del tipo que estamos hablando seria una joyita para
equipos antiguos, con tarjetas que hace tiempo que no se llevan ni fabrican.
No creo que ese tipo de tarjetas vayan a tener un soporte demasiado "expreso".

>Como esto no existe para cada tarjeta, se ha creado un "módulo parche",
>que usa las características VESA de cada tarjeta para cambiar la
>resolución. Dado que para usar VESA hay que usar BIOS, ésto sólo se puede
>hacer una vez antes de arrancar linux. Resultado: obtienes un framebuffer
>con cualquier tarjeta que soporte VESA 2.0 pero te quedas en esa
>resolución hasta que resetees el ordenador.

Y las tarjetas mas antiguas no ven VESA 2.0 ni en pintura.

>> 2. Un navegador en consola vendria bien en muchos casos, pero el mas evidente
>> es el de equipos pequeños y/o antiguos, en los que las X no van muy alla y el
>> Netscape es una tortura.
>
>¿Algún problema con eso? Si un navegador funciona en mi 386, lo sigo
>prefiriendo en mi PII antes que el netscape, dado que consume menos
>recursos.

Ya, lo que pasa es que en el PII es tu opcion, mientras que en el 386 seria la
unica alternativa (si quieres graficos, claro). A mi me vendria de maravilla
en el curro, en un PII433 Celeron con 64Mb RAM, pero reconozco que donde seria
un puntazo total es en un 386 con 8Mb, por ejemplo.

>Exácto. Todavía hay poco soporte para esta maravilla del framebuffer, pero
>va cambiando. Una de las ventajas del framebuffer es que un programa que
>lo use funcionará en una Sparc, como un PowerPC, un PC, o cualquier otra
>cosa que lo emule. Si mal no me acuerdo, los Psion serie cinco usan
>framebuffer (en escala de 4 grises, creo) para usar una versión de Linux,
>y así todos los programas funcionan con ellos.

¿Que mas posibilidades nos brindarian alta portabilidad? Es que es algo a
tener en cuenta.

>El framebuffer de mi matrox añade unos 60Kb a mi kernel. Si eso lo usas
>para deshacerte de todo un servidor XSVGAlib, creo que has ganado en
>espacio. Además, que uses framebuffer no hace que tu sistema vaya lento
>necesariamente, depende del programa y cómo use la pantalla.

Me referia mas a que la mayoria de minilinux siguen trabajando con kernels de
la serie 2.0 y libc5, y a que tambien muchos de ellos no incluyen X.


-- 
 -----------------------------------------
 | POWERED BY Debian 2.1 - Kernel 2.2.14 | 
 | Andres Herrera  User Reg. N.66054     |
 | aherrer@clientes.unicaja.es           |
 | Grupo LIMA     http://lima.telenet.es | 
 -----------------------------------------

Attachment: pgppPksYsPDgm.pgp
Description: PGP signature


Reply to: