From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : mvojkovi@ucsd.edu
  Date: Thu, 5 Aug 1999 20:22:35 +0200

Regarding GGI and Xfree 4.0, Forwarded.

Hello !

I was forwarded the following mail, and I'd like to comment on it.

Feel free to forward this to the XFree Mailing lists, if you like.

I think there is too much confusion around the whole topic, and I'd like to
have at least the XFree people informed about what is true and what not.

> Date: Thu, 29 Jul 1999 11:56:17 -0700 (PDT)
> From: Mark Vojkovich <mvojkovi@ucsd.edu>
> To: devel@XFree86.Org
> Subject: Re: ROM BIOS
> 
> On Thu, 29 Jul 1999 core@triton.net wrote:
> > Has GGI not already implemented a non-os-specific non-architecture-specific
> > multiscreen capable, standardized video card interface?

Yes. It has. We call it KGI, and it is known to run on at least two OSes
which differ completely in design. One of them is Linux, the other I am not
yet allowed to talk about, as it is commercial.

Drivers for both OSes build from the same source, just linking with a
different glue layer to interface with the OS communications mechanisms.

> > I have noticed that no discussion of GGI has taken place recently on this
> > list, I am fairly new to this list...

> Perhaps that's because most people here thing GGI is a bad idea?

I hope I can rectify a few of the misconceptions of GGI/KGI that exist out
there, and that make many clued people think it is a bad idea. 
I would probably think the same, if my knowledge was based on the rumors
that are out there, and I admit, that our "propaganda" branch will need
to be improved very much to do away with them. So it is not your fault 
to be misinformed about some of the concepts of GGI/KGI. We are not too 
good at marketing.

First of all, I'd like to point out, that GGI and KGI are different.

GGI is the parent project, part of which is KGI, which is our HW-independent
graphics interface.

We called it KGI (kernel graphics interface), because graphics card
programming required priviledged access, which is usually done in kernel
mode, and that is, what KGI drivers were designed for.

However it is of no concern for a KGI driver, in what protection ring it
runs. The suidKGI target we had, employed a different OS-layer that allowed
the KGI driver to run in usermode on Linux, just like XFree or SVGAlib do.

The KGI driver does not care about its execution environment, as the OS-
interfacing layer takes care about how exactly say an IO-access is 
accomplished or a request is relayed to the driver.

> > GGI also provides transparent acceleration(currently 2D only), and 
> > because it exists in kernel space 

It can exist in kernel space, but this is not necessary. If for some reason,
you want to run it in userspace, you can. No problem.

This is why we have offered some XFree people (Dirk Hohndel and Harald Koenig
for example) several times to write an XFree "OS-layer" that would wrap up a
KGI driver into an XFree driver.

Early XFree driver designs (mode setup still done by the server, only accel
done by a module) somewhat defeated that, but to my knowledge (which might
be wrong, as I am no XFree developer and so I only hear some thing here and
there) the new XFree 4.0 module scheme would allow it.

Is that right ? I.e. the full graphics driver is in the module now ?

> it would allow direct access to 3D accel functions,

This is in deed problematic in userspace. You will need at least a bit of
kernel help, as you will want to use DMA and IRQs for full performance of
the whole system.

Please note the "of the whole system". I do know, that polled operation is
possible with many cards and is often even the fastest method with respect
to the speed of graphics operations. However it is a waste of CPU (for
long operations, which are rather common with modern 3D cards that have
large FIFOs and can do complex operations) to poll for accel-ready, if 
we could as well wait for an IRQ to come in and calculate a few more
polygons in the meantime.

> which I beleive would be out of place in the Xserver... I think that X should
> move towords implementing a single server ontop of GGI, 

Such a server exists. It is called XGGI.

However we have to make a distinction here:

XGGI uses LibGGI which gives it an even broader scope. It will not only run
using the hardware drivers KGI provides, but as well on anything that LibGGI
supports, which includes another X server (or itself), the linux fbdev
device, SVGAlib, memory areas, shared memory, libaa, ...

This flexibility in the library allows for some cool stuff like having no
need for Xnest, Xvfb or similar or running on the sides of the ggi cube, 
but ...

... this is probably not, what Xfree would be very interested in.

I think the area where we really should cooperate is the hardware drivers.

The point is : XFree is a great piece of software, it works well, and I
liked to use it (the prime reason I don't use it now, is a strange bug in
the Glint server that locked my machine 10% of the time at startx, what 
leaves me with XGGI running on the KGI permedia driver).

But there are times, when you want to do graphics, but you don't want to
start X for it. Games are one example, file viewers often as well.

Thus compiling the graphics drivers into the X server was IMHO not a very 
good idea. O.K. you had a great X server, but what about the other tasks ?

Even with todays machines, starting up an X server with WM and all takes a
few seconds as opposed to the time the monitor needs to resync when I press
F3 on a graphics file in mc with a non-X direct graphics access system.

Now that Xfree encapsulates the drivers in modules, it becomes more feasible
to use them in a more direct fashion for the above purposes.

> and that all of the driver development should move to ggi, 

This I don't care much about, but I would really appreciate, if we could
cooperate on that matter. One of our coders seems willing to try to make a
wrapper for your XFree driver modules, that will allow LibGGI to access
them. He says, this seems to be a not-so-easy task, as he will have to 
satisfy many external references, but he will try. 
If he succeeeds, this will allow LibGGI to use the XFree drivers 
"standalone", putting them to good use for such situations.

I would like, if we could mutually use our drivers. The benefit for you will
not be too big, as you have a vast driver base.

However if you had a look at KGI, maybe you like the concept. If the above
developer is right, it might be simpler to write KGI drivers than XFree
drivers, so maybe on a long term basis, you might want to move there.
But I won't judge about that now.

> The fastest approach is having the Xserver access the hardware
> directly.

This is definitely correct. However it locks you out of using IRQs and DMA
and thus it as well hinders performance. I know, that one can hack around
that a little, but after all, these remain hacks.

Moreover on a well designed card, nothing holds us back to export the IO
areas of that card to userspace. This way the X server can be just as fast
as it always was.

The problem is, that with almost all cards, hitting the card registers 
directly is a security critical operation. The X server can be considered 
a trusted binary and thus be allowed such things. 

"Normal" apps, which are also in the scope of GGI cannot be allowed to do
that. Noone wants an untrusted binary to run as root and noone wants
non-root to be able to crash the machine or render the display unuseable
until the next reboot.

Thus by default we do not allow unpriviledged register access in KGI but go
through the driver for validation.

Having said that, I see no problem whatsoever to ask the KGI driver to
export the accelerator registers to userspace, which it will grant given
sufficient permission of the caller. As this permission check is done in
the OS-layer, one can even customize it. This might allow the X server to
run without suid priviledges, just like XGGI does, at full performance, by
e.g. using a special group or some other authentication scheme (say knowing
a system cookie, being able to open a particular file, ...).

> GGI advocates don't understand the performance implications
> of what they are suggesting.

We definitely understand these implications, and we have put serious thought
into solving this issue as far as possible. Most concepts we employ in this
area are very similar to what you can read up in several SGI articles about
their graphics architecture, though we had to invent some additional
schemes, as we don't have the advantage of always having very well designed
graphics hardware. 

> > Also for those who might be against this, GGI is a very small kernel module,

Let me correct this : KGI drivers can be loaded as a pretty small kernel
module. You can as well use them SUID in userland, if you wish.

As this seems to be a more or less religious issue for many, I'd like to
point that out again.

> > most of its support(acceleration) resides in user space as a shared library,

This depends on the driver. KGI drivers can usually do the most common
accelerations inside the driver thus allowing to accelerate stuff in a
generic way and to accelerate drawing for untrusted binaries that you cannot
allow to map the acceleration registers.

However for some drivers, exporting and mapping the accel registers from
userspace is implemented, giving you the very same speed for drawing
operations, with at least less possibility for a malign application to 
harm the system, as mode setup registers stay protected, as this is not
timing-critical.

> > and it is orginized is a modular fasion, very compatible with XFree86 4.0's
> > structure...

This is nice to hear.

>    I gave the GGI folks a personal invitation to join XFree86 
> to work on a GGI driver for XFree86 4.0.  They declined.

Could you tell me whom you talked to ? I would remember, except if I was
struck by some mental disease recently, as would Steffen.
We are the project leaders, which are probably the most straightforward
persons to ask. Most of our other active developers also said they didn't
get anything like this. Maybe Marcus, whom we can't ask right now, as he's
on vacation, but I remember him saying that he wanted to do that anyway.

We would of course like to work on such a driver, and as said, we will
probably even have a developer for it.

And we would as well appreciate, if someone of your developers set out to 
write a KGI wrapper for the XFree module system. I will gladly try to assist
him personally with the necessary knowledge about how to write KGI OS-layers.

> I'm certainly not going to write a GGI driver; I don't even like GGI.

O.K. - I accept that as your personal opinion, though I hope I have moved
your position a little.

> And if the GGI folks don't even want to write a GGI driver for XFree86 4.0...

We do. Please tell us whom to contact, what to do, ... and we will find
a developer that does.

Again: 

We would really like to cooperate with XFree. Even though we have been 
severely bashed by some members in the past. 

If you look at LibGGI, you will see, that we are open to all systems 
out there, and we try to build bridges between the worlds. 

Using LibGGI you can run SVGAlib apps under X, an X server on SVGAlib, 
arbitrary LibGGI programs on the sides of a spinning cube, ... whatever.

Please let us try to work together instead of each on his own and maybe 
even against one another. We are already fighting a hard battle against
hardware vendors and commercial drivers. We shouldn't waste our time
with unneeded battle against each other.

CU, Andy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =