On Sat, 30 Mar 2002, Jeffrey Drake wrote: > I do not know exactly where it is freezing, as I do not know how to test > for that. I do not have X installed let alone running. I imagine it is > potentially possible that gii might not be found, but that shouldn't > cause a freeze.
In general we consider it to be a Very Bad Thing (tm) if GGI causes any sort of freeze. We like to make sure that even if the program aborts it leaves the console in a usable state. I think you mean "vgl" noy "kgl", which is as far as I know, FreeBSD's answer to Linux's SVGALib, and is a userspace library (with perhaps some kernel tie-ins I don't know). It is quite likely that the display-vgl code in our CVS repository has gotten out of date with libvgl and needs some touch-up. I have no FreeBSD boxes, but if none of our BSD folks have the time to debug LibVGL (folks?) then I might be persuaded to install a BSD partition somewhere and fix it. > An additional request: Does anyone know anything at all about 'kgl'? I believe it >may > stand for kernel graphics library, but I can't find ANY thing about it, only things >that use > it, and very few of those. "KGI" is kernel graphics interface, but I think you mean "vgl" and according to the README in our source subdirectory, there should be a vgl(3) manpage on systems where libvgl is installed. P.S. Before I sent this I read a little more about libvgl and I see that it uses a real-mode VESA BIOS trick. This could make things a bit hard to debug because the VESA compatibility of your particular hardware comes into question. That, and the real-mode BIOS code trick is a bit of a hack which if it works that's great, but on systems where it has not been tested, may cause results like what you got :-/ If SVGAlib has been ported to FreeBSD I would suggest installing and using that instead. P.P.S. We should perhaps comment out libvgl support in libggi.conf and add there a warning to only activate if they are ready to put their VESA BIOS to the trial of flame. T minus 2 days and counting... -- Brian
