Announce: LibGGI 2.0 BETA1 (the Degas release) is finally out. -------------------------------------------------------------- Yes, I know - we have taken our time. LibGGI has been given a major service interval, and we hope, we now have something, that is here to stay. LibGGI has been split into a library doing generic input handling called LibGII, and the "traditional" LibGGI, which takes care for handling graphical output to virtually anything used to display graphics on Linux or Unix in general. And _NO_ - you don't need to patch your kernel to use it. For those that have waited for just that announcement - here is where you can get it: ftp://ftp.ggi-project.org/pub/ggi/ggi/2_0_beta_1 For those who don't yet know, what LibGGI is about and why you want it as well: LibGGI is an attempt to unify all those graphical output systems that exist on Unix (and we even want to port to other systems as well). Linux alone has a pretty big set of graphics output subsystems: X, SVGAlib, /dev/fb (native or kgicon), LibAA, Glide, XF86-DGA, etc. ... LibGGI is an attempt to unify all of them. It is a very fast, simple (ever tried to make a small graphics app directly in Xlib ?) and lightweight interface layer, that allows you to run the _very_same_binary_ on all the above mentioned targets (as we call them). LibGGI will detect (or you can select, of course) the environment you are running in, and redirect its output as required. Forget about limiting yourself to just one graphics subsystem and just use LibGGI. LibGII is a companion lib, that was developed because most programs producing graphical output will require input as well. In LibGGI 1.0, LibGII was integrated with LibGGI, but we found that it is more flexible to separate it out. This enables you to add your favorite device to the available input devices of nicely written LibGGI programs, and you can use it. the author of the program doesn't even know your device exists. At worst, you can make it emulate a mouse. And yes, even if you don't want to use LibGGI, you might still find libGII useful. It is completely independent of it and can be used standalone. As there are quite a bunch of SVGAlib applications out there, while there are many systems that can't use them due to the lack of drivers, we decided to make an SVGAlib wrapper as well. This is an SVGAlib-look-alike, which internally uses LibGGI. This allows you to run many SVGAlib programs via LibGGI and make them display on your X server, for example. Other goodies: LibGGI features several "pseudo-targets", that allow for nifty effects: - "multi" allows you to display the same application on multiple targets. Very nice for remote demonstrations. - "tile" allows to cut a big virtual graphics area into a bunch of tiles, that can be sent to different targets. Can you say video-wall ? - "trueemu" allows to run "bad" applications that insist on running truecolor on other bitdepth visuals. - "palemu" does the same for palette-loving apps. Other targets (like sunfb and VNC) are being prepared. A few of the more advanced targets might show little oddities in the current BETA. We'll try to fix that soon, but we wanted to have a present for christmas ... Performance: Wrappers aren't always slow. We took great care to optimize things, and we actually do support acceleration, where available. Or as one our developers puts it: You might want to mention squake running on svgalib-wrapper running on LibGGI running on X gives about the same framerate as squake running on SVGAlib directly on the gfxhw ;) Applications: LibGGI has attracted quite some ports of interesting programs. Available titles include Descent (the first port, that was known to natively run on Linux/Alpha), DOOM and DUMB, Xmame, Phorus, Crystal Space, XGGI (an X server running on top of GGI - this unifies Xfb, Xnest, Xvfb, ...) and many many more. A note to developers: We believe that the API is stable now. Maybe we will do minor adjustments to the inner workings, but the exported functionality is expected to be stable. So hack away. Have fun with it !