Re: [Linux-fbdev-devel] The future of framebuffer

[Sven <lu...@dp...>]

On Fri, Sep 28, 2001 at 12:45:24PM +0400, Nick Kurshev wrote:
> Hello, Sven!
> On Fri, 28 Sep 2001 08:28:50 +0200, you wrote:
>=20
> > On Fri, Sep 28, 2001 at 10:20:33AM +0400, Nick Kurshev wrote:
> > > > Huh, why move all the fbdev out, the only thing you need to modul=
arize is the
> > > > fonts used, not the fbdev.
> > > >=20
> > > Because it can be compiled independedly from kernel. Because it is =
like mini-X.
> > > IMHO kernel should have only minimal part of drivers. (finely only =
set of drivers which
> > > should be compiled into kernel for normal working) but such thing a=
s framebuffer, audio
> > > drivers and many other things could be safety moved from kernel out=
 and be as satellite
> > > projects.
> >=20
> > Ah, but if you remove the fbdev from the kernel, many arches have no =
more
> > console, in particular all those laking vga hardware.
> >=20
> > Also you loose the hability to get the penguin logo at boot time, or =
any other
> > graphic that is, which would be a shame.
> >=20
> These things could be handled by vesafb which can't be compiled as modu=
le.
> AFAIK VBE3.0 already have standardized such things as DGA, video extens=
ions
> and even audio interface. Althrough exist cards which don't support VES=
A
> but such cards may not support graphics modes too.

Sure, but you aren't listening, you just plainly ignore all the non-i386
hardware out there, as well as all the older vide ocards. And there are a=
 lot
of graphic cards that are supported but are not VESA 2.=E0 or later compa=
tible.

Also you plainly forget all those where VESA support is somewhat broken.

and if you use vesafb, you already have most of the fbdve infrastructure =
in
anyway, so why not use decent drivers ?

You problem here is only with the fonts, why not use modular fonts that c=
an be
loaded, or even fonts provided by a userland app ?

> > Finally, removing many dirvers from the kernel and having them as ext=
ernal
> > projects is only asking for problems, incompatibilities and bugs. It =
is not a
> > nice thing to do.=20
> >=20
> There may be incompatibility but only if linux internal interface is ch=
anged
> but independed projects will not depend on it. Except case when major v=
ersion of

Sure, but this has not been the case in the past, so ...

> linux will changed but this situation is similar to having different dr=
ivers
> for Win95 and Win2000.

And is the main reason for all those crashes you get in windows : badly
written or plain incompatible drivers.

> In addition it will give possibility to update such drivers without upd=
ating
> the kernel and vice versa.

I can already do that, Or do you think i need to rebuild the kernel each =
time
i change a line in some fbdev driver code ?

> > > > BTW, can't we generate the fonts from the ones used by vgacon ?
> > > >=20
> > > As I've found that linux doesn't contain character images except fr=
amebuffer's font files.
> > > But we can use fs/nls to convert DOS .cpi files to linux fonts. (Si=
nce on russian system
> > > DOS uses 866 codepage but Linux koi8-r). But in this case linux pac=
kage will large of
> > > X package :( But IMHO it would be better th hove possibility to use=
 dos.cpi files directly
> > > from Linux with iconv functionallity.
> >=20
> > Err, not sure i follow you here, but were are the dos.cpi info stored=
, in the
> > vga card rom ? on the vfat filesystem ? in the bios ?
> >=20
> On vfat. But IMHO each computer had preinstalled DOS as they have prein=
stalled Win9x now.

Sure, again, you are i386 centric, i doubt you will get WIn9x preinstalle=
d on
those sparc boxed, or maybe on some older m68k one, or ... ?

> Anyway exist FreeDOS and other similar systems where such files could b=
e taken.

Sure, but there is surely a better solution available ?

Friendly,

Sven Luther