Terminal interface and how it should be used?

Terminal interface and how it should be used?

[Vesa Jääskeläinen]

Hi,

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.

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

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

/* Clear the screen.  */
void (*cls) (void);

Should screen be cleared instantly? Or should it be after refresh().

/* 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 RGB palette?

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

Thanks,
Vesa Jääskeläinen

Re: Terminal interface and how it should be used?

[Marco Gerards]

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

Re: Terminal interface and how it should be used?

[Vesa Jääskeläinen]

Marco Gerards wrote:
> 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. :-)

After couple of hours catching up with newest grub2 modifications and
diffing, I was able to make quite nice migration of the code. There are
still TODO items and such. But should give you much better indication
where we are at now.

Tarball:
http://jumi.lut.fi/~vjaaskel/grub2/grub2-video-20060225.tar.gz

Diff:
http://jumi.lut.fi/~vjaaskel/grub2/grub2-video-20060225.diff

There is pre-made grub.cfg that loads font and prepares everything to be
usable. Please make sure that unifont.pff is included to floppy (or what
ever you use to test it).

After booting, enter to command line and write:
terminal videoterm

You can of course add this line to grub.cfg when you feel it works good
enough.

There is currently no option to choose what video mode is initialized,
it just tries to use 1024x768. It blinks a lot when scrolling, index
color modes most likely will not work, not all features are present and
so on... Other than that :), I would like to hear comments about it.

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

Ok.

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

This is now done only when refresh is called.

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

This is also done only after refresh.

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

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

Ok. Then the new videoterm is a good candidate for proofreading that
there is refreshes at correct places :).

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

Added refreshes to cmdline input as it was quite uncomfortable to write
blindly ;)

Refreshes is implemented with simple dirty regions implementation. There
is only one area that gets larger when new regions are added. This could
be improved later on. But should work nicely (of course it might redraw
too much)

Re: Terminal interface and how it should be used?

[Vesa Jääskeläinen]

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

Re: Terminal interface and how it should be used?

[Yoshinori K. Okuji]

On Wednesday 01 March 2006 22:23, Vesa Jääskeläinen wrote:
> 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 ?

I like to have the code in the CVS as soon as possible.

Okuji