From: Alexander Larsson <alla@lysator.liu.se>
  To  : ggi-develop@eskimo.com
  Date: Wed, 09 Sep 1998 20:18:28 +0200

kgi vs. fbcon

I can hardly describe the feel that i had when fbcon was introduced into the 
mainstream kernel and kgicon was working for the first time. That was a good 
time, but time flies, and now with a little perspective on this whole thing 
isee it in another light.

It is obvious that fbcon was created mainly to do one thing, and do it good. 
That is a noble cause, and they did it good. The thing they wanted was to be 
able to get a CONSOLE running on a framebuffer device. The problem is, that is 
not exactly what we (the ggi project) wanted. We wanted a nice, safe way for 
ANY program to access a graphics card from userspace. The secondary effects of 
fbcon, the exporting of the framebuffer to userspace, is of a more limited 
kind than what we were working on.

Here are some pro's and con's for kgi and fbcon: 
(Note that i won't mention acceleration here, as it seems to draw bad blood)

fbcon pros:
* Is in the mainstream kernel, and accepted by linus. 
* Demonstrated to be very architecture independent, runs on all current linux ports.

fbcon cons:
* while we got rid of that ugly iopl(3) from X, it's still not good enough. To keep security up, /dev/fb0 must not be readable/writeable to all. To open the framebuffer X needs higher permissions. This can be done in a number of ways: setuid root X server, have a group 'fb' with trusted users in it, or having a setgid 'fb' X server. Of these, i think the last one seems best, but still, a buffer overrun in X can be used to read secrets from the framebuffer/console. This doesn't just concern X, but any program that wants to do graphics (think quake).
* fbcon can do multihead, but from what i know it can't do true multi-whatever-its-called with two keyboards and two monitors.
* fbcon doesn't have the notion of virtual consoles, so one device controls all vc:s. This means that only one program can open /dev/fb0 at the same time, so no fullscreen quake until you leave X!

kgi pros:
* X, quake, whatever needs NO extra permissions to use gfx.
* you can have 5 gfx-cards and 3 keyboard and connect them to make 3 virtual terminals where two of them are multi-headed.
* You can run graphics programs on all vc:s at the same time, without any problems.
* kgi's driver model is very modular/sofisticated. Making new drivers can be pretty easy if some of the components already exists in other drivers.

kgi cons:
* The kgi patch touches large parts of the kernel. Linus doesn't like this. Also, beacause fbcon is already in the mainstream kernel, kgi will have problems getting accepted.
* kgi has been very intel-centric. I understand steffen's new design runs under PPC too, but it looses hands on to fbcon in this respect.
 

Now, this all mess isn't necesarily all that bad. 
There is still a solution that works for all of us:

The kgi driver model is designed to be quite flexible in regards to the host os. This is the reason that it was so easy to create kgicon. When steffens new kgi is done, we can port all current driver over to that driver model and then convert fbcon-kgi to use the new model. 

This would give us the best of both worlds: mainstream 2.2 kernels can use kgi (kgicon) without needing patches, and we can continue to refine kgi and try to get it into 2.3.x (or just as separate patches YMMW).

/ Alex

 Ps. don't kill me if i got something wrong....