> 1. GGI isn't ready yet (that's what the GGI guys told me theirselves).
Agreed. It's currently in `how close can we push these
halves of Uranium 235 together with our bare hands without blowing
ourselves up' speed of development. Lots of stuff left to hammer
out on the kernel side.
(Our libraries, on the other hand, and pretty solid and
pretty spiff - please don't let the immaturity of the kernel
code keep you from the library side of our endevour - and yes,
Virginia, it libGGI apps will run on X. And SVGAlib. And AAlib.
And IRIX. And FreeBSD. And....)
> 2. The abstract console stuff is multi-platform, and supports both VGA text
> (currently 80x25 only), graphical consoles and GSPs (e.g. TIGA 340x0).
> It's known to work on at least:
> - ia32 (aka i386): VGA text mode (vgacon)
Your only weak spot - no VGA framebuffer.....
> 4. Of course CONFIG_ABSTRACT_CONSOLE is just a config option. We provide a new
> console.c (console.new.c) and some changes in a few other files.
Ditto with the current GGI-EvStack code. It's all a config
option. We even provide in the EvStack branch a `conlinux' linux
console emulation helper to allows SVGAlib and XFree86 to work,
provided you haven't install a KGI display driver.
However, as Geert said, I'm getting ahead of the game here.
GGI/EvStack `Will Be Ready When She's Ready' - namely, at Linux Expo
we (Andreas, Steffen, and I) will be giving talks on our `foolishness'
- I cordially invide you all to come, have a listen, and provide
comments on our project.
Oh, and by the way, I Like VI. I'll pull a paint gun on
any of you Eight Megs And Constantly Swapping lisp-lovers! ;^)
[see http://www.linuxexpo.com for why I said this.]
> Final reason (more emotionally): is there any good reason why the first
> non-Intel port of Linux (for the ignorant: the m68k port) is still not
> completely integrated, while we had all those nice things running back in 1994
> (no typo, one nine nine four!)????
Agreed. This type of well-architected code should have been in
the kernel from v1.0.
> P.S.2. Writing a frame buffer device for one hardwired resolution of a graphics
> board is a piece of cake. Look at tgafb.c for an example... What I'm
> trying to say is that you should be able to write a frame buffer device
> for your Sun in less than an evening.
True. Getting 3 cards in the same machine to work with different
video modes without stepping on each other in an ix86 machine, is a
whole 'nuther ball of wax. Which is one of the reasons behind GGI.
If the IBM PC wasn't such a piece of shite, do you really
think we'd have spent three years on this hairball of a problem? ;^)
-- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground...- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu