Date: Tue, 11 Jul 2000 16:13:13 -0500 From: "Pedro F. Giffuni" <giffunip@asme.org> To: freebsd-multimedia@FreeBSD.org Cc: Andreas Beck <becka@rz.uni-duesseldorf.de> Subject: GGI porting project Message-ID: <396B8DE9.FAB118A5@asme.org>
next in thread | raw e-mail | index | archive | help
Preamble: As most users, I am happily surprised with the incredible growth and development FreeBSD has had. This development, however, has been centered towards the sector where FreeBSD has gained better acceptance, the server market, but ignoring certain desktop related improvements that have been made on other camps. The GGI project (http://www.ggi-project.org/) enables the use of accelerated video cards on UNIX-like systems. It presently only runs on Linux but it is architecture independent and it has evolved providing the advantages of similar systems (SCOS's AGA, libsvga, allegro, etc...) without much uglier hacks or restrictive licenses (most of the code is under an X11 license and the kernel glue code is licensed according to the OS). Porting GGI to FreeBSD would bring great advantages to both camps. For FreeBSD it would represents a complement to the XFree86 4.x video support plus the possibility of using software developed for libsvga and libggi on full screen. For GGI it would mean greater acceptance and the possibility of becoming a standard some day (I understand they have also been in contact with the UDI project). Objectives: - Port the basic GGI userland infrastructure so that it will work with the FreeBSD console. - Provide a loadable module for the GGI kernel dependent parts so that we can run accelerated video applications under FreeBSD native programs and linux emulated applications. People involved: The code has been studied and we have ideas on how to proceed but this message was posted because right now we are all busy on other things and without more volunteers the project will take very long! On the GGI project side, project leader Andreas Beck <becka@uni-duesseldorf.de> has installed FreeBSD-4.0 and, although very busy, is extremely helpful in answering the general GGI questions that might arrive. On the FreeBSD side, Coleman Kane <cokane@pohl.ececs.uc.edu> was a natural choice since he ported the 3DFX driver to FreeBSD. No time either, but he has expressed his interest in helping and he has a GGI supported card. Me, I am too busy moving to another city and learning to program in C, so I'm just cheerleading and trying to keep the project alive :-). Roadmap Summary: In principle, all references to the Linux console code should be avoided :-). The criteria that will prevail was finely depicted by Søren Schmidt: "However I am the strong oppinion that we dont need yet another graphics interface in the kernel, no matter what, so either use the existing interface maybe with some extensions that fit the current way of doing things, or put a new interface in there and get rid of the old." The work that remains to be done lies in two areas: -- Userland: obviously, these dont require any change on FreeBSD. libgii, is a library that supports keyboard and mouse input. The FreeBSD keyboard support is particularly different from the Linux case, but it shouldn't be difficult to support with the K_RAW mode. libggi, This is the main graphic library, it can use targets (glide, libsvga, memory, aalib, fbdev) with the X11 target being the only one that works well on FreeBSD AFAIK. -- Kernel: KGIcon is the basic module used to provide graphic acceleration and support for architecture independent drivers. In linux this module actually replaces the framebuffer device, quoting Andreas Beck: "Well - the idea is to have a device in /dev that you can open, mmap the framebuffer from it and send commands to it in some way. Eventually some devices that are well designed can allow to further mmap device registers to speed up accel commands." On sourceforge there is a newer but still experimental KGI version, again quoting the expert: "Basically it's a fb device as well, but it has different semantics that work around the broken Linux console implementation." It's still a mistery (for me) if we should fit this into /dev/fb.c, or if we should create a new framebuffer device. It's probably still to early to decide this... Another interesting thing that can be done is providing enhanced console support: KGI could accelerate operations like scrolling, and libgii could prove useful supporting Unicode. Conclusion If you can and are willing to help on anything you should take a look at the GGI website, and start hacking the development version. The freebsd-multimedia list is probably the best place to discuss, and there's also a GGI mailing list (posting is closed unless you subscribe, though), and please don't hesitate to contact Andreas Beck (or me, if you are very desperate :). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?396B8DE9.FAB118A5>