Re: Terminal interface and how it should be used?

[Marco Gerards]

Vesa Jääskeläinen <address@hidden> 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