> > Another topic that I missed was, why did kgi fail and what can we do to avoid > > repeating the same path this time around. > > IIRC, the main reasons were: > - GGI wanted to do too much at once and was too intruisive (conclusion: > always advance in small steps, not big leaps): > o kernel graphics drivers (KGI) > o new input subsystem (similar to what we're heading to now) > o user space library (libggi, AFAIK the only part that's still alive) > - fbdev was better in multi-platform handling (m68k -> PPC -> ia32 -> SPARC > -> alpha -> ...) > > Please correct me if I'm wrong ;-)
The KGI is way to complex. I attempted to write a driver using that system but I was totally lost. Fbdev, especially now is much easier to develope. The input system we have is very similiar to what they had. I'm really glad we have a input system. As for the library. Well it has always been a dream to have a universal library by many people. It never happened and never will happen. When it comes it libraries you have issues like licenses and people fighting ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
