On Tue, 21 Jan 2003, Christoph Egger wrote: > Ok, I'll try to make a (short) summary.
> Andreas wanna deal with this whole issue by informing the userspace via a > ping-pong mechanism based on sending signals between kernel space (KGI) and > userspace (GGI application and/or GGI's kgi-target). > > Fabio wanna deal with this whole issue by locking/unlocking the critical > areas (MMIO-, framebuffer-, Overlay-areas) using either interprocess mutexes > (semaphores using shared memory - kernellevel mutexes are also thinkable, but I > don't know, if such things really exists accessable from userspace). > > I think, the most robust and most efficient way is to try to combine BOTH > ways. I mean using mutexes AND signals. Well... I ment to say what your conclusion is: We might need both. And, let's face it: For which programs would a background framebuffer be useful and worth the trouble ? For programs that can't refresh within #include <fuzzylogic.h> GGI_SMALL_AMOUNT_OF_TIME. I can't come up with anything else but rendering software, and maybe rendering software shouldn't use the framebuffer as direct and only output ? True, when the video memory is filled with textures, it will take a few seconds before the software continues to run, but that's IMHO the price you pay for switching consoles while playing #include list_of_heavy_3D_games.h KGI provides the user 64 graphical consoles, I think you can't deal with those without paying a little price. All ideas about background framebuffers are nice in many specific situations, but I think KGI is far too generalizing. Jos
