Video subsystem draft

Video subsystem draft

[Vesa Jääskeläinen]

Hi,

I made a draft how video subsystem could work. It doesn't currently
contain information about internals, but is more concentrated on usage
of the API.

In order to make GRUB 2's video subsystem more flexible, there is a need
to modify font manager in order to support more variety of different
character types. I already tested it with one idea and it seems to work
nicely, but in order to support more character types I think someone
else have to give some comments about how glyph's should be defined.

Anyway, here is first draft and I would like to get some comments about it:

http://jumi.lut.fi/~vjaaskel/grub2/

btw. There will be some network reconfigurations in beginning of next
week, so that site could be unavailable for some time.

Thanks,
Vesa Jääskeläinen

Re: Video subsystem draft

[Timothy Baldwin]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

On Sunday 23 Oct 2005 12:24, Vesa Jääskeläinen wrote:
> Hi,
>
> I made a draft how video subsystem could work. It doesn't currently
> contain information about internals, but is more concentrated on usage
> of the API.

GRUB should support modes with fixed palettes, in order to support (firmware) 
windowing systems, such as RISC OS and Windows CE.

The VIDC1 256 colour with 16 entry palette modes could also treated as having 
a fixed palette.

-- 
Member AFFS, WYLUG, SWP (UK), UAF, RESPECT, StWC
No to software patents!    Victory to the iraqi resistance!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Video subsystem draft

[Vesa Jääskeläinen]

Timothy Baldwin wrote:
> On Sunday 23 Oct 2005 12:24, Vesa Jääskeläinen wrote:
>> Hi,
>>
>> I made a draft how video subsystem could work. It doesn't currently
>> contain information about internals, but is more concentrated on usage
>> of the API.
> 
> GRUB should support modes with fixed palettes, in order to support (firmware) 
> windowing systems, such as RISC OS and Windows CE.
> 
> The VIDC1 256 colour with 16 entry palette modes could also treated as having 
> a fixed palette.

Hi,

Those are called as Index Color mode in that draft. If palette can't be
changed, then those functions used to set palette should fail.

Thanks,
Vesa Jääskeläinen

Re: Video subsystem draft

[Yoshinori K. Okuji]

On Sunday 23 October 2005 01:24 pm, Vesa Jääskeläinen wrote:
> I made a draft how video subsystem could work. It doesn't currently
> contain information about internals, but is more concentrated on usage
> of the API.

It looks good.

> In order to make GRUB 2's video subsystem more flexible, there is a need
> to modify font manager in order to support more variety of different
> character types. I already tested it with one idea and it seems to work
> nicely, but in order to support more character types I think someone
> else have to give some comments about how glyph's should be defined.

For the glyph support, it should be based on the font manager, but I haven't 
decided the API yet. As a starting point, it would be enough to assume that 
we always use a fixed size (currently, 8x16 or mutiples of 8x16). In the 
future, we will want to support different size or even vector fonts.

> Anyway, here is first draft and I would like to get some comments about it:
>
> http://jumi.lut.fi/~vjaaskel/grub2/

Can you put the contents on the wiki? This would be easier to maintain the 
document.

Okuji

Re: Video subsystem draft

[Vesa Jääskeläinen]

Yoshinori K. Okuji wrote:
> On Sunday 23 October 2005 01:24 pm, Vesa Jääskeläinen wrote:
>> I made a draft how video subsystem could work. It doesn't currently
>> contain information about internals, but is more concentrated on usage
>> of the API.
> 
> It looks good.

Then I'll do the first implementation. It will be only for i386 as
that's only platform I can test.

>> In order to make GRUB 2's video subsystem more flexible, there is a need
>> to modify font manager in order to support more variety of different
>> character types. I already tested it with one idea and it seems to work
>> nicely, but in order to support more character types I think someone
>> else have to give some comments about how glyph's should be defined.
> 
> For the glyph support, it should be based on the font manager, but I haven't 
> decided the API yet. As a starting point, it would be enough to assume that 
> we always use a fixed size (currently, 8x16 or mutiples of 8x16). In the 
> future, we will want to support different size or even vector fonts.

I'll will improve current situation a bit to direction of better glyph
support, but this needs more work. I will give patch for those too when
first implementation is ready.

>> Anyway, here is first draft and I would like to get some comments about it:
>>
>> http://jumi.lut.fi/~vjaaskel/grub2/
> 
> Can you put the contents on the wiki? This would be easier to maintain the 
> document.

I am not too familiar with syntax of wiki, but here is something:
http://grub.enbug.org/VideoSubsystem

I will try to improve it's contents later on.

Thanks,
Vesa Jääskeläinen

Re: Video subsystem draft

[Vesa Jääskeläinen]

Vesa Jääskeläinen wrote:

>>> In order to make GRUB 2's video subsystem more flexible, there is a need
>>> to modify font manager in order to support more variety of different
>>> character types. I already tested it with one idea and it seems to work
>>> nicely, but in order to support more character types I think someone
>>> else have to give some comments about how glyph's should be defined.
>> For the glyph support, it should be based on the font manager, but I haven't 
>> decided the API yet. As a starting point, it would be enough to assume that 
>> we always use a fixed size (currently, 8x16 or mutiples of 8x16). In the 
>> future, we will want to support different size or even vector fonts.
> 
> I'll will improve current situation a bit to direction of better glyph
> support, but this needs more work. I will give patch for those too when
> first implementation is ready.

What is the procedure to generate font file to font manager? Or should I
 just add some functionality to import VGA font to font manager.

Otherwise some of the functionality is working correctly, but until font
issue is solved it is not really useful for anything. Or if you count
drawing boxes to screen is useful ;)

Then we must decide how are we going to implement theming in grub. I am
open to any ideas.

Thanks,
Vesa Jääskeläinen

Re: Video subsystem draft

[Yoshinori K. Okuji]

On Friday 18 November 2005 12:19 am, Vesa Jääskeläinen wrote:
> What is the procedure to generate font file to font manager? Or should I
>  just add some functionality to import VGA font to font manager.

First, download unifont.hex from <http://czyborra.com/unifont/HEADER.html>. 
Then, convert it with util/unifont2pff.rb. If you invoke this script with no 
argument, you can a short summary of the usage. Let's say, you store the font 
in unifont.pff, then the command is "ruby util/unifont2pff.rb unifont.hex > 
unifont.pff". Now you can put this generated file under /boot/grub, and load 
it by the command "font".

You can also specify specific code ranges to unifont2pff.rb, if you need only 
a subset of supported glyphs. This is necessary if you want to use the 
ancient technology called "floppy".

Honestly, I haven't tried the font manager for a long time. So I won't be 
surprised even if I hear it is not working well. But last time I tried it (it 
was not GRUB 2, but PUPA), it worked well and I saw a menu with Japanese 
titles.

Okuji

Re: Video subsystem draft

[Vesa Jääskeläinen]

Yoshinori K. Okuji wrote:
> On Friday 18 November 2005 12:19 am, Vesa Jääskeläinen wrote:
>> What is the procedure to generate font file to font manager? Or should I
>>  just add some functionality to import VGA font to font manager.
> 
> First, download unifont.hex from <http://czyborra.com/unifont/HEADER.html>. 
> Then, convert it with util/unifont2pff.rb. If you invoke this script with no 
> argument, you can a short summary of the usage. Let's say, you store the font 
> in unifont.pff, then the command is "ruby util/unifont2pff.rb unifont.hex > 
> unifont.pff". Now you can put this generated file under /boot/grub, and load 
> it by the command "font".
> 
> You can also specify specific code ranges to unifont2pff.rb, if you need only 
> a subset of supported glyphs. This is necessary if you want to use the 
> ancient technology called "floppy".

I think it can be gzipped to fit more nicely :).. (and it seems to work
too).

But even without gzipping it, I am having some problems with it. I don't
think this is a problem in font manager.

> Honestly, I haven't tried the font manager for a long time. So I won't be 
> surprised even if I hear it is not working well. But last time I tried it (it 
> was not GRUB 2, but PUPA), it worked well and I saw a menu with Japanese 
> titles.

After something calls grub_error first read from font file fails, with
grub_file_read() == -1. Now this causes font manager to drop font from
memory. If I disable feature that I can see that first character is
invalid and others come nicely. In case of "error: ..." first 'e' is
corrupt and rest is ok. I am not sure is this really issue in grub_error
 itself but it is in sequence when problem shows up.

I can't find problem in font manager, even the offset that is tries to
seek is within limits of the file (and correct) and there is enough
bytes left in file in order to successfully complete the read.

I can send tarred version of grub2 with video subsystem if someone wants
to help on this one. I will continue to search for possible problems in
case I can pinpoint and fix it.

Is the font file using some standard format or can it's contents be
changed? Bitmap data for fonts could be placed in better order to more
easily to render it (currently I modify byte order before giving it to
glyph renderer). (My guess is that it is [P]upa [F]ont [F]ormat or file)

Re: Video subsystem draft

[Yoshinori K. Okuji]

On Tuesday 22 November 2005 08:06 pm, Vesa Jääskeläinen wrote:
> I think it can be gzipped to fit more nicely :).. (and it seems to work
> too).

Compression might make the performance horrible, because PPF is very 
optimized.

> After something calls grub_error first read from font file fails, with
> grub_file_read() == -1. Now this causes font manager to drop font from
> memory. If I disable feature that I can see that first character is
> invalid and others come nicely. In case of "error: ..." first 'e' is
> corrupt and rest is ok. I am not sure is this really issue in grub_error
>  itself but it is in sequence when problem shows up.
>
> I can't find problem in font manager, even the offset that is tries to
> seek is within limits of the file (and correct) and there is enough
> bytes left in file in order to successfully complete the read.
>
> I can send tarred version of grub2 with video subsystem if someone wants
> to help on this one. I will continue to search for possible problems in
> case I can pinpoint and fix it.

I will check this myself later.

> Is the font file using some standard format or can it's contents be
> changed? Bitmap data for fonts could be placed in better order to more
> easily to render it (currently I modify byte order before giving it to
> glyph renderer). (My guess is that it is [P]upa [F]ont [F]ormat or file)

If you want to improve it, feel free to do it. It is our own format. But I 
think the byte order was set conveniently.

Okuji

Re: Video subsystem draft

[Vesa Jääskeläinen]

Yoshinori K. Okuji wrote:
> On Tuesday 22 November 2005 08:06 pm, Vesa Jääskeläinen wrote:
>> I think it can be gzipped to fit more nicely :).. (and it seems to work
>> too).
> 
> Compression might make the performance horrible, because PPF is very 
> optimized.

When there is a caching implemented in a one day, it's only initial
cost. So far I haven't seen performance problems with this. But then
again I haven't tried it too much.

>> After something calls grub_error first read from font file fails, with
>> grub_file_read() == -1. Now this causes font manager to drop font from
>> memory. If I disable feature that I can see that first character is
>> invalid and others come nicely. In case of "error: ..." first 'e' is
>> corrupt and rest is ok. I am not sure is this really issue in grub_error
>>  itself but it is in sequence when problem shows up.
>>
>> I can't find problem in font manager, even the offset that is tries to
>> seek is within limits of the file (and correct) and there is enough
>> bytes left in file in order to successfully complete the read.
>>
>> I can send tarred version of grub2 with video subsystem if someone wants
>> to help on this one. I will continue to search for possible problems in
>> case I can pinpoint and fix it.
> 
> I will check this myself later.

Just in case you (or someone else) want to test current version, I have
uploaded it to:
http://jumi.lut.fi/~vjaaskel/grub2/grub2-video-20051126.tar.gz

I noticed that when ever I call grub_error something brakes, but what is
doing it I can't tell. There is a testerr3 function in video/video.c
that tries to demonstrate when does the corruption occur.

Oh.. and before anyone asks, video implementation is not still complete.
Code itself probably wont compile in other archs. But I think the
interface itself could be OK. But it needs to mature a bit. VGA module
is disabled until I have time to look how to modify it to fit new system.

>> Is the font file using some standard format or can it's contents be
>> changed? Bitmap data for fonts could be placed in better order to more
>> easily to render it (currently I modify byte order before giving it to
>> glyph renderer). (My guess is that it is [P]upa [F]ont [F]ormat or file)
> 
> If you want to improve it, feel free to do it. It is our own format. But I 
> think the byte order was set conveniently.

Byte order is currently exactly the same as in .hex file :)

It has minor issue with widechar fonts (char width > 1). It like
contains two different font data. First there is first half of like
normal 8x16 font and then there is second half. My idea would be to
store bitmap in scanlines instead of character blocks so I can take
whole character width and draw that.

Now I need to sleep... I will continue my tracking later one.

Re: Video subsystem draft

[Vincent Pelletier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 1773 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 26 Nov 2005 02:28:53 +0200
Vesa Jääskeläinen <chaac@nic.fi> wrote:
> Yoshinori K. Okuji wrote:
> > If you want to improve it, feel free to do it. It is our own
> > format. But I think the byte order was set conveniently.
> 
> Byte order is currently exactly the same as in .hex file :)
> 
> It has minor issue with widechar fonts (char width > 1). It like
> contains two different font data. First there is first half of like
> normal 8x16 font and then there is second half. My idea would be to
> store bitmap in scanlines instead of character blocks so I can take
> whole character width and draw that.

By the way, there is already a font format handled by IEEE1275
frame buffercards.
- From the standard : 

set-font ( addr width height advance min-char #glyphs -- )
Set the current font as specified.

So I think they can handle arbitrary-sized glyphs.
I can't find the font data definition, but as "default-font" returns
all those values for the default font, reverse engineering will be a
matter of minutes.

If the font format you want to design could be compatible with ths one,
it would be a pleasure to port it to sparc :) - and probably the same
for PPC.

By the way, I think we should start a discussion on the API common to
all architectures for framebuffer handling.

Vincent Pelletier
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDiCCXFEQoKRQyjtURAryjAJ9Xppf3KxB4aYi8m5V1Xzta6fB5XgCeJXwE
lVa4Lay3OgE/JF3WHBqfZ0k=
=RJLt
-----END PGP SIGNATURE-----

	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

Re: Video subsystem draft

[Yoshinori K. Okuji]

On Saturday 26 November 2005 03:36 pm, Vincent Pelletier wrote:
> By the way, there is already a font format handled by IEEE1275
> frame buffercards.
> From the standard :
>
> set-font ( addr width height advance min-char #glyphs -- )
> Set the current font as specified.

If my understanding is correct, the firmware does not handle multiple widths 
of fonts. If I'm wrong, correct me.

> By the way, I think we should start a discussion on the API common to
> all architectures for framebuffer handling.

Vesa is doing this, IIRC.

Okuji

Re: Video subsystem draft

[Vesa Jääskeläinen]

Vincent Pelletier wrote:
> By the way, I think we should start a discussion on the API common to
> all architectures for framebuffer handling.

Currently there is a terminal implementation that uses video subsystem
to render screen. So basicly in every arch there must be a video driver
if you want graphical console.

You can see my current idea how to use video driver in grub wiki:
http://grub.enbug.org/VideoSubsystem

Actual implementation is currently in a bit flux, so I don't want people
to start coding until all really needed features work correctly with one
driver so others can use it as a reference when developing other video
drivers.

If you want to look at you can see current implementation in URL that I
posted day or two ago to list.

Re: Video subsystem draft

[Marco Gerards]

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

> Vincent Pelletier wrote:
>> By the way, I think we should start a discussion on the API common to
>> all architectures for framebuffer handling.
>
> Currently there is a terminal implementation that uses video subsystem
> to render screen. So basicly in every arch there must be a video driver
> if you want graphical console.
>
> You can see my current idea how to use video driver in grub wiki:
> http://grub.enbug.org/VideoSubsystem

As I still can't log in on the wiki, I better reply here :-)

First of all I'd like to see some double buffering feature.  Will that
be somehow possible?  In that case we need functions like:

- Switching to a buffer, making it visible.
- Selecting which buffer is used for output.
What is the emulation you talk about for set palette?

Why are viewports needed?

Have you thought about how to load bitmaps?

I don't like using grub_uint*_t for parameters.  Just use normal
integers instead.  These types just have to be used for ABIs and
network and disk access.  In the case of APIs such types should be
avoided.

So better use "int height" instead of "grub_uint32_t height".  This is
especially important for portability and it serves no purpose.

Is it possible to pass parameters like depth to grub_video_setup?

Will it be possible for other users than the terminal to use these
functions?  I think that would be nice.  But in that case a function
should be used to redraw the screen.

How would scrolling work if a background picture was used?

Thanks,
Marco

Re: Video subsystem draft

[Yoshinori K. Okuji]

On Friday 09 December 2005 11:44 pm, Marco Gerards wrote:
> Why are viewports needed?

Because we want to set a region to display a menu, I guess.

Okuji

Re: Video subsystem draft

[Vesa Jääskeläinen]

Marco Gerards wrote:
> Vesa Jääskeläinen <chaac@nic.fi> writes:
> 
>> Vincent Pelletier wrote:
>>> By the way, I think we should start a discussion on the API common to
>>> all architectures for framebuffer handling.
>> Currently there is a terminal implementation that uses video subsystem
>> to render screen. So basicly in every arch there must be a video driver
>> if you want graphical console.
>>
>> You can see my current idea how to use video driver in grub wiki:
>> http://grub.enbug.org/VideoSubsystem
> 
> As I still can't log in on the wiki, I better reply here :-)
> 
> First of all I'd like to see some double buffering feature.  Will that
> be somehow possible?  In that case we need functions like:
> 
> - Switching to a buffer, making it visible.
> - Selecting which buffer is used for output.

Yes, double buffering is possible of course ;) It's not even hard one.
There are some issues that must be decided.

Most important one is, what you want to do with double buffer, do you
want access to actual pixel data? Should this access be hidden or
emulated. What happens when there are different graphics modes. Do we
need to implement pixel data conversion layer.

Or do you want only to hide some possible artifacts? Eg. having many
changes to whole screen per refresh cycle? Current idea was only draw to
screen when there is something new to draw.

Now if we assume that there will be double buffering then there is
problem where the actual data is stored. As we don't have fancy drivers
for each video card there, we must use provided features of VBE (or
similar interface).

In banked modes, switching the bank can be slow, and if we require that
double buffer is store on video memory, accessing (read&write) can be
slow. It could also limit some modes from user as there is no room for
double buffer. And worst case is here that some implementations of VBE
can be buggy in this case... Ever seen div by zero from video bios ;) ?

If we store this memory to host memory, then accessing it is fast, but
swapping the whole screen can be slow. We could of course implement some
dirty regions to optimize transfer time. Now if you want direct access
to frame buffer data (read&write) then who is responsible to make sure
pixel data is correct for the display? Do we need to convert pixel data
on transfer?

My idea was following in current implementation:
- Supply basic operations on video driver
- If there is complex graphics needed, use bitmap (it would have
transparency support)
- When bitmap is loaded, it would be converted to device compatible bitmap
- If there is a need to generate bitmap data, it should be done in
emulated pixel buffer (something like R8G8B8A8) and then converted to
device compatible bitmap.

Ps. I will answer rest of your questions later on, now I need to move on
elsewhere :)

Re: Video subsystem draft

[Marco Gerards]

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

>> First of all I'd like to see some double buffering feature.  Will that
>> be somehow possible?  In that case we need functions like:
>> 
>> - Switching to a buffer, making it visible.
>> - Selecting which buffer is used for output.
>
> Yes, double buffering is possible of course ;) It's not even hard one.
> There are some issues that must be decided.
>
> Most important one is, what you want to do with double buffer, do you
> want access to actual pixel data? Should this access be hidden or
> emulated. What happens when there are different graphics modes. Do we
> need to implement pixel data conversion layer.
>
> Or do you want only to hide some possible artifacts? Eg. having many
> changes to whole screen per refresh cycle? Current idea was only draw to
> screen when there is something new to draw.

Right, but in that case you can draw to another buffer and just
switch.  Usually that switch changing a pointer or offset in a
register of your video card.

> Now if we assume that there will be double buffering then there is
> problem where the actual data is stored. As we don't have fancy drivers
> for each video card there, we must use provided features of VBE (or
> similar interface).

If double buffering is not available we have to make a copy of the
buffer to the video memory.

> In banked modes, switching the bank can be slow, and if we require that
> double buffer is store on video memory, accessing (read&write) can be
> slow. It could also limit some modes from user as there is no room for
> double buffer. And worst case is here that some implementations of VBE
> can be buggy in this case... Ever seen div by zero from video bios ;) ?

AFAIK you can access all video memory from protected mode without bank
switching.  Please correct me if I am wrong.  Anyways, we can always
implement double buffering in software or make it optional or so.

> If we store this memory to host memory, then accessing it is fast, but
> swapping the whole screen can be slow. We could of course implement some
> dirty regions to optimize transfer time. Now if you want direct access
> to frame buffer data (read&write) then who is responsible to make sure
> pixel data is correct for the display? Do we need to convert pixel data
> on transfer?

In that case the pixel data should be correct for the display so it
can be directly copied.

Anyways, if the hardware is capable of doing double buffer, I would
prefer that to avoid flickering.  It could be optional or so.  But it
would be nice if the option is there.

> My idea was following in current implementation:
> - Supply basic operations on video driver
> - If there is complex graphics needed, use bitmap (it would have
> transparency support)

How would it support transparency?

> - When bitmap is loaded, it would be converted to device compatible bitmap

Sounds sane.

> - If there is a need to generate bitmap data, it should be done in
> emulated pixel buffer (something like R8G8B8A8) and then converted to
> device compatible bitmap.

Ok.

--
Marco

Re: Video subsystem draft

[Vesa Jääskeläinen]

Marco Gerards wrote:
> Vesa Jääskeläinen <chaac@nic.fi> writes:
> 
>>> First of all I'd like to see some double buffering feature.  Will that
>>> be somehow possible?  In that case we need functions like:
>>>
>>> - Switching to a buffer, making it visible.
>>> - Selecting which buffer is used for output.
>> Yes, double buffering is possible of course ;) It's not even hard one.
>> There are some issues that must be decided.
>>
>> Most important one is, what you want to do with double buffer, do you
>> want access to actual pixel data? Should this access be hidden or
>> emulated. What happens when there are different graphics modes. Do we
>> need to implement pixel data conversion layer.
>>
>> Or do you want only to hide some possible artifacts? Eg. having many
>> changes to whole screen per refresh cycle? Current idea was only draw to
>> screen when there is something new to draw.
> 
> Right, but in that case you can draw to another buffer and just
> switch.  Usually that switch changing a pointer or offset in a
> register of your video card.

Offset in video card might not be accessible. With VBE it is hidden from
coder and there is optional function to setup screen starting position.

>> Now if we assume that there will be double buffering then there is
>> problem where the actual data is stored. As we don't have fancy drivers
>> for each video card there, we must use provided features of VBE (or
>> similar interface).
> 
> If double buffering is not available we have to make a copy of the
> buffer to the video memory.

Ok.

>> In banked modes, switching the bank can be slow, and if we require that
>> double buffer is store on video memory, accessing (read&write) can be
>> slow. It could also limit some modes from user as there is no room for
>> double buffer. And worst case is here that some implementations of VBE
>> can be buggy in this case... Ever seen div by zero from video bios ;) ?
> 
> AFAIK you can access all video memory from protected mode without bank
> switching.  Please correct me if I am wrong.  Anyways, we can always
> implement double buffering in software or make it optional or so.

Only when there is complete frame buffer available. It's not case with
banked only video cards :). Fortunely those are starting to be rare, but
there are some still left. I noticed that someone added to TODO list (in
wiki) to support banked modes in VBE, there might be a reason for this.

Oh btw. That crashing thing was when setting up frame buffer dimensions
(and it failed quite badly). And this is needed when supporting hardware
double buffering.

But we can emulate this in software to ease it out as you suggested.

>> If we store this memory to host memory, then accessing it is fast, but
>> swapping the whole screen can be slow. We could of course implement some
>> dirty regions to optimize transfer time. Now if you want direct access
>> to frame buffer data (read&write) then who is responsible to make sure
>> pixel data is correct for the display? Do we need to convert pixel data
>> on transfer?
> 
> In that case the pixel data should be correct for the display so it
> can be directly copied.

Ok.

> Anyways, if the hardware is capable of doing double buffer, I would
> prefer that to avoid flickering.  It could be optional or so.  But it
> would be nice if the option is there.

I think this must be standard feature from coders point of view.
Otherwise there might be mistakes on handling it correctly.

>> My idea was following in current implementation:
>> - Supply basic operations on video driver
>> - If there is complex graphics needed, use bitmap (it would have
>> transparency support)
> 
> How would it support transparency?

Using "alpha" component of the colors in bitmap. If it is zero, it is
completely transparent (no need to draw a thing), if it would be 255 it
is completely opaque. And between those, it would require some calculation.

Re: Video subsystem draft

[Vesa Jääskeläinen]

Marco Gerards wrote:
> What is the emulation you talk about for set palette?

In order to support theming, there is most likely some predefined
colors. We could use palette to save those defaults. When certain color
would be needed then we just ask for color with grub_video_map_color ()
and it would access palette and return hardware compatible color value.
In indexed VGA modes there is possibility also to set palette, and user
could use special palette. Now if we emulate this behavior also in RGB
modes, it would make life easier for theme scripter/designer as in
indexed color modes and in RGB color modes behavior would be same.

Now what are the actual values for the grub_video_map_color, I haven't
yet decided. But I was thinking something like this:

Values 0-255 would be identical to the palette indices. If value would
be 256 or larger then it would be a theming alias for palette index and
it would be accessed thru theming framework that has not yet been
designed and then theming framework would either return index to palette
or actual RGB value depending on the active video mode.

Let's assume theme designer would like to have three colors of a blue
and there is no comparable colors in standard VGA palette. And he would
also like to specify those colors also in indexed color modes. So he
decides to configure those color to palette. Now if those colors would
be later requested by rgb mapping or by using those indices those colors
would be available and show correctly to end user both in RGB modes and
in index color modes. And what is most important, theme designer doesn't
need to bother whether end user has index color or RGB mode.

> Why are viewports needed?

Idea of the viewports was that if there is certain region of the window
that should be saved from editing. Let's assume C-64 style console ;).
You have border where there is one specific color and then different
area where the text is being drawn.

Now we first clear the whole screen with border color and then setup
viewport where the text would be displayed. Then all rest functions to
draw something to screen is being limited that viewport and border area
would be saved from modifications (no need to redraw those). Now if we
thinkg about scrolling screen up. On normal case whole screen would be
scrolled and borders would need to be redrawn, but with viewport only
place to need redrawing is the bottom area that is new.

Of course this would change a bit if there is background bitmap. But in
that case it would still make it easier to use the actual display area
as all coordinates are relative to viewport. Only hard problem would be
on scrolling. Now if you have animated background you must render
affected section all the time and depending on animation you most likely
would not need to setup viewport. If there is no need for viewport, it
will automatically be maximized to full screen, so if it is not set,
then user doesn't even notice it's limiting factor.

> 
> Have you thought about how to load bitmaps?

My idea for loading bitmaps would be that there would be different
functions to load bitmaps. And when bitmap is loaded the bitmap would be
converted automatically to display optimal format. Only disadvantage of
this is that if screen mode changes, the bitmap information would be
needed to be reloaded in order to be displayed correctly.

One option here would be that there would be that display driver would
be required to convert between different formats. This could create some
overhead and cause some slowdown.

I haven't thinked what would be best format to save those bitmaps, we
could support multiple formats by using modules to hide differences
between those and then have some wrapper function to walk thru all
bitmap loader modules.

> I don't like using grub_uint*_t for parameters.  Just use normal
> integers instead.  These types just have to be used for ABIs and
> network and disk access.  In the case of APIs such types should be
> avoided.
> 
> So better use "int height" instead of "grub_uint32_t height".  This is
> especially important for portability and it serves no purpose.

Ok... grub_uint32_t is unsigned version, so would it be reasonable to
use unsigned int instead of int and do we assume that int is normally
signed, or should I explicitly write signed int or unsigned int?

> Is it possible to pass parameters like depth to grub_video_setup?

Depth?... Are you thinking 3D-displays here :) ? Or are you building up
some kind of Z-buffering?

> Will it be possible for other users than the terminal to use these
> functions?  I think that would be nice.  But in that case a function
> should be used to redraw the screen.

Most of the functions could be used from scripts, only problem is that
scripts would need to handle different data types correctly (like bitmap
etc).

> How would scrolling work if a background picture was used?

I was planning that terminal would implement background picture
handling. And if there is a background picture that would scroll when
the screen is about to scroll. That area must be redrawn. Fanciest
option here would be that there would be graphical layers, but that is
more a "window manager issue" than a video driver issue.

Re: Video subsystem draft

[Marco Gerards]

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

>> I don't like using grub_uint*_t for parameters.  Just use normal
>> integers instead.  These types just have to be used for ABIs and
>> network and disk access.  In the case of APIs such types should be
>> avoided.
>> 
>> So better use "int height" instead of "grub_uint32_t height".  This is
>> especially important for portability and it serves no purpose.
>
> Ok... grub_uint32_t is unsigned version, so would it be reasonable to
> use unsigned int instead of int and do we assume that int is normally
> signed, or should I explicitly write signed int or unsigned int?

I would just used `int' and `unsigned int'.  It's just important that
you don't explicitly use a specific amount of bits and leave that to
the compiler.

>> Is it possible to pass parameters like depth to grub_video_setup?
>
> Depth?... Are you thinking 3D-displays here :) ? Or are you building up
> some kind of Z-buffering?

Depth means the amount colors.  For example you can have a 16 bits
depth, which means 65536 colors per pixel.

>> Will it be possible for other users than the terminal to use these
>> functions?  I think that would be nice.  But in that case a function
>> should be used to redraw the screen.
>
> Most of the functions could be used from scripts, only problem is that
> scripts would need to handle different data types correctly (like bitmap
> etc).

Of course.

>> How would scrolling work if a background picture was used?
>
> I was planning that terminal would implement background picture
> handling. And if there is a background picture that would scroll when
> the screen is about to scroll. That area must be redrawn. Fanciest
> option here would be that there would be graphical layers, but that is
> more a "window manager issue" than a video driver issue.

If you use double buffering, you can use a few buffers:

1) the background
2) the text and whatever the console needs for output
3) some buffer to which #1 is copied and #2 is copied (using 0 as
   transparancy or so)
4) The visible buffer

In that case you draw to buffer 2, prepare buffer 3.  When you want to
show buffer 3 you switch it with buffer 4.

What do you think of that?

--
Marco

Re: Video subsystem draft

[Vesa Jääskeläinen]

Marco Gerards wrote:
> Vesa Jääskeläinen <chaac@nic.fi> writes:
> 
>>> I don't like using grub_uint*_t for parameters.  Just use normal
>>> integers instead.  These types just have to be used for ABIs and
>>> network and disk access.  In the case of APIs such types should be
>>> avoided.
>>>
>>> So better use "int height" instead of "grub_uint32_t height".  This is
>>> especially important for portability and it serves no purpose.
>> Ok... grub_uint32_t is unsigned version, so would it be reasonable to
>> use unsigned int instead of int and do we assume that int is normally
>> signed, or should I explicitly write signed int or unsigned int?
> 
> I would just used `int' and `unsigned int'.  It's just important that
> you don't explicitly use a specific amount of bits and leave that to
> the compiler.

Ok. Can I assume that unsigned int always has at least 32 bits? Or do I
need to specify some types needing 32 bits using grub_uint32_t ? I will
use grub_uint32_t and friends in VBE structures, but in video subsystem
it is irrelevant.

>>> Is it possible to pass parameters like depth to grub_video_setup?
>> Depth?... Are you thinking 3D-displays here :) ? Or are you building up
>> some kind of Z-buffering?
> 
> Depth means the amount colors.  For example you can have a 16 bits
> depth, which means 65536 colors per pixel.

Okey, bits per pixel then, or color depth :)... Currently it is auto
detecting best possible bits per pixel mode. We could allow mode_type
parameter to assist on selection of the best matching mode. And if there
is no exact match, one bit in mode_type could tell what to do in that
situation. Should best matching mode be selected, or only exact matches
allowed. If there is no valid mode in display driver it will fall back
to next listed driver and try to initialize mode with same parameters.

I thinked that selecting the bpp is not important and I optimized it out
 :), but if this is wanted feature I think guiding is better option.
There are many different RGB modes and I think that it would be most
reasonable to ask generally a RGB mode and then select best one.

>>> How would scrolling work if a background picture was used?
>> I was planning that terminal would implement background picture
>> handling. And if there is a background picture that would scroll when
>> the screen is about to scroll. That area must be redrawn. Fanciest
>> option here would be that there would be graphical layers, but that is
>> more a "window manager issue" than a video driver issue.
> 
> If you use double buffering, you can use a few buffers:
> 
> 1) the background
> 2) the text and whatever the console needs for output
> 3) some buffer to which #1 is copied and #2 is copied (using 0 as
>    transparancy or so)
> 4) The visible buffer
> 
> In that case you draw to buffer 2, prepare buffer 3.  When you want to
> show buffer 3 you switch it with buffer 4.
> 
> What do you think of that?

That's not exactly double buffering :). It's more like a layering
combined with double buffering.

But your idea of layers with data can be used and is most likely good
approach. But should this be implemented in video driver or elsewhere. I
have tried to make video drivers simple to implement. Rest of the
graphics system would then implement fancier functions.

In here I would see this as a job of "window manager". In grub's case
this is more like a responsibility of the terminal :).

There are two approaches that I see here:

1) Terminal's responsibility

Rendering sequence would be:

- Zero out back buffer (optional)
- Terminal would draw background bitmap
- Terminal could use multiple additional bitmaps layers and upper layers
could include transparency information
- Terminal must use font manager in order to draw text, unless glyph
drawing is implemented elsewhere.
- Swap front/back buffers

Now good thing here is that video driver is not bloated. Bad thing here
is that handling of those bitmaps would most likely need same
functionality as is provided in non-bitmap video driver.

2) Partially video drivers responsibility

Add support for rendering targets. Caller could create virtual screens
that can be used to render with normal drawing functions. This would
shift some of the jobs to video subsystem.

Rendering sequence could be something like:

- Zero out back buffer (optional)
- Render background from render target 0 (or from bitmap)
- Render additional layers from other render targets (or from bitmaps)
- Render text layer using font manager or another render target
- Swap front/back buffers

In order to use render targets, they must be created and they should be
based on the actual screen properties. Eg. Same color order and so on.
Resolution of the render targets could be different. This is to fasten
blitting process. There is also possibility to "lock" render target in
order to do pixel buffer modifications.

To map text layer to render target ideology, there would be need to
create correct size render target. Then use display driver provided
glyph rendering code to display actual text. Scrolling is really easy in
this case. But when drawing to render target we must remember to specify
all transparent areas.

Con's of the render targets is that eats quite lot of more memory than
then first idea. But with them we can get prettier output more easily.

This render target could be a viable solution, even though it shifts
some more work to video subsystem. It's not too hard to implement render
target support. So if this is a route we take it's Ok for me.

But now comes the important question :)... How advanced we want this
video subsystem to be in GRUB ?

Re: Video subsystem draft

[Marco Gerards]

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

>> I would just used `int' and `unsigned int'.  It's just important that
>> you don't explicitly use a specific amount of bits and leave that to
>> the compiler.
>
> Ok. Can I assume that unsigned int always has at least 32 bits? Or do I
> need to specify some types needing 32 bits using grub_uint32_t ? I will
> use grub_uint32_t and friends in VBE structures, but in video subsystem
> it is irrelevant.

It's 32 bits on a 32 bits architecture and 64 bits on a 64 bits
architecture.  Using 32 bits on some 64 bits architecture might be
suboptimal and I think it is harder to read.  But it is ok to assume
you have at least 32 bits, but it can be more on some archs.

>>>> Is it possible to pass parameters like depth to grub_video_setup?
>>> Depth?... Are you thinking 3D-displays here :) ? Or are you building up
>>> some kind of Z-buffering?
>> 
>> Depth means the amount colors.  For example you can have a 16 bits
>> depth, which means 65536 colors per pixel.
>
> Okey, bits per pixel then, or color depth :)... Currently it is auto
> detecting best possible bits per pixel mode. We could allow mode_type
> parameter to assist on selection of the best matching mode. And if there
> is no exact match, one bit in mode_type could tell what to do in that
> situation. Should best matching mode be selected, or only exact matches
> allowed. If there is no valid mode in display driver it will fall back
> to next listed driver and try to initialize mode with same parameters.

Ok, nice.

> I thinked that selecting the bpp is not important and I optimized it out
>  :), but if this is wanted feature I think guiding is better option.
> There are many different RGB modes and I think that it would be most
> reasonable to ask generally a RGB mode and then select best one.

It's relevant when someone made a 16bpp background image.  I am quite
sure he doesn't want to use 8 bpp. :-)

>>>> How would scrolling work if a background picture was used?
>>> I was planning that terminal would implement background picture
>>> handling. And if there is a background picture that would scroll when
>>> the screen is about to scroll. That area must be redrawn. Fanciest
>>> option here would be that there would be graphical layers, but that is
>>> more a "window manager issue" than a video driver issue.
>> 
>> If you use double buffering, you can use a few buffers:
>> 
>> 1) the background
>> 2) the text and whatever the console needs for output
>> 3) some buffer to which #1 is copied and #2 is copied (using 0 as
>>    transparancy or so)
>> 4) The visible buffer
>> 
>> In that case you draw to buffer 2, prepare buffer 3.  When you want to
>> show buffer 3 you switch it with buffer 4.
>> 
>> What do you think of that?
>
> That's not exactly double buffering :). It's more like a layering
> combined with double buffering.

That is right.

> But your idea of layers with data can be used and is most likely good
> approach. But should this be implemented in video driver or elsewhere. I
> have tried to make video drivers simple to implement. Rest of the
> graphics system would then implement fancier functions.

I also think video drivers should be easy to implement.  So this stuff
has to be done by the framebuffer I think.  Or someplace else.

> In here I would see this as a job of "window manager". In grub's case
> this is more like a responsibility of the terminal :).

Yeah, window manager support is something we should focus at, at
first. ;-)

> There are two approaches that I see here:
>
> 1) Terminal's responsibility
>
> Rendering sequence would be:
>
> - Zero out back buffer (optional)
> - Terminal would draw background bitmap
> - Terminal could use multiple additional bitmaps layers and upper layers
> could include transparency information
> - Terminal must use font manager in order to draw text, unless glyph
> drawing is implemented elsewhere.
> - Swap front/back buffers
>
> Now good thing here is that video driver is not bloated. Bad thing here
> is that handling of those bitmaps would most likely need same
> functionality as is provided in non-bitmap video driver.

I am not sure if I understand you.  Can you give two practical
examples of where it is better and where it is worse?

> 2) Partially video drivers responsibility
>
> Add support for rendering targets. Caller could create virtual screens
> that can be used to render with normal drawing functions. This would
> shift some of the jobs to video subsystem.
>
> Rendering sequence could be something like:
>
> - Zero out back buffer (optional)
> - Render background from render target 0 (or from bitmap)
> - Render additional layers from other render targets (or from bitmaps)
> - Render text layer using font manager or another render target
> - Swap front/back buffers

You want this so hardware layering features can be used?  Did you look
at some systems like XFree already?

> In order to use render targets, they must be created and they should be
> based on the actual screen properties. Eg. Same color order and so on.
> Resolution of the render targets could be different. This is to fasten
> blitting process. There is also possibility to "lock" render target in
> order to do pixel buffer modifications.

What does locking mean in this context?

> Con's of the render targets is that eats quite lot of more memory than
> then first idea. But with them we can get prettier output more easily.

Isn't the output just the same?

> This render target could be a viable solution, even though it shifts
> some more work to video subsystem. It's not too hard to implement render
> target support. So if this is a route we take it's Ok for me.

I am not yet sure if I understand it completely, I should re-read it
when I am not that tired. ;)

> But now comes the important question :)... How advanced we want this
> video subsystem to be in GRUB ?

As I see it we need some killer feature to compete with GRUB Legacy.
Some neat graphics support can be that killer feature.  Especially if
it is cross-platform.

Something we should keep in mind is that if we want something new, we
could always extend the interfaces.  So no need for interfaces to
support 3D cards yet. ;-)

--
Marco

Re: Video subsystem draft

[Vesa Jääskeläinen]

Marco Gerards wrote:
> Vesa Jääskeläinen <chaac@nic.fi> writes:
>> I thinked that selecting the bpp is not important and I optimized it out
>>  :), but if this is wanted feature I think guiding is better option.
>> There are many different RGB modes and I think that it would be most
>> reasonable to ask generally a RGB mode and then select best one.
> 
> It's relevant when someone made a 16bpp background image.  I am quite
> sure he doesn't want to use 8 bpp. :-)

I will try to add some optional flags there that can be used to guide on
mode selection. Or help on selecting actual video mode.

>>>>> How would scrolling work if a background picture was used?
>>>> I was planning that terminal would implement background picture
>>>> handling. And if there is a background picture that would scroll when
>>>> the screen is about to scroll. That area must be redrawn. Fanciest
>>>> option here would be that there would be graphical layers, but that is
>>>> more a "window manager issue" than a video driver issue.
>>> If you use double buffering, you can use a few buffers:
>>>
>>> 1) the background
>>> 2) the text and whatever the console needs for output
>>> 3) some buffer to which #1 is copied and #2 is copied (using 0 as
>>>    transparancy or so)
>>> 4) The visible buffer
>>>
>>> In that case you draw to buffer 2, prepare buffer 3.  When you want to
>>> show buffer 3 you switch it with buffer 4.
>>>
>>> What do you think of that?
>> That's not exactly double buffering :). It's more like a layering
>> combined with double buffering.
> 
> That is right.
> 
>> But your idea of layers with data can be used and is most likely good
>> approach. But should this be implemented in video driver or elsewhere. I
>> have tried to make video drivers simple to implement. Rest of the
>> graphics system would then implement fancier functions.
> 
> I also think video drivers should be easy to implement.  So this stuff
> has to be done by the framebuffer I think.  Or someplace else.
> 
>> In here I would see this as a job of "window manager". In grub's case
>> this is more like a responsibility of the terminal :).
> 
> Yeah, window manager support is something we should focus at, at
> first. ;-)
> 
>> There are two approaches that I see here:
>>
>> 1) Terminal's responsibility
>>
>> Rendering sequence would be:
>>
>> - Zero out back buffer (optional)
>> - Terminal would draw background bitmap
>> - Terminal could use multiple additional bitmaps layers and upper layers
>> could include transparency information
>> - Terminal must use font manager in order to draw text, unless glyph
>> drawing is implemented elsewhere.
>> - Swap front/back buffers
>>
>> Now good thing here is that video driver is not bloated. Bad thing here
>> is that handling of those bitmaps would most likely need same
>> functionality as is provided in non-bitmap video driver.
> 
> I am not sure if I understand you.  Can you give two practical
> examples of where it is better and where it is worse?

Biggest difference here is that in this case, video drawing functions
can only be used on frame buffer. Drawing functions doesn't support on
drawing to bitmaps. There would be immediate need to add code to render
data bitmaps, or this must be done by coder. So this could duplicate
some code.

Pro's of using this is that it doesn't require so much memory as there
is no need to store multiple layers in memory. This is better option
when there is no so much memory available.

Con's of using this is that you must to draw ALL text on screen again on
when scrolling screen or if there is some animation on other layers
(assuming that it happens over/under of the text). You most likely need
additional functions to modify bitmaps if same functionality is wanted
as on case 2.

>> 2) Partially video drivers responsibility
>>
>> Add support for rendering targets. Caller could create virtual screens
>> that can be used to render with normal drawing functions. This would
>> shift some of the jobs to video subsystem.
>>
>> Rendering sequence could be something like:
>>
>> - Zero out back buffer (optional)
>> - Render background from render target 0 (or from bitmap)
>> - Render additional layers from other render targets (or from bitmaps)
>> - Render text layer using font manager or another render target
>> - Swap front/back buffers
> 
> You want this so hardware layering features can be used?  Did you look
> at some systems like XFree already?

I was more thinking of implementing this on software. Xfree is a bit too
advanced project and I am not familiar with it's licensing, how well it
will fit in this case. So far I haven't used hardware layering
techniques? Or I think so :).

>> In order to use render targets, they must be created and they should be
>> based on the actual screen properties. Eg. Same color order and so on.
>> Resolution of the render targets could be different. This is to fasten
>> blitting process. There is also possibility to "lock" render target in
>> order to do pixel buffer modifications.
> 
> What does locking mean in this context?

This is a term from DirectX, in there locking means that certain memory
area is being allowed to be altered. By locking you specify that this is
being modified and that cannot be moved around by driver framework. When
you are ready and unlock that memory then data is transferred to it's
preferred location and possible conversions is also performed.

>> Con's of the render targets is that eats quite lot of more memory than
>> then first idea. But with them we can get prettier output more easily.
> 
> Isn't the output just the same?

Output can be made same. This is more a conceptual problem. It is more
like a what functions can be used to do what operations. If this case,
there would not be so many functions to be implemented. But it would
shift some more code to video drivers. But at same time it would make
usage more streamlined.

I will point out the word _easily_ over there ;)

>> This render target could be a viable solution, even though it shifts
>> some more work to video subsystem. It's not too hard to implement render
>> target support. So if this is a route we take it's Ok for me.
> 
> I am not yet sure if I understand it completely, I should re-read it
> when I am not that tired. ;)

I'll hope we can come up with decision what we want before next version
deadline comes :)

>> But now comes the important question :)... How advanced we want this
>> video subsystem to be in GRUB ?
> 
> As I see it we need some killer feature to compete with GRUB Legacy.
> Some neat graphics support can be that killer feature.  Especially if
> it is cross-platform.

Well.. We haven't even started to think about theming and scripting of
the GUI's :)

There are even more things to think... Some of those can cause some
headache, like timer events... How those are good to be implemented...
But there probably should be some limit at some point. Or we have
complete graphical API interface with RTOS and no need to have actual
OS... Think about that :)

Re: Video subsystem draft

[Vesa Jääskeläinen]

Vincent Pelletier wrote:
> By the way, there is already a font format handled by IEEE1275
> frame buffercards.
> - From the standard : 
> 
> set-font ( addr width height advance min-char #glyphs -- )
> Set the current font as specified.
> 
> So I think they can handle arbitrary-sized glyphs.
> I can't find the font data definition, but as "default-font" returns
> all those values for the default font, reverse engineering will be a
> matter of minutes.
> 
> If the font format you want to design could be compatible with ths one,
> it would be a pleasure to port it to sparc :) - and probably the same
> for PPC.

I am not familiar with that, but current implementation only supports
case when grub can read the actual font data itself and render it. So at
this point this is a requirement for graphical console. In principle if
necessary data can be acquired, hardware renderable fonts can be used
but there must be a mechanism to specify viewport that hardware font
rendering checks and does not exceed.

Currently font format itself is open to suggestions and I would like to
hear about possible issues related to some "foreigner" fonts that I
haven't used before. There perhaps are many different kinds of scripts
that might be unreasonable to support but at this point nothing is
dropped out.

Re: Video subsystem draft

[Yoshinori K. Okuji]

On Saturday 26 November 2005 01:28 am, Vesa Jääskeläinen wrote:
> > Compression might make the performance horrible, because PPF is very
> > optimized.
>
> When there is a caching implemented in a one day, it's only initial
> cost. So far I haven't seen performance problems with this. But then
> again I haven't tried it too much.

I must test it myself, too. The performance of reading a compressed file is 
slow, because of seeking. Seeking forward is fast, but seeking backward is 
very slow. So compression makes sense for OS images, but not much for font 
files.

The most important part is the initial cost, BTW. Since a boot loader must be 
quick to start up (otherwise, the user loses some seconds every time), 
caching is not so important.

> Byte order is currently exactly the same as in .hex file :)

Yes.

> It has minor issue with widechar fonts (char width > 1). It like
> contains two different font data. First there is first half of like
> normal 8x16 font and then there is second half. My idea would be to
> store bitmap in scanlines instead of character blocks so I can take
> whole character width and draw that.

I see.

Okuji

Re: Video subsystem draft

[Vesa Jääskeläinen]

Yoshinori K. Okuji wrote:
> On Saturday 26 November 2005 01:28 am, Vesa Jääskeläinen wrote:
>>> Compression might make the performance horrible, because PPF is very
>>> optimized.
>> When there is a caching implemented in a one day, it's only initial
>> cost. So far I haven't seen performance problems with this. But then
>> again I haven't tried it too much.
> 
> I must test it myself, too. The performance of reading a compressed file is 
> slow, because of seeking. Seeking forward is fast, but seeking backward is 
> very slow. So compression makes sense for OS images, but not much for font 
> files.

> The most important part is the initial cost, BTW. Since a boot loader must be 
> quick to start up (otherwise, the user loses some seconds every time), 
> caching is not so important.

There is this transparent gzip support in gz file open, that diagnoses
file to decide wether it is gzipped or not. If there is transparent
option specified, it can also read nongzipped files. This would allow
user to pack font file if there is a need to compress it (of course with
cost of speed)

If I remember correctly I also saw caching of sectors in disk code, so
basicly if disk cache is big enough old font data will already be in
memory. And this will only cause little delay as there is no I/O
latency. Actual testing in real hardware will tell how good this is. I
am currently only running this on vmware.

Re: Video subsystem draft

[Marco Gerards]

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

> If I remember correctly I also saw caching of sectors in disk code, so
> basicly if disk cache is big enough old font data will already be in
> memory. And this will only cause little delay as there is no I/O
> latency. Actual testing in real hardware will tell how good this is. I
> am currently only running this on vmware.

The disk cache is invalidated after one second, IIRC.

--
Marco

Re: Video subsystem draft

[Vesa Jääskeläinen]

Vesa Jääskeläinen wrote:
> Just in case you (or someone else) want to test current version, I have
> uploaded it to:
> http://jumi.lut.fi/~vjaaskel/grub2/grub2-video-20051126.tar.gz
> 
> I noticed that when ever I call grub_error something brakes, but what is
> doing it I can't tell. There is a testerr3 function in video/video.c
> that tries to demonstrate when does the corruption occur.
> 
> Oh.. and before anyone asks, video implementation is not still complete.
> Code itself probably wont compile in other archs. But I think the
> interface itself could be OK. But it needs to mature a bit. VGA module
> is disabled until I have time to look how to modify it to fit new system.

Here is most up to date version:
http://jumi.lut.fi/~vjaaskel/grub2/grub2-video-20051128.tar.gz

I need to do more checks that everything works correctly and verity that
all features are present. So it is still not ready to be committed. I
think that it currently has all basic functionality that is provided by
older graphic terminals (except color changing).

When I was testing scrolling functionality and writing some garbage from
keyboard, at around column 79/80 all the rest characters on line gets
corrupted. I am not sure is this related to that other issue, but if
someone gets some ideas where the problem could come I would like to
hear about it.

I noticed that there are some hard coded 79's in command line parsing,
but hadn't got enough time yet to investigate it.

Quick help how to test it yourself (/dev/fd0 contains valid floppy):

cd grub2.video
./configure
make && ../makegrub

There is grub.cfg included that loads all necessary modules.

After booting:
terminal videoterm

Re: Video subsystem draft

[Vesa Jääskeläinen]

Ok... The problem is with grub_errno. There might be other cases where
this problem shows up too. But with font manager this is easy to see.

In my testerr3 testing function (in video.c) I added simple:

  grub_errno = GRUB_ERR_NOT_IMPLEMENTED_YET;
  grub_printf("error: no error :)\n");

Now it corrupted first 'e' character over there.

If I set grub_errno to zero, it outputted correctly. So I started to
think what is the real cause for this. I modified my video driver to
only set grub_errno when there is an real error situation. And the
behavior changed a bit, after setting up grub_errno to non-zero every
character got corrupted until the prompt came.

Now only reason to corrupt this is that something goes to different code
path because grub_errno is set. And this something is most likely the
disk/file system subsystem. Now this is also a problem if there is any
other disk operation done and an error is being set.

Font manager failed because it could not read disk for some reason.

Now I am open for ideas how and where to fix this problem.