All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vesa Jääskeläinen" <chaac@nic.fi>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Terminal interface and how it should be used?
Date: Thu, 02 Mar 2006 00:23:51 +0200	[thread overview]
Message-ID: <44061EF7.4010408@nic.fi> (raw)
In-Reply-To: <44005AB8.7030408@nic.fi>

Vesa Jääskeläinen wrote:
> Marco Gerards wrote:
>> Vesa Jääskeläinen <chaac@nic.fi> writes:
>>> /* Set the current color to be used */
>>> void (*setcolorstate) (grub_term_color_state state);
>>>
>>> /* Set the normal color and the highlight color. The format of each
>>>    color is VGA's.  */
>>> void (*setcolor) (grub_uint8_t normal_color, grub_uint8_t highlight_color);
>>>
>>> And what exactly should these two be doing ? :).. setcolorstate and
>>> setcolor. I can imagine that it changes color, but to what. Should this
>>> be changed to some kinda theming system. Or should I just assume that
>>> those are palette indexes and in RGB modes, use emulated R
>> normal_color and highlight_color are indexed colors.  So you have to
>> set up some lookup table to lookup the colors that belong to a certain
>> index.  Something similar is done for the IEEE 1275 terminal.  So you
>> can look there for a reference and use that table.
> 
> Will implement this shortly. I have quite good idea how to implement
> this, but I will look that code too.

Now it copies "factory" defaults as a default emulated palette, and then
used indices to there. This highlight and normal color doesn't sound
like a foreground & background color :), but I implemented them in
similar manner. Currently drawing something to screen will make
character and it's background opaque. This might not be a good idea in a
long run. Having a transparent terminal might be a nice feature. But
that is quite easy to change when we need it.

Then the next issue here is that video mode should be selectable for the
user (or for the script at least). Any ideas how to implement this?
Perhaps some environment variable? After this is solved I will release a
new snapshot.

Then I need to check out my TODO items :)... and implement support for
indexed color modes. And make a cleanup. Do we really need other
functionality from VBE to be usable than the information what is needed
for multiboot?  I would like to remove those "old" setpixel etc. stuff.

But basicly in this stage I think drivers for the other archs could be
started to be written. The driver interface seems to be good enough for
our use. Any ideas what would be a good point when we migrate the code
back to CVS ?

Thanks,
Vesa Jääskeläinen



  reply	other threads:[~2006-03-04 14:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-20 22:55 Terminal interface and how it should be used? Vesa Jääskeläinen
2006-02-21 12:04 ` Marco Gerards
2006-02-25 13:25   ` Vesa Jääskeläinen
2006-03-01 22:23     ` Vesa Jääskeläinen [this message]
2006-03-05 22:19       ` Yoshinori K. Okuji

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=44061EF7.4010408@nic.fi \
    --to=chaac@nic.fi \
    --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.