lkml.org 
[lkml]   [1998]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: GGI, EGCS/PGCC, Kernel source
From
Date
>>>>> "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

\
 
 \ /
  Last update: 2005-03-22 13:41    [from the cache]
©2003-2011 Jasper Spaans