Re: Terminal interface and how it should be used?

[Vesa Jääskeläinen]

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

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)