Marco Gerards wrote: > Vesa Jääskeläinen <[EMAIL PROTECTED]> writes: > >> Vincent Pelletier wrote: >>> By the way, I think we should start a discussion on the API common to >>> all architectures for framebuffer handling. >> Currently there is a terminal implementation that uses video subsystem >> to render screen. So basicly in every arch there must be a video driver >> if you want graphical console. >> >> You can see my current idea how to use video driver in grub wiki: >> http://grub.enbug.org/VideoSubsystem > > As I still can't log in on the wiki, I better reply here :-) > > First of all I'd like to see some double buffering feature. Will that > be somehow possible? In that case we need functions like: > > - Switching to a buffer, making it visible. > - Selecting which buffer is used for output.
Yes, double buffering is possible of course ;) It's not even hard one. There are some issues that must be decided. Most important one is, what you want to do with double buffer, do you want access to actual pixel data? Should this access be hidden or emulated. What happens when there are different graphics modes. Do we need to implement pixel data conversion layer. Or do you want only to hide some possible artifacts? Eg. having many changes to whole screen per refresh cycle? Current idea was only draw to screen when there is something new to draw. Now if we assume that there will be double buffering then there is problem where the actual data is stored. As we don't have fancy drivers for each video card there, we must use provided features of VBE (or similar interface). In banked modes, switching the bank can be slow, and if we require that double buffer is store on video memory, accessing (read&write) can be slow. It could also limit some modes from user as there is no room for double buffer. And worst case is here that some implementations of VBE can be buggy in this case... Ever seen div by zero from video bios ;) ? If we store this memory to host memory, then accessing it is fast, but swapping the whole screen can be slow. We could of course implement some dirty regions to optimize transfer time. Now if you want direct access to frame buffer data (read&write) then who is responsible to make sure pixel data is correct for the display? Do we need to convert pixel data on transfer? My idea was following in current implementation: - Supply basic operations on video driver - If there is complex graphics needed, use bitmap (it would have transparency support) - When bitmap is loaded, it would be converted to device compatible bitmap - If there is a need to generate bitmap data, it should be done in emulated pixel buffer (something like R8G8B8A8) and then converted to device compatible bitmap. Ps. I will answer rest of your questions later on, now I need to move on elsewhere :) _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
