From: Marco Gerards <mgerards@xs4all.nl>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Video subsystem draft
Date: Sat, 10 Dec 2005 22:15:42 +0100 [thread overview]
Message-ID: <873bl0mz5t.fsf@xs4all.nl> (raw)
In-Reply-To: <439B3F1A.5070204@nic.fi> (Vesa Jääskeläinen's message of "Sat, 10 Dec 2005 22:48:26 +0200")
Vesa Jääskeläinen <chaac@nic.fi> 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
next prev parent reply other threads:[~2005-12-10 21:16 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-23 11:24 Video subsystem draft Vesa Jääskeläinen
2005-10-23 15:03 ` Timothy Baldwin
2005-10-23 15:24 ` Vesa Jääskeläinen
2005-10-28 3:21 ` Yoshinori K. Okuji
2005-10-28 13:59 ` Vesa Jääskeläinen
2005-11-17 23:19 ` Vesa Jääskeläinen
2005-11-18 11:06 ` Yoshinori K. Okuji
2005-11-22 19:06 ` Vesa Jääskeläinen
2005-11-25 20:25 ` Yoshinori K. Okuji
2005-11-26 0:28 ` Vesa Jääskeläinen
2005-11-26 14:36 ` Vincent Pelletier
2005-11-26 19:54 ` Yoshinori K. Okuji
2005-11-27 1:48 ` Vesa Jääskeläinen
2005-12-09 22:44 ` Marco Gerards
2005-12-10 0:19 ` Yoshinori K. Okuji
2005-12-10 10:31 ` Vesa Jääskeläinen
2005-12-10 21:01 ` Marco Gerards
2005-12-10 21:23 ` Vesa Jääskeläinen
2005-12-10 20:48 ` Vesa Jääskeläinen
2005-12-10 21:15 ` Marco Gerards [this message]
2005-12-10 22:14 ` Vesa Jääskeläinen
2005-12-10 22:32 ` Marco Gerards
2005-12-10 23:11 ` Vesa Jääskeläinen
2005-11-27 2:00 ` Vesa Jääskeläinen
2005-11-26 19:52 ` Yoshinori K. Okuji
2005-11-27 2:09 ` Vesa Jääskeläinen
2005-12-09 22:33 ` Marco Gerards
2005-11-28 21:29 ` Vesa Jääskeläinen
2005-12-06 15:18 ` Vesa Jääskeläinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=873bl0mz5t.fsf@xs4all.nl \
--to=mgerards@xs4all.nl \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.