Issues in implementing VESA support

Issues in implementing VESA support

[Shivram Khandeparker]

hi

Here are some issues i encountered in implementing a VESA console
for grub2

1. What happened to get_vbe_controller_info and get_vbe_mode_info?
  They dont seem to be there in grub2. Which means il have to rewrite them.
  Which should be just a copy paste from grub legacy.. right?
  If i do write them then where do i put theses functions. In my own files
  or in say startup.s (like vga does) ?

2. In my pacth i was using custom a font which was compiled into grub.
   Since the new grub has a font manager i would like to use that instead.
   Could somebody please provide me more info on using this font manager,
   like the kind of font file it uses, does it use bitmap fonts . And how do
   i access the font data once the font file is loaded.

3. If i have more than one file then should i put them in a separate
   driectory? If yes where (under term ) ?


regards
Shivram
   

Re: Issues in implementing VESA support

[Marco Gerards]

Shivram Khandeparker <shivramk@sancharnet.in> writes:

> hi
>
> Here are some issues i encountered in implementing a VESA console
> for grub2
>
> 1. What happened to get_vbe_controller_info and get_vbe_mode_info?
>   They dont seem to be there in grub2. Which means il have to rewrite them.
>   Which should be just a copy paste from grub legacy.. right?
>   If i do write them then where do i put theses functions. In my own files
>   or in say startup.s (like vga does) ?

If there are no copyright issues, you can just copy them.  I am not
sure if the person that wrote that code assigned his copyrights to the
FSF.  If you know that, just copy it.  Otherwise Okuji can tell us.

> 2. In my pacth i was using custom a font which was compiled into grub.
>    Since the new grub has a font manager i would like to use that instead.
>    Could somebody please provide me more info on using this font manager,
>    like the kind of font file it uses, does it use bitmap fonts . And how do
>    i access the font data once the font file is loaded.

It looks to me that this is a bitmap font.  Please have a look at
`write_font' in grub2/term/i386/pc/vga.c.  Hopefully this code is
clear to you.  I hope the plan switching code does not confuse you, I
am not sure if you need that for VESA (or some VESA modes).

> 3. If i have more than one file then should i put them in a separate
>    driectory? If yes where (under term ) ?

It should go into grub2/term/i386/pc.  It depends on how many files
you need to descide if a new directory should be created.  I think you
can better do what seems the best to you.  Changing this later should
not be a problem, right?

--
Marco

Re: Issues in implementing VESA support

[Shivram Khandeparker]

On Sunday 16 May 2004 01:49, Marco Gerards wrote:

> If there are no copyright issues, you can just copy them.  I am not
> sure if the person that wrote that code assigned his copyrights to the
> FSF.  If you know that, just copy it.  Otherwise Okuji can tell us.
>

The copyright is with the FSF (AFAIK). But the real question was  
where do i put the code - in startup.S or my own .S file?

Since you mentioned assigning the copyright to FSF. How do i do that?

> It looks to me that this is a bitmap font.  Please have a look at
> `write_font' in grub2/term/i386/pc/vga.c.  Hopefully this code is
> clear to you.  I hope the plan switching code does not confuse you, I
> am not sure if you need that for VESA (or some VESA modes).

Hmmm.. looks like we are using pff coz i see this ruby script called
unifont2pff in util directory. Googling about pff did not return anything
useful. Though i did find info on unifont. I think i can figure out this
pff thing from the code, but any help would really be useful.

Il get back if i have any problems.

regdards
Shivram

Re: Issues in implementing VESA support

[Stefan Reinauer]

* Marco Gerards <metgerards@student.han.nl> [040515 22:19]:
> If there are no copyright issues, you can just copy them.  I am not
> sure if the person that wrote that code assigned his copyrights to the
> FSF.  If you know that, just copy it.  Otherwise Okuji can tell us.
 
Why would the FSF need the copyright for that piece of code? It being
GPL would be enough to make it usable in a new GPL project like grub2 is.

> > 3. If i have more than one file then should i put them in a separate
> >    driectory? If yes where (under term ) ?
> 
> It should go into grub2/term/i386/pc.  It depends on how many files
> you need to descide if a new directory should be created.  I think you
> can better do what seems the best to you.  Changing this later should
> not be a problem, right?

The hardware/VESA specific code should go below i386/pc. Any code that
can generically be reused for other machines should be placed in a
generic location. Changing this later will pretty much end up in a mess.
The file hierarchy should be an illustration of the logical program
structure. Moving the structure of the code around will end up in a
similar mess as grub 0.x

   Stefan

Re: Issues in implementing VESA support

[Marco Gerards]

Stefan Reinauer <stepan@openbios.org> writes:

> * Marco Gerards <metgerards@student.han.nl> [040515 22:19]:
>> If there are no copyright issues, you can just copy them.  I am not
>> sure if the person that wrote that code assigned his copyrights to the
>> FSF.  If you know that, just copy it.  Otherwise Okuji can tell us.
>  
> Why would the FSF need the copyright for that piece of code? It being
> GPL would be enough to make it usable in a new GPL project like grub2 is.

There is something written about the copyright assignments in the GCS:
http://www.gnu.org/prep/standards_4.html#SEC4

I am not sure about how Okuji wants to handle copyrights, but IIRC for
GRUB 2 those need to be assigned.

Anyway, this should not be a too big issue.

>> > 3. If i have more than one file then should i put them in a separate
>> >    driectory? If yes where (under term ) ?
>> 
>> It should go into grub2/term/i386/pc.  It depends on how many files
>> you need to descide if a new directory should be created.  I think you
>> can better do what seems the best to you.  Changing this later should
>> not be a problem, right?
>
> The hardware/VESA specific code should go below i386/pc. Any code that
> can generically be reused for other machines should be placed in a
> generic location. Changing this later will pretty much end up in a mess.
> The file hierarchy should be an illustration of the logical program
> structure. Moving the structure of the code around will end up in a
> similar mess as grub 0.x

This is not what I meant.  What I meant was that I we can discuss that
when we have a patch.  I'd be happy to review the patch and move
things around before applying it.

You are right about the generic code, it should be shared.  For
example the powerbooks from apple have a graphical framebuffer at
startup.

For example the code load pictures for the background (assuming that
will, be done) can be shared, just like the font code.

Thanks,
Marco

Re: Issues in implementing VESA support

[Yoshinori K. Okuji]

On Saturday 15 May 2004 21:49, Shivram Khandeparker wrote:
> 1. What happened to get_vbe_controller_info and get_vbe_mode_info?
>   They dont seem to be there in grub2. Which means il have to rewrite
> them. Which should be just a copy paste from grub legacy.. right? If
> i do write them then where do i put theses functions. In my own files
> or in say startup.s (like vga does) ?

If you need to write an assembly in real mode, startup.S is the right 
place. If you think your code is too big to include it in startup.S, 
you can make another file and have startup.S to include it.

The code in GRUB Legacy is written by me. So you can freely copy it to 
GRUB 2. No problem.

> 2. In my pacth i was using custom a font which was compiled into
> grub. Since the new grub has a font manager i would like to use that
> instead. Could somebody please provide me more info on using this
> font manager, like the kind of font file it uses, does it use bitmap
> fonts . And how do i access the font data once the font file is
> loaded.

There is no documentation for this font manager, so I describe it here 
in brief.

It supports a bitmap font which includes an index table. A font file 
must have this structure:

The 4-byte magic word ("PPF\x7f")
The number of glyphs (little-endian, 4 bytes integer)
An index table
glyphs

An index table consists of entries in this format:

Character code in Unicode (little-endian, 4 bytes integer)
Offset of the glyph from the beginning of the file (little-endian, 4 
bytes integer)

Each glyph is like this:

Width in 8-pixel unit (1 or 2)
Bitmap

For now, the font manager supports only 8x16 and 16x16 font sizes. If 
you don't like this font manager, feel free to make a better one 
yourself.

Once you make a font file, you can use it by the command "font".

Okuji

Re: Issues in implementing VESA support

[Yoshinori K. Okuji]

On Sunday 16 May 2004 09:44, Shivram Khandeparker wrote:
> Since you mentioned assigning the copyright to FSF. How do i do that?

I will ask you after you produce something significant legally.

> Hmmm.. looks like we are using pff coz i see this ruby script called
> unifont2pff in util directory. Googling about pff did not return
> anything useful. Though i did find info on unifont. I think i can
> figure out this pff thing from the code, but any help would really be
> useful.

Of course, there is no information on the web about pff. Because PFF 
stands for Pupa Font Format. It's our own format.

Okuji

Re: Issues in implementing VESA support

[Yoshinori K. Okuji]

On Sunday 16 May 2004 20:44, Marco Gerards wrote:
> I am not sure about how Okuji wants to handle copyrights, but IIRC
> for GRUB 2 those need to be assigned.

It's the same as GRUB Legacy. If you write new code for GRUB, we need an 
assignment or a disclaimer for it. Otherwise, we don't accept such 
code.

Okuji