Re: GGI, EGCS/PGCC, Kernel source

Jon M. Taylor (
Wed, 25 Feb 1998 12:19:55 -0800 (PST)

On 25 Feb 1998, Jes Degn Soerensen wrote:

> >>>>> "Stefan" == Stefan Mars <> writes:
> Stefan> On 24 Feb 1998, Jes Degn Soerensen wrote:
> >> Then show us what needs to go into the kernel .... OpenGL does
> >> not.
> Stefan> *heartattack* Geez, whatever gave you the impression that we
> Stefan> are trying to put OpenGL into the kernel?? trust me, we are
> Stefan> not.
> One of the previous posters said that kernel support was needed. I
> have been looking at some of the web pages and it is not exacly clear
> to me what will go into the kernel and what will not.

The general rule: what goes into the kernel is the minimum
necessary code to do all of the following safely:

* Set modes
* mmap() linear or pseudo-linear framebuffers on devices that have them
* fire accelerations
* Hook interrupts on devices that have them

The problem lies in the fact that what constitutes "safe" is
quite different from card to card. Old cards with no acceleration are
pretty safe. So are the lovely high-end SGI cards that have been
discussed on this list recently, because they were designed to work
smoothly with a modern multitasking OS.

In between, though, you have the accelerated cards of the past
five or so years that are all wildly different in terms of design,
capabilities, and bugs. Each of these has to be handled differently. On
some you have to put a fair amount of wrapper code in the kernel around
the raw acceleration ops, because they can access memory at will or crash
the bus or other such fun things if mis-programmed. Others need much
less handholding. Some cards have wierd bugs that must be worked around
in the kernel. And when multiheading comes into the picture, the
possible interactions between combinations of cards must be taken into

The only way to impose any kind of sanity on this chaos while
still keeping kernel bloat down and not sacrificing speed and access to
all the card's features is to not impose a uniform API on the kernel
vidoe drivers beyond what is necessary. What is necessary to keep
standardized is:

* The concept of a console in general
* Textmodes as distinct from graphics modes
* Framebuffers
* Accelerations

Yes, this does look a lot like fbcons.c. However, fbcons.c is a
bit limited. It does not seem to support *arbitrary* acceleration, which
we consider vital and necessary. It is a creature of the "anything more
than basic text16 support should be in X" mindset.

> Will you use user space access to video registers when these can be
> memory mapped and kernel access for boards that do only support the
> old brain-damaged port IO? Or will you do all access to the video
> boards' registers using ioctls in kernel space? (for me it doesn't
> make a difference whether kernel space is something compiled into the
> kernel statically or if it is a loadable module - it is all kernel
> context).

Again, the operative word is "safe". Is it safe to give userspace
access to XYZ? Will it potentially compromise system stability? For
most VGA-style video cards, the answer is no. For example, many cards
have registers which are write-only. If the kernel cannot maintain a
soft copy of these registers, it loses its ability to track the state of
the hardware. Also, incorrectly programming the registers can easily
lock the system cold. The same is less often true of newer MMIO schemes,
but by no means eliminated. The decisions about what to export to
userspace and what to leave in the kernel HAVE to be made on a
case-by-case basis.

> Stefan> Living in kernel space is also our drivers, and just like any
> Stefan> other system they can be compiled in or loaded as a
> Stefan> module. The drivers knows about their hardware, and exports
> Stefan> some ioctl calls, some general, some specific to the
> Stefan> hardwarde, in order to let userland change modes, use
> Stefan> acceleration etc.
> Acceleration in kernel space using ioctls, sorry but no thank you.

Yep. Ioctls are too slow. At least if you consider one ioctl
per accel request. Bundling/queueing commands will help a lot but is not
a magic bullet. EvStack is supposed to be the final solution to this
problem, by allowing very high-speed message pipes between the kernel and

> If
> you want performance you still need to let the user-space applications
> such as X and svgalib type things (is that what ggilib is?) access the
> hardware directly. If it requires apps to be suid root in order to
> access IO-ports then it is just the price you have to pay IMHO.

Even if you want to allow userspace apps to hit the hardware
directly, at least give people a choice! If they want to sacrifice a bit
of stability to get an extra 20 fps in Quake (and they are the admin),
fine! But that doesn't mean that someone that wants to use Netscape/X on
a server machine should have to worry about killing his server if he
switches VCs too fast, either. FWIW, GGI members seem to have come round
to admitting that people should be given the above choice, and preumably
at some point in the future the KGI drivers will be altered to give them
the ability to export themselves directly to userspace.

But, and I think that this is *critically* important, STABILITY
COMES BEFORE PERFORMANCE. I am amazed that the same people that flog
Linux (rightly) as a superior, stable server OS are willing to live with
the stability problems that come with X on Linux currently. Sorry, but
"don't run X on the server" is not a good response. That is the kind of
BS cop-out that the windows world uses to excuse NT's poor stability.

> Stefan> Hmm.. I am not going to spam the mailing list with a large gif
> Stefan> (or was it jpeg?), but if you go to our www pages at
> Stefan>, and then look under
> Stefan> documentation/"overheads from linux kongress" (the link isn't
> Stefan> called that, you will have to read a little), then you will
> Stefan> find a speed comparision between Xggi and the S3 Xserver.
> Well I didn't look closely at the X server performance comparisons,
> and frankly I need a usable console before I will even consider X
> performance.

EvStack will give Linux an almost infinitely flexible console
scheme. Thus, people stopped developing the KGI console code in favor of
EvStack development. I admit that the current KGI console is kinda

> Stefan> So, please, come and have a look for yourself. If you feel
> Stefan> that we are doing something good, then please tell us and
> Stefan> linux-kernel so. If you feel something should be done
> Stefan> otherwise we will listen to that too.
> I've been there now, any well maybe I didn't look close enough, but I
> didn't find a lot of information that convinced me that GGI is the
> ultimate solution in the end. All the things about input devices etc.,
> I do not see why they have to be part of a graphics library, but still
> it looks like nice things to implement for the kernel.

You have hit upon the reason for EvStack's existence. In the
process of revamping the console code to accomodate graphics devices, it
became apparent that the existing, traditional scheme just wasn't flexible
enough to accomodate arbitrarily complex input and output devices.
Consider the following scenario:

* One physical computer
* Three local displays:
* A traditional dumb SVGA card
* A newer SVGA card with TV tuner input capability
* A powerful 3D card with no built-in textmodes
* Three USB keyboards, each with a different keymap
* Two mice, a spaceorb 360, a digitizing pad and a scanner - all USB devices
* A nice sound card
* And an arbitrary number of networked users that all want to be able to
run any local console app remotely.

Now suppose that each console can have its own video mode or
textmode, and each textmode can have a different font set, palette,
resolution, mouse cursor, etc etc etc. How do you handle all of that with
a traditional UNIX console, handle it cleanly, and not have to sacrifice
any interoperability or hardware features? You don't, basically. A far
more flexible scheme is needed, one that is based on message passing and
thus is free of limitations on the forms of input and output that can be
handled, and the relationships of IO devices (and groups of devices) to
each other.

> >> I do agree entirely with Alan when he says that bits from both
> >> camps will be the right solution in the end.
> Stefan> Ok, what specific bits?
> I belive that having video-mode switching in the kernel is a good
> thing, and it is mandatory for some architectures. Your driver
> architecture which splits the handling of the seperate chips is quite
> similar to what I would like to do and you have a lot more low-level
> driver code than we have for obvious reasons.
> Having some sort of standard user space library to handle video acces
> is also a nice idea, and I don't mind having the X server built on top
> of this. However, I still belive that all the acceleration details has
> to go into the user space library and not the kernel.

See above. PC video hardware is buggy.

> However, how are you going to deal with architectures that do not have
> VGA-style text-modes for the console

Emulate them in software, just like fbcons.c does.

> and how will you deal with weido
> devices such as TIGA boards?

You mean devices without framebuffers? Not sure, to be honest.
Obviously it is possible, because fbcons.c can do it. KGI can always
ride on top of fbcons.c like it already does for m68k, but that only
takes care of textmodes.

'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to