grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Video subsystem draft


From: Marco Gerards
Subject: Re: Video subsystem draft
Date: Sat, 10 Dec 2005 22:15:42 +0100
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

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.

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

>> Will it be possible for other users than the terminal to use these
>> functions?  I think that would be nice.  But in that case a function
>> should be used to redraw the screen.
>
> Most of the functions could be used from scripts, only problem is that
> scripts would need to handle different data types correctly (like bitmap
> etc).

Of course.

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

--
Marco





reply via email to

[Prev in Thread] Current Thread [Next in Thread]