Re: Video subsystem draft

[Vesa Jääskeläinen]

Marco Gerards wrote:
> Vesa Jääskeläinen <address@hidden> 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 :)