Index:
[thread]
[date]
[subject]
[author]
From: Jon M. Taylor <taylorj@ecs.csus.edu>
To : ggi-develop@eskimo.com
Date: Wed, 29 Jul 1998 13:17:18 -0700 (PDT)
Re: I've seen the stars too... [Re: kgicon, etc]
On Wed, 29 Jul 1998, Rodolphe Ortalo wrote:
> >> > >IIRC it's a known problem (since the kernel's driver will already have
> >> > >claimed the vga space). The #if 0 is alright in the short term, I'm not
> >> > >sure what exactly should be done in the long term...
> >
> >Write a proper console driver that doesn't claim these ports.
> > [...]
> >You know, my opinion about the console code can't be printed, can not
> >even be said in front of an audience. To say the least, it's a mess.
>
> I don't know the current console code of linux. I only know the one
> of KGI. ;-)) So I cannot say...
I know about it, although I am not an expert.
> Do you mean it is possible to write cleanly a multi-headed,
Yes. Insert new fbcon drivers and use con2fbmap to migrate only
some, not all, of the console to the new driver. There's your multihead.
> multiple
> inputs capable
No. AFAIK fbcon consoles cannot be switched to use different
input devices.
> console system without EvStacks ? ;-)))
> Maybe then we don't need EvStacks in fact then ?
> BTW: I'm wondering, couldn't it be that earth is flat also... ?
EvStack/GGI console is light-years ahead of fbcon. But remember,
fbcon is not meant to be revolutionary. Geert invented(?) fbcon to
implement the traditional linux console on framebuffer devices.
> >The KGI i386 boot display driver code doesn't use more than
> >a plain frame buffer. And it is shut up when a real driver loads.
> >That's why I am skeptical about the kgicon approach, but hey,
> >I am willing to learn.
>
> The only interest I find in kgicon is that fact that it allows me to
> use a standard kernel to develop my KGI drivers NOW (because, aheemmm,
> currently it is difficult to develop with a KGI patch inside...).
It is convenient. It allows to separate the driver development
from the console development (and rom the input device development as
well), which IMHO is a good thing. Not all people want to work on all
those things at the same time. For example, now that I am working on
kgicon, I can turn on DEBUG_LEVEL=3 in all the drivers and it will not
lock up my system! That always slowed down my development before, when I
was forced to use KGI's console to use KGI drivers.
> I know I should be working on libgwt instead of playing with my graphic
> card, but well, you know...
>
> The other interest is that it will allow us to distribute our code
> without requiring users to patch their kernel (a thing that seems
> to be associated with a sacrilege).
It is a PITA which many people did not want to deal with.
> But well, with a fully operational KGI kernel, I guess we will someday
> do the opposite: a /dev/fb emulation layer for KGI.
I would rather see the Linux fbcon system tweaked to be able to
use /dev/graphic (KGI) directly instead of /dev/fb (fbdev).
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
Index:
[thread]
[date]
[subject]
[author]