Re: Log summary

[Rodolphe O. <or...@la...>]

On Mon, 23 Sep 2002, Jos Hulzink wrote:

> On Monday 23 September 2002 17:50, Rodolphe Ortalo wrote:
[...]
> > Personnally, I wonder if if wouldn't be as easy to set up a graphic mode
[ at module init ]
> > first (than a VGA text mode). mmap-ed framebuffers are much more
> > convenient than fixed address VGA buffers w/ all the potential collision
> > problems with more than 2 boards.
[...]
> Yeah, specially for it allows us to do more than text, my idea was a text 
> mode, and not a graphics mode :) I prefer a decent kgi core above fancy 3D 
> accellerated "you are multi-headed and your hardware hasn't started smoking 
> yet" screens :)

It could be a nice sentence... :-) However, don't target 3D or animation,
it would probably bloat the kernel with unnecessary complexity (it's not a
screensaver); while I just wanted not to bloat the kernel with tricky code
to manage the inconvenient VGA fixed addressing scheme (in the A0000-BFFFF
area).

After init(), possibly, the most easy from KGI is to setup a simple mode
with a regular framebuffer and use the mmio region via. BTW, while
thinking, even 8bpp is in fact cumbersome (you need to setup the palette)
- 16bpp is probably preferable (and keeps the VRAM requirement decent:
<1Mo even for 800x600). The fallback to 640x400 is probably desirable for
the good old VGA monitors (plus, I'm using one to write this! ;-).

> But frankly, I don't give a damn. It's just that at the moment nothing 
> happens :) Now even the read screen of death is gone, there is absolutely 
> nothing fancy about loading a kgi driver anymore :-P

When we start to make progress with new features, I guess the fancy things
will be back... :-)

In the meantime, this in-kernel code could be useful indeed. After all, if
the kernel tries to setup a simple graphic mode and do some simple display
on it; that could be the most elementary test for a driver module.
 In fact, I often start some complex application just to validate that a
just-compiled module is still functional. It would be convenient if
"insmod" did such a basic test by itself.

Well, what I mean is that it would be useful in fact. And that avoiding
VGA-text may be a good thing (e.g. for the Matrox, VGA-text on a secondary
head is a tricky path in the driver - not the standard code path at all).

Rodolphe