Re: Video subsystem draft

[Vesa Jääskeläinen]

Marco Gerards wrote:
> Vesa Jääskeläinen <address@hidden> writes:
> 
>>> I don't like using grub_uint*_t for parameters.  Just use normal
>>> integers instead.  These types just have to be used for ABIs and
>>> network and disk access.  In the case of APIs such types should be
>>> avoided.
>>>
>>> So better use "int height" instead of "grub_uint32_t height".  This is
>>> especially important for portability and it serves no purpose.
>> Ok... grub_uint32_t is unsigned version, so would it be reasonable to
>> use unsigned int instead of int and do we assume that int is normally
>> signed, or should I explicitly write signed int or unsigned int?
> 
> I would just used `int' and `unsigned int'.  It's just important that
> you don't explicitly use a specific amount of bits and leave that to
> the compiler.

Ok. Can I assume that unsigned int always has at least 32 bits? Or do I
need to specify some types needing 32 bits using grub_uint32_t ? I will
use grub_uint32_t and friends in VBE structures, but in video subsystem
it is irrelevant.

>>> Is it possible to pass parameters like depth to grub_video_setup?
>> Depth?... Are you thinking 3D-displays here :) ? Or are you building up
>> some kind of Z-buffering?
> 
> Depth means the amount colors.  For example you can have a 16 bits
> depth, which means 65536 colors per pixel.

Okey, bits per pixel then, or color depth :)... Currently it is auto
detecting best possible bits per pixel mode. We could allow mode_type
parameter to assist on selection of the best matching mode. And if there
is no exact match, one bit in mode_type could tell what to do in that
situation. Should best matching mode be selected, or only exact matches
allowed. If there is no valid mode in display driver it will fall back
to next listed driver and try to initialize mode with same parameters.

I thinked that selecting the bpp is not important and I optimized it out
 :), but if this is wanted feature I think guiding is better option.
There are many different RGB modes and I think that it would be most
reasonable to ask generally a RGB mode and then select best one.

>>> How would scrolling work if a background picture was used?
>> I was planning that terminal would implement background picture
>> handling. And if there is a background picture that would scroll when
>> the screen is about to scroll. That area must be redrawn. Fanciest
>> option here would be that there would be graphical layers, but that is
>> more a "window manager issue" than a video driver issue.
> 
> If you use double buffering, you can use a few buffers:
> 
> 1) the background
> 2) the text and whatever the console needs for output
> 3) some buffer to which #1 is copied and #2 is copied (using 0 as
>    transparancy or so)
> 4) The visible buffer
> 
> In that case you draw to buffer 2, prepare buffer 3.  When you want to
> show buffer 3 you switch it with buffer 4.
> 
> What do you think of that?

That's not exactly double buffering :). It's more like a layering
combined with double buffering.

But your idea of layers with data can be used and is most likely good
approach. But should this be implemented in video driver or elsewhere. I
have tried to make video drivers simple to implement. Rest of the
graphics system would then implement fancier functions.

In here I would see this as a job of "window manager". In grub's case
this is more like a responsibility of the terminal :).

There are two approaches that I see here:

1) Terminal's responsibility

Rendering sequence would be:

- Zero out back buffer (optional)
- Terminal would draw background bitmap
- Terminal could use multiple additional bitmaps layers and upper layers
could include transparency information
- Terminal must use font manager in order to draw text, unless glyph
drawing is implemented elsewhere.
- Swap front/back buffers

Now good thing here is that video driver is not bloated. Bad thing here
is that handling of those bitmaps would most likely need same
functionality as is provided in non-bitmap video driver.

2) Partially video drivers responsibility

Add support for rendering targets. Caller could create virtual screens
that can be used to render with normal drawing functions. This would
shift some of the jobs to video subsystem.

Rendering sequence could be something like:

- Zero out back buffer (optional)
- Render background from render target 0 (or from bitmap)
- Render additional layers from other render targets (or from bitmaps)
- Render text layer using font manager or another render target
- Swap front/back buffers

In order to use render targets, they must be created and they should be
based on the actual screen properties. Eg. Same color order and so on.
Resolution of the render targets could be different. This is to fasten
blitting process. There is also possibility to "lock" render target in
order to do pixel buffer modifications.

To map text layer to render target ideology, there would be need to
create correct size render target. Then use display driver provided
glyph rendering code to display actual text. Scrolling is really easy in
this case. But when drawing to render target we must remember to specify
all transparent areas.

Con's of the render targets is that eats quite lot of more memory than
then first idea. But with them we can get prettier output more easily.

This render target could be a viable solution, even though it shifts
some more work to video subsystem. It's not too hard to implement render
target support. So if this is a route we take it's Ok for me.

But now comes the important question :)... How advanced we want this
video subsystem to be in GRUB ?