All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Gerards <mgerards@xs4all.nl>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Terminal interface and how it should be used?
Date: Tue, 21 Feb 2006 13:04:42 +0100	[thread overview]
Message-ID: <87k6bohq91.fsf@xs4all.nl> (raw)
In-Reply-To: <43FA48DD.8090509@nic.fi> (Vesa Jääskeläinen's message of "Tue, 21 Feb 2006 00:55:25 +0200")

Vesa Jääskeläinen <chaac@nic.fi> writes:

Hi Vesa,

> I have made some progress with video subsystem and currently the font
> manager is slowing down (we need to cache fonts) and there are some
> issues with grub_term. I am not sure if all parts of the code use it
> correctly or then I am just understanding it differently. After those
> issues are solved I think we could start to migrate this code back to tree.

Great to hear you are making progress.  Hopefully we can resolve the
issues ASAP. :-)

> Here are selected features that might need more information in order to
> get correct results.
>
> /* Put a character. C is encoded in Unicode.  */
> void (*putchar) (grub_uint32_t c);
>
> Should putchar() instantly show results of the operation? Or after
> calling refresh().

It should be shown after the refresh of the screen.  I made this
change because on some terminals you have to do a refresh anyways.
Doing a refresh for every putchar can make some terminals too slow to
work on properly.  I think the amount of required refreshes can be
reduced, but it is something that needs proper discussion on a per
case basis.

> /* Go to the position (X, Y).  */
> void (*gotoxy) (grub_uint8_t x, grub_uint8_t y);
>
> Should gotoxy() instantly move cursor to specified location and if
> output is not yet drawn, should it be drawn at this point.

The current terminals can do this instantly.  But I think it is sane
to make this dependant on the refresh.

> /* Clear the screen.  */
> void (*cls) (void);
>
> Should screen be cleared instantly? Or should it be after refresh().

Good question.  At the moment it does not require a refresh, IIRC.
But in the case of the fb it might be nice to require that.

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


> /* Update the screen.  */
> void (*refresh) (void);
>
> This one is a trickier, should it cause redraw to be done to whole
> screen, or to render actions in queue. I am asking this because it would
> look like it is being used to render actions in queue. If I code it to
> render whole screen, we get nice flickering as screen is being rendered
> multiple times for nothing. (I am not interested at this point to
> optimize video drawing as I want to have solid terminal interface first)
> If I remove some extra refreshes terminal works quite nicely, but then
> it might not be semantically correct usage.

It is implementation dependant.  On VGA text mode this function
doesn't do a thing.  On the ncurses console it calls the ncurses
refresh function.  The terminal just has to make sure that after this
call the screen contents is up to date.

The problem with removing some refresh calls i that when there is a lot
of output and the terminal scrolls, you don't see it scrolling.
Perhaps we can reduce the amount of refresh calls considerably.
Some scenarios when you want to call refresh:

- Immediately after printing debugging information.
- When the user is asked for input.
- When there is a lot of IO scheduled (reading the kernel+initrd from
  disk).
- When scrolling.  Perhaps not even for every line.

Currently refresh is called for *every* grub_printf call.  Until now
this did not cause performance problems for us, but I think this one
has to be removed now.

--
Marco




  reply	other threads:[~2006-02-21 12:42 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 [this message]
2006-02-25 13:25   ` Vesa Jääskeläinen
2006-03-01 22:23     ` Vesa Jääskeläinen
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=87k6bohq91.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.