On Tue, 29 Aug 2000, Andreas Beck wrote:
> Other than Steffen's KGI, we simply don't have a reasonable graphics layer
> that would make sense to include in the kernel. Kgicon is basically just
> another (more portable to alien systems) way to write framebuffer drivers.
> Nothing _Linux_ would need.
*BSD has been ascendant recently. There have been discussions in
the past about using *BSD instead of Linux as the primary KGI development
OS, but nothing ever happened. HURD was also mentioned at one point, as
was Win32(!).
> > and should the GGI team develop a branch of the kernel?
This has also been mentioned in the past. Steffen's new KGI
system is IMHO functional and stable enough for this to work - last time I
checked (mid-June or so), a KGI-patched kernel ran XFree86 3.3.6 servers
flawlessly. Probably _more_ stably than stock kernels do, thanks to the
rewritten console subsystem. However, a set of small but annoying
problems remain which would keep KGI from being a truly 100% drop-in
replacement for fbcon/fbdev/DRI/agpgart/etc in current kernels:
* I never got the 2.3/2.4 port working. Close (it wasn't _that_
difficult), but no cigar. The 2.2 kernel series is still being actively
maintained by Alan Cox, but 2.4 will have several new features (most
notably kiobufs and devfs) which if used by KGI would make the KGI kernel
patches quite a bit smaller and simpler.
* Serial mice don't work with the "stock" KII input drivers (basic PS/2
keyboard and mouse). There's support for Vojtech Pavlik's unified input
device (evdev) system, but the KGI code for this is minimal currently.
* Lots of changes to the Linux console subsystem are on tap for 2.5.
James Simmons manages the new console project, and he is working with
Vojtech to integrate the evdev system with this new console architecture.
Linus seems to be cranking up the politics again, though, so what he'll
allow into 2.5, and in what form, is still very much an open question.
* All the finding and fixing of tons of tiny bugs (which takes lots of
coders and testers) has mostly been left undone (due to lack of coders and
testers). KGI is pretty damn solid, given this circumstance (hats off to
Steffen!), but it really needs a good, solid period of testing and bug
fixing.
* There's a dearth of available KGI driver code. We have a few
proto-drivers for VGA, Permedia, MGA, nVidia and S3 ViRGE chipsets, but
nothing "really solid" yet. KGI's new driver model is quite different
from the driver models of the existing open-source video driver codebases
(XFree86, fbdev, and even KGIcon), and thus driver porting is decidedly
nontrivial. This situation would be fixable with a bit of sustained work
on the VGA driver, as well as a well-working example of exported hardware
accels (Permedia, probably).
* Lack of LibGGI target code for the new KGI system. I whipped up some
quick 'n dirty library code for abstracting the KGI interface
cross-platform (LibKGI), as well as an even quicker n' dirtier (read:
currently nonfunctional) LibGGI target module for KGI which uses LibKGI.
Both of these need to be fleshed out, which won't be too difficult but
will probably require a decently functional VGA driver to test
modesetting, framebuffer mapping, resource mappings and locking, etc. For
testing accelerations, we'll need at least _some_ working accels in _some_
KGI driver code to test against.
In sum, while KGI does require a decent bit of work, it is already
quite far along. Don't give up on it. If you don't already know about
how kick-ass Steffen's design for the new KGI is, or haven't read
Steffen's excellent architectural descriptions of KGI, please head over to
SourceForge and do some KGI browsing. You'll be amazed.
> If someone wants to do this, it might make sense. We maintained patches for
> a long time a long while ago, but as noone seemed to be too interested,
> we started lagging behind kernel changes and finally stopped updating stuff.
I should sit down and make another stab at a 2.4 KGI port. It'll
likely be much easier now that most of the hideous bugs which were present
in the earlier 2.3 kernel series have been stomped.
> > * How well are the relationships with the X team?
>
> Traditionally they haven't been very good. Though we got some nice
> invitations later to help working on the XFree-4.x series. However noone
> here took the opportunity - or rather the big amount of work coupled to it
> ...
XFree86 4.0.1 just isn't stable enough yet, nor is it in
widespread use. It would be a lot of work for relatively little benefit,
since we already have XGGI which works quite well for most purposes. Have
the XFree86 people released a formal DDK for their modular driver system
yet? That would certainly help.
> > And DRI? Is DRI possible under GGI?
>
> Noone has tried yet. According to Steffen DRI is something one shouldn't
> really try ...
Well, it should be workable at a fairly basic level. Like XFree86
4, though, the bulk of the driver code would end up in userspace libraries
(LibGGI target code) since DRI basically just muxes the hardware and
provides basic command queue management and resource locking, etc etc.
Nothing fancy like KGI, which contains a whole new signal flow graph
representation of video hardware, sophisticated accel queue scheduling and
management, etc. If a DRI target was written for LibGGI, such a solution
would probably resemble Marcus' MGA "driver" code which is currently in
libggi/default/fbdev/mga2164w.
> > Is GGI/KGI ending as a curiosity - another kind of graphics library - ,
>
> I am afraid it will - regarding Linux.
Don't be too sure about that. The fact remains, as it has for
several years now: LibGGI+KGI is a FAR better general-purpose graphics
system layer than anything anyone else has yet come up with.
> > or does it have a future as a basic part of Linux?
>
> It has a future, but I assume it will rather be in the embedded systems
> market. It's used quite some there .... ;-).
Oh yeah |->. I recently had the opportunity to show KGIcon and
LibGGI to several groups of embedded Linux folks. As with pretty much all
serious embedded Linux efforts, these people looked into using X, but as
Alan Cox put it on linux-kernel recently, "using X in an embedded
environment is the cause of much mirth, merriment and laughter". When I
showed them LibGGI and KGIcon, they were _ecstatic_.
> Yeah, I know - all that sounds pretty pessimistic.
Sure. But it is far _too_ pessimistic. Trust me. GGI/KGI is
alive and kicking.
> And I always feel pretty
> sad, when it comes to that topic. GGI is "my baby" more than any other open
> source project. And there is quite some blood, sweat and tears I and several
> other people put into it, so it really hurts to see it fall in decay.
I wouldn't call it "decay". I rather consider instead that we
have been in "stealth mode" for a while. That is not a bad thing! We
have fixed bugs, tweaked and tuned some code internals here and there,
kicked out the odd extension such as LibXMI, GGIMesa or LibGWT, produced
some of the best documentation of any open-source project out there, and
basically waited for the rest of the world to catch up with us |->. From
what I have seen of the astonishing growth of embedded Linux recently, I
think our time may finally be here.
>I'm
> pretty busy these days juggling two jobs, so I don't have so much time left
> to work on GGI.
Me either, not since LibXMI which I haven't worked on in months.
> While this is bad for GGI, it helps a little to distract me
> from my "broken heart" about the project's state.
>
> But maybe some folks here would like to cheer me up a little ?
I was quite cheered up when I joined the WINE project (I use WINE
heavily at work). WINE was derided for years because it was a huge
project which never seemed to make much progress. Since the end of last
year, however, WINE's growth has _exploded_, and even software like the M$
VC++ environment is now working! This is because a hell of a lot of
people need WINE for business reasons these days and are thus being paid
to hack WINE recently. In particular, Corel corp. has been a huge
contributor to WINE this year, maybe the largest.
In many ways, the GGI and WINE projects are structurally quite
similar: they both strive to encompass a huge and quite diverse
functionality set, they both are quite modular, they both languished for
years, off and on, because they were "ahead of their time", etc etc etc.
If WINE can experience a resurgence once it's natural time to shine
arrived, GGI certainly can!
> What GGI needs is a driving force.
The failure of XFree86 4 + DRI to produce a suitable graphics
system layer for embedded Linux devices should provide such a force.
People _NEED_ what we have to offer, and that is the bottom line. Our
only serious competitor in this space is SDL, but SDL's design is focused
on providing a clean, consistent gaming API for Loki. If it works in
embedded systems, great, but don't expect it. LibGGI and KGI are designed
for embedded systems (among other things) from step one.
> Look at the mailing list. It's quiet.
> Really quiet. The only postings are a few newbies seeking help or asking for
> features, and from time to time, me, Marcus or a few others that annouce
> a little new feature they coded up, because _they_ needed it.
All long-lived OSS projects go though "down time" periods. I
don't consider this a reflection of the long term health of the GGI
project. If people thought that GGI was dead, they wouldn't _ever_ post.
People use GGI. LOTS of people use GGI. Unfortunately I don't think we
hear about a lot of this, because the basic GGI design is so good that
people can quickly (and successfuly) hack it for use with embedded
devices, and our "commercially attractive" X-style license doesn't require
that their changes be publically released. This isn't _bad_ - the
unrestricted nature of the X-style license is quite attractive to
commercial entities, much more so than the [L]GPL - but it does serve to
keep a lot of GGI use under the radar.
> Come one folks ! A project as big as GGI doesn't live by half a dozen
> semi-active coders. At least we need some _motivation_.
Motivation comes from:
* The opportunity to learn. We have always provided plenty of that |->
* The notion that one is working towards a reasonably possible goal.
Most people want to be reassured that KGI will _eventually_ get into the
Linux kernel, or that LibGGI will _eventually_ be used by gaming
companies, etc etc. This one tends to be a kind of self-fulfilling
prophecy - if GGI is popular, more coders will come to work on it and
therefore it will advance quicker, GOTO 10.
* Having lots of to-do lists hanging around. We need plenty of tasks to
hand for people to dive right into, from lists of pie-in-the-sky
QuickHacks(tm) that almost any coder could quickly throw together, to the
really large, longer-term architectural projects, and everything
in between. I think GGI may intimidate a lot of potential converts.
> Tell us what you need, tell us _that_ you need it, give us a hand
> implementing it, report bugs, and so on
Also:
* PLEASE let the world know, if you can, that your company or project or
whatever is using GGI! I realize that, especially in the embedded
marketplace, people don't want to tip off a competitor to a valuable and
somewhat 'hidden' resource, but please do so to the extent that you can.
Contact a GGI developer privately if necessary, we'll be discreet.
* PLEASE contribute back whatever GGI hacks your company or project makes.
At least the small ones! Our license terms do not _require_ this, but it
would certainly contribute to the long-term growth of a valuable tool.
Again, please contact a GGI developer if you wish to contribute such code
but do not want to be publically identified as the author. I may have
some such contributions to 'gateway' back to to world at large myself
soon....
GGI IS NOT DEAD. Reports of our death have been greatly
exaggerated for years now, on and off. It wasn't true then and it isn't
true now. The bottom line is that GGI/KGI can still do a hell of a lot of
things that _NOTHING ELSE_ out there can do. Period.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
