Re: Video subsystem draft

[Marco Gerards]

Vesa Jääskeläinen <address@hidden> writes:

>> 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.

It's 32 bits on a 32 bits architecture and 64 bits on a 64 bits
architecture.  Using 32 bits on some 64 bits architecture might be
suboptimal and I think it is harder to read.  But it is ok to assume
you have at least 32 bits, but it can be more on some archs.

>>>> 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.

Ok, nice.

> 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.

It's relevant when someone made a 16bpp background image.  I am quite
sure he doesn't want to use 8 bpp. :-)

>>>> 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.

That is right.

> 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.

I also think video drivers should be easy to implement.  So this stuff
has to be done by the framebuffer I think.  Or someplace else.

> 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 :).

Yeah, window manager support is something we should focus at, at
first. ;-)

> 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.

I am not sure if I understand you.  Can you give two practical
examples of where it is better and where it is worse?

> 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

You want this so hardware layering features can be used?  Did you look
at some systems like XFree already?

> 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.

What does locking mean in this context?

> 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.

Isn't the output just the same?

> 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.

I am not yet sure if I understand it completely, I should re-read it
when I am not that tired. ;)

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

As I see it we need some killer feature to compete with GRUB Legacy.
Some neat graphics support can be that killer feature.  Especially if
it is cross-platform.

Something we should keep in mind is that if we want something new, we
could always extend the interfaces.  So no need for interfaces to
support 3D cards yet. ;-)

--
Marco