As I spent pretty much time coding for the GGI Project I fell I should
state my opinions and point of view about the topics discussed here with
much passion.
First GGI is *not* meant to become a X server in kernel space. All it
should do is to provide a uniform interface between display and sensor hardware
and applications. Thus making GGI part of the kernel would mean to have
a uniform interface to pointing hardware (please tell me why (e.g.) does an
application have to worry about the mouse protocols and why are there more than
one place to configure mice? A kernel can and _should_ hide this.),
displays (yes, *multiple* displays) etc. Just like drivers for block devices this
needs kernel support (at least be running in kernel mode). Why to treat display
hardware different than any other hardware???
This would mean that the ten or so X drawing primitives have to become implemented
with kernel support as well as support for mice etc. The current binaries that do
mainly mode initialisation are about 30K thus you wouldn't end up with 2-4MB modules
as was stated earlier in this thread.
On top of this a X server should be built that interfaces only to GGI. There are
a lot of things like window management, communication to clients etc. that contribue
to code size but I think the MB of code come from (unneccessary with GGI) support
of different chipsets.
Linus Torvalds wrote:
>
> > On Mon, 3 Jun 1996, Linus Torvalds wrote:
> >
> > > We HAVE a uniform graphics API already. It's called X.
Yes it is. That's why GGI will be as close to X as possible. Perhaps it could
be even possible to hide from some GGI applications if they are running with or
without X.
> >
> > True, however XFree86 (and any other brand running on linux) could be much
> > improved by taking the low-level routines and placing them into the
> > kernel.
>
> Now _this_ is a valid approach - if Linux can help Xfree86 in any real way to
> make a better X server, things are different.
>
> However, I don't think the XFree86 people want to lock themselves into a
> Linux-centric world-view (the same way there exists other hardware than just
> PC's, there also seems to exist some other OS's than Linux. Strange, I know,
> but I have people I'd consider reliable (albeit strang) report such things to
> me).
I think they wouldn't not is this neccessary. As the current plans are, GGI will
be desingned so that a X server would just have to keep track of the GC and Drawables
and call GGI functions with approriate parameters. XFree needs to do this anyway
so there should be no impossible design changes.
> As such, the move to add functionality to Linux to help make XFree86 better is
> not likely to be universally liked even by the XFree86 people. And rightly so.
That's what is a main goal of GGI. However, why not to create a platform independent
low level API for other applications too? X will have to interface to this kernel
functionality anyway and if X does other apps could as well. And, if well done
this could also give companies (like Matrox) a opportunity to have simple support
for linux. Just a KLM like drivers for other OS's would suffice. So Linux and XFree
wouldn't have to worry about every new card around.
> There may be some specific feature we can add to the kernel to make it easier
> for the XFree people to develop X, and then I'll do it. If that happens to help
> other projects too I'm all the happier - the mark of a good design is that it
> works for lots of different things.
As does GGI. Having kernel control of display hardware would not only
ease implementation of X but also allow to have better console handling and
stability (as we could perform VC switches *without* asking any user mode app
for permission to do so).
> > It makes user-level things a hell of a lot easier to program, and
> > the easier it is to program in, the more programmers you're going to get
> > doing it. Why do programmers still support MegaSucky "OS"'s (using that
> > term loosly ;) ? Because they're easy to program in!
>
> Umm.. The above doesn't follow.
>
> Changing the kernel to support XFree86 more wouldn't change the _user_ program
> interface in the least. The X protocol is a standard protocol, and that part
> wouldn't change..
It wouldn't, but user programs could be written to interface either directly to
the hardware (on low memory machines) or to X via GGI. without a line of code
being changed. And, if applications want to use special hardware without X, why not?
> (There _are_ XFree86-specific features, like the direct frame buffer
> extensions, and the people who worked on that contacted me about perhaps doing
> kernel stuff for it. They seemed to have ended up it without any kernel changes
> though)
> > > When you argue for kernel support for graphics, you argue _against_ the
> > > already existing, standard UNIX graphics API that does a hell of a lot
> > > more than some stupid frame buffer.
You don't. You argue for easier, from the server's point of view hardware independent
implementation and configuration of the already existing, standard UNIX graphics API.
The hell of a lot more than the framebuffer is still done by the X server but
interaceing hardware is the kernels task. Think of using interrupts etc on
multimedia hardware to come (only to mention video capture boeard etc).
> > Not really.. I think the point is that the kernel drivers do all the
> > low-level stuff that requires kernel/superuser privs, and any user-level
> > program that wishes to perform these functions must call the kernel
> > routines to do it for them. It's not meant to be a REPLACEMENT for X,
> > after all, what CAN replace X? :) Think about it - there will be no
> > need for a million & one setuid-0 X server binaries that are 2-3Mb in
> > size! One generic server would be enough, which calls the kernel to do
> > the card-specific routines, and hence doesn't need to be setuid-0.
>
> Umm.. I fail to see the advantage.
3MB binary to be selected from a dozen files vs. a 90KB KLM that might be delivered
with your graphics card and a generic 1.5MB binary?
For me it makes a difference of 1.5MB disk space and one or two hours spent
configuring X .
> On the machines I use, I _already_ have just one X server binary. Admittedly I
> chose that one from a larger set of binaries, but what is the relevance of this
> point? We need to have different drivers _anyway_, and having them as separate
> X servers is a lot easier than having them as separate kernels..
The final design of GGI is thought to consist of a kernel part that does all the
management and console interfacing/control and a set of modules for each graphics
card or input device. There will be *one* kernel in terms of GGI.
> XFree86 already _does_ the graphics stuff, and I see very little advantage to
> moving any of that into the kernel. When _they_ approach me and tell me that
> they'd like some more features, I'll take it into consideration, though.
>
> Linus
So the GGI people and I will go on beside the main kernel development. But
I will go on as I know it will improve Linux. If not yet so perhaps once
we got it further to show a working solution.
Steffen
Note: please send a CC to seeger@physik.tu-chemnitz.de with any reply. Thanks.