Re: vesafb terminal for testing.

["Vesa Jääskeläinen" <chaac@nic.fi>]

Vladimir Serbinenko wrote:
> Vesa Jääskeläinen wrote:
> 
>> I can try to draft out features that I think is needed and then we can
>> see what is still missing and when it is good enough then implement it.
>>
> But we need to let the room for the future growth. One of far-looking
> plans is
> "eye-candy" menu interface and we don't know yet what we will put there.

Perhaps someone likes to have all features Okuji wrote in his message...
 But my idea was to make list of generic operators that will be needed
on most cases. Basic operations has been quite stable for many years.
Only thing "new" is that there are hardware acceleration for some of
them. If something tradically different comes up, then we have to think
again. But let's see what I come up.

> Then
> if somebody wants to implement icon-based menu (icon+label for each menu
> entry,
> choosing with mouse and so on) he should be able to do so without
> changing the
> video interface function. Perhaps we should make abstract drawing interface?
> If so IMHO we should take one of existing drawing interfaces like the base
> (but of course it's not necessary to implement all features of the base
> interfaces,
> just the basic ones)

Absolutely, I was thinking about generic interface. It will make it much
easier and less bug prone as everything is done using generic interface.
It eases porting to other systems too.

Remember that you have to separate behavior of the menu from the
graphics driver. Menu can be changed anyway implementors sees best fit,
but the graphics driver doesn't change that much (or at least it shouldn't).

>> // functions
>> grub_vbe_probe
>> grub_vbe_set_mode
>> grub_vbe_get_mode
>> grub_vbe_get_mode_info
>>
>> // global variables
>> struct grub_vbe_info_block grub_vbe_controller_info;
>> struct grub_vbe_mode_info_block grub_vbe_active_mode_info;
>>
>> And perhaps some others if there is a need.
>>
> I'm very opposite because it's not critical for booting and it will take
> place and place in kernel is critical (at least for i386). It could be
> separate
> modules (e.g. vesafb and vesainfo) but it must be a module. If multiboot
> needs
> it. It can just reference it like a dependency

Perhaps. Currently there is some thunks that call real mode VBE
functions in kernel. And those functions I listed are more easier to use
interfaces for some of those functions.

As far I know, GRUB 2 doesn't support dynamic loading of function entry
points, instead there are only two predefined entry points that can be
called from modules so there has to be some interface for those if they
are not implemented in kernel level. And it would be bad to duplicate
that code in several places.

I see four options here:

1) design graphics drivers interface and register it when loading
module. Pros is that it is easy to write new graphics drivers. Cons is
that we need to have then virtual screen support (not hard to make).

2) improve terminal interface. Cons for this are that terminal interface
can grow quite large and not all functions are relevant to terminal.

3) implement some generic code in kernel level. Pros is that it is
easier to interface with it. Cons are that kernel size increases.

4) design some helper function interface that could be used to make
dynamic function calls to module code. Cons are 'What happens then when
module is unloaded?'.

Perhaps there are other options ?

Thanks,
Vesa Jääskeläinen