Framebuffer

Framebuffer

[Marco Gerards]

Hi,

As I quickly mentioned in my email yesterday, I want to have a look at
the vga terminal.  This vga terminal is just one of the many
framebuffers that will be implemented, as far as I am concerned.  On
the PC we will have the VESA terminal someday.  It should be possible
to get a framebuffer on the new world macs too.  On some machines
there is only a framebuffer and no textmode.

To avoid code duplication it might be the best to write one generic
terminal called framebuffer which can be configured to work with many
kinds of framebuffers.  In this email I will write down a suggestion
how it should work.  I have little experience with framebuffers on a
lot of machines so I am not sure if what I am suggestion is sane or
portable.  I hope you will make suggestions to make this design as
good as possible or come forwards with alternative solutions.

The main thing that I want to do is creating a generic terminal called
"framebuffer".  On its own it is useless, but it can communicate with
another kind of modules, video drivers.

The framebuffer should always be initialized with a video driver and
depending on the size of the screen and its depth it reserves memory.
Whenever a character is written to the terminal, the generic
framebuffer driver writes it to the internal buffer.  When it is
required to synchronize the screen that is displayed with the one in
memory, it calls a function in the video driver.

To speed up things the framebuffer sends updates to the video driver
with updates so not the entire buffer has to be copied.  The
video driver is responsible to write the updates to video memory, bank
switching and making sure it is displayed on the screen.  That means
the video driver can do stuff like double buffering, etc.

The main advantage of this approach is that the framebuffer terminal
can do anything including showing the splashimage, etc.  All smart
things happen there, the video drivers just do the stupid work.  That
means that whenever someone wants to implement a framebuffer, he only
has to write a video driver and not a complete terminal driver.

Does this make sense or does this just suck?  I hope many people will
reply on this so I can start hacking ASAP.

Thanks,
Marco

Re: Framebuffer

[Johan Grip]

Marco Gerards wrote:
<SNIP>
> Does this make sense or does this just suck?  I hope many people will
> reply on this so I can start hacking ASAP.
> 
This does indeed make sense. For the project I am involved in, AROS, we 
already use a patched version of GRUB with vesa support in it.

Our patch allows GRUB to set a vesa mode before handing over control to 
the OS, so we do not need to mess with realmode stuff in our code.

So from our perspective this would be a welcomed addition to the GRUB2 
code base.

Kind regards,
   Johan

Re: Framebuffer

[Marco Gerards]

Johan Grip <ogun@ogun.org> writes:

> Marco Gerards wrote:
> <SNIP>
>> Does this make sense or does this just suck?  I hope many people will
>> reply on this so I can start hacking ASAP.
>>
> This does indeed make sense. For the project I am involved in, AROS,
> we already use a patched version of GRUB with vesa support in it.
>
> Our patch allows GRUB to set a vesa mode before handing over control
> to the OS, so we do not need to mess with realmode stuff in our code.

This is a bit of a different discussion, I think (although related).
What you are suggesting is that the VESA part of the multiboot
specification should be implemented, right?  IIRC it is possible to
set a VESA mode just before booting the kernel if I remember the
multiboot spec correctly.  The code for that and the framebuffer can
be shared somehow.

Both a complete multiboot (or a new multiboot specification) and a
framebuffer for GRUB 2 are important to have IMHO.

Thanks,
Marco

Re: Framebuffer

[Johan Grip]

Marco Gerards wrote:
> Johan Grip <ogun@ogun.org> writes:
> 
> 
>>Marco Gerards wrote:
>><SNIP>
>>
>>>Does this make sense or does this just suck?  I hope many people will
>>>reply on this so I can start hacking ASAP.
>>>
>>
>>This does indeed make sense. For the project I am involved in, AROS,
>>we already use a patched version of GRUB with vesa support in it.
>>
>>Our patch allows GRUB to set a vesa mode before handing over control
>>to the OS, so we do not need to mess with realmode stuff in our code.
> 
> 
> This is a bit of a different discussion, I think (although related).
> What you are suggesting is that the VESA part of the multiboot
> specification should be implemented, right?  IIRC it is possible to
> set a VESA mode just before booting the kernel if I remember the
> multiboot spec correctly.  The code for that and the framebuffer can
> be shared somehow.
> 
Indeed, that was my thought. Once you have code for a vesa framebuffer 
in place, adding the multiboot compliancy would be rather simple. So 
they go hand in hand, atleast for vesa.

> Both a complete multiboot (or a new multiboot specification) and a
> framebuffer for GRUB 2 are important to have IMHO.
> 
Yes, agreed.
I think our code does not follow the multiboot spec though, as we want 
to be able to select a screenmode from the grub menu. The multiboot spec 
states that the kernel image should have info in it regarding screen 
mode etc.

//Johan

Re: Framebuffer

[Marco Gerards]

Johan Grip <ogun@ogun.org> writes:

> I think our code does not follow the multiboot spec though, as we want
> to be able to select a screenmode from the grub menu. The multiboot
> spec states that the kernel image should have info in it regarding
> screen mode etc.

And IMHO that sucks.  It would be better to improve the multiboot spec
at this point.  It would be better if it was possible somehow for the
user to configure all kinds of things.

But I will come back with ideas for an improved multiboot spec, one
that is portable, another time.

Thanks,
Marco

Re: Framebuffer

[Johan Rydberg]

Marco Gerards <metgerards@student.han.nl> writes:

> But I will come back with ideas for an improved multiboot spec, one
> that is portable, another time.

Actually, wouldn't this be the perfect time to start discussing
a multi-architecture Multiboot standard proposal?  GRUB2 is now
running on both IA-32 and PPC.

~j

Re: Framebuffer

[Yoshinori K. Okuji]

On Friday 15 October 2004 17:15, Marco Gerards wrote:
> And IMHO that sucks.

What sucks? Could you elaborate on that?

Okuji

Re: Framebuffer

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> On Friday 15 October 2004 17:15, Marco Gerards wrote:
>> And IMHO that sucks.
>
> What sucks? Could you elaborate on that?

That the mode is stored in the binary.  IMHO it would be nice if it
would be possible for the user to choose it somehow.

Thanks,
Marco

Re: Framebuffer

[Yoshinori K. Okuji]

On Saturday 16 October 2004 00:49, Marco Gerards wrote:
> That the mode is stored in the binary.  IMHO it would be nice if it
> would be possible for the user to choose it somehow.

I'm afraid that you misunderstand the purpose of the Multiboot 
Specification.

First of all, the spec is not about the user interface of a boot loader. 
It only defines a boot protocol between a boot loader and an OS image. 
It is not in the scope of the spec how the mode is chosen by the user.

This is quoted from the spec:

   All of the graphics fields are enabled by flag bit 2. They specify
the preferred graphics mode. Note that that is only a _recommended_
mode by the OS image. If the mode exists, the boot loader should set
it, when the user doesn't specify a mode explicitly. Otherwise, the
boot loader should fall back to a similar mode, if available.

Do you still believe that it sucks? I hope you will examine the spec 
before criticizing it.

Okuji

Re: Framebuffer

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> This is quoted from the spec:
>
>    All of the graphics fields are enabled by flag bit 2. They specify
> the preferred graphics mode. Note that that is only a _recommended_
> mode by the OS image. If the mode exists, the boot loader should set
> it, when the user doesn't specify a mode explicitly. Otherwise, the
> boot loader should fall back to a similar mode, if available.
>
> Do you still believe that it sucks? I hope you will examine the spec 
> before criticizing it.

No, you are right.  I misunderstood things, but it is clear now.

Thanks,
Marco

Re: Framebuffer

[Yoshinori K. Okuji]

On Friday 15 October 2004 15:51, Marco Gerards wrote:
> The main thing that I want to do is creating a generic terminal
> called "framebuffer".  On its own it is useless, but it can
> communicate with another kind of modules, video drivers.

How about having a support library like fshelp?

Okuji

Re: Framebuffer

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> On Friday 15 October 2004 15:51, Marco Gerards wrote:
>> The main thing that I want to do is creating a generic terminal
>> called "framebuffer".  On its own it is useless, but it can
>> communicate with another kind of modules, video drivers.
>
> How about having a support library like fshelp?

The same idea but the other way around.  A library is fine for me.
The main idea why I suggested videodrivers is that you really
implement drivers and not a terminal.

Thanks,
Marco

Re: Framebuffer

[Yoshinori K. Okuji]

On Sunday 17 October 2004 22:34, Marco Gerards wrote:
> The same idea but the other way around.  A library is fine for me.
> The main idea why I suggested videodrivers is that you really
> implement drivers and not a terminal.

Well, if you can use two framebuffer terminals, how do you choose one, 
if you use a single terminal called "framebuffer"?

For example, on a SiS chipset, it might be possible to use a VESA driver 
and a SiS-specific driver. If GRUB has "vesa" and "sisfb", we can just 
use "terminal vesa" or "terminal sisfb".

Okuji

Re: Framebuffer

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> On Sunday 17 October 2004 22:34, Marco Gerards wrote:
>> The same idea but the other way around.  A library is fine for me.
>> The main idea why I suggested videodrivers is that you really
>> implement drivers and not a terminal.
>
> Well, if you can use two framebuffer terminals, how do you choose one, 
> if you use a single terminal called "framebuffer"?
>
> For example, on a SiS chipset, it might be possible to use a VESA driver 
> and a SiS-specific driver. If GRUB has "vesa" and "sisfb", we can just 
> use "terminal vesa" or "terminal sisfb".

What I had in mind was using "framebuffer vesa" in that case.  But
I will use the library approach so it is not relevant anymore.  Unless
someone thinks it is?

I am afraid I can not work on this this week.  I will be gone for a
week and can not answer my emails.  But I intend to work on this for a
complete week (next week I think).  So I hope people will not work on
these things in the meanwhile, if you intend to do so, please contact
me really soon...

Thanks,
Marco