Re: GGI, EGCS/PGCC, Kernel source

Stefan Mars (mars@lysator.liu.se)
Mon, 23 Feb 1998 12:04:44 +0100 (MET)


Here's an idea..

Why don't we wait until we in the GGI project are ready, before we start
this discussion. We understand that GGI is still to immature, and not yet
ready to be included into the mainstream kernel. However, we are aiming
for including it into 2.3.

If you are interested in the internals of GGI, then please come over and
visit us, our www page http://www.ggi-project.org will provide you with
all information of where to find us (mailinglists and such).

We will also be at LinuxExpo 98 to present our ideas for those who wants
to meet us in person.

But in short, while I am happy to see that at least some people really
wants us, I do consider it way to early to hold this discussion.

-Stefan
stefan.mars@ggi-project.org

On 23 Feb 1998, Jes Degn Soerensen wrote:

> >>>>> "linker" == <linker@nightshade.ml.org> writes:
>
> linker> I agree that GGI seems a bit 'bulkey' but it's obvious (from
> linker> looking at their snapshots) that they have done TONS of work
> linker> to make it as small and clean as possible.
>
> linker> Part of the reason it's so complicated is because of all the
> linker> things it does.. I really dont think that it's anymore
> linker> complicated then the network subsytem.
>
> Well the network subsystem is allowed to be complex because the
> protocol handling is complex, it is not necessarily the same for a
> graphics subsystem.
>
> linker> Here are some of the things they are shooting at..
>
> linker> *Output device abstraction *Input device independence
> linker> *Platform indepence *Kernel Level Hardware control (most
> linker> IMPORTANT part.. IHMO )
>
> Well you cannot make 100% abstraction inside the kernel without making
> things bloated _and_ slow. This discussion has been at linux-kernel
> before, however basically a kernel graphics abstrction interface needs
> to be able to set the video modes and run some sort of console,
> ie. for framebuffer consoles it makes sense to use an optional blitter
> for scrolling and clearing the screen, ie. the functions necessary to
> make the console fast and nothing else. Anything that needs to run in
> graphics mode such as X, svgalib and similar apps. should deal with
> this in user space to achive maximum performance. The kernel interface
> should not in any way provide a generic blitter interface or anything
> like that, but I don't think the GGI guys are trying to do that
> anymore.
>
> linker> *Mutiple input/output devices
>
> Hounestly I don't see the need for connecting 7 keyboards and monitors
> to a PC.
>
> linker> *Multihead from the consol level up..
>
> fbdev does this already.
>
> linger> *High performance
>
> Well this might be better now, but back when Geert tried to port the
> GGI console to the m68k `performance' was not on the list of words
> describing the result. Of course things may have improved a lot here.
>
> linker> *Access to fancy hardware features (this is tough when you
> linker> consider they are trying to be abstract)
>
> Again, it is very important to consider what actually needs to go into
> the kernel and what should and can be kept in user space.
>
> linker> Can you think of a better way of say poping in two pci video
> linker> cards and two keyboards (one on the ps2mouse port) and two
> linker> mice and having a single computer act as two for all apps in a
> linker> transparent way?
>
> Do we need this, do anybody actually want this?
>
> Besides fbdev handles multiple consoles on arbitrary devices, the only
> thing you need to add is multiple keyboard support.
>
> Again, I am not fully uptodate on GGI, a lot of the things in GGI are
> most likely done the right way. What I am after is just that we should
> keep things simple, and only put the necessary things into the kernel.
>
> Jes
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>

/-----------------------------------------------------------------------------\
| Stefan Mars |Student, Applied physics & Electrical engineering |
| Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology |
| S-584 36 Linkoping | |
| Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 |
|-----------------------------------------------------------------------------|
| Maintainer of The THX Home Cinema Buyers Guide, located at |
| http://www.lysator.liu.se/%7Emars/thxguide.html |
\--------------------- PGP key available through finger ----------------------/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu