reguest for comments regarding an imac_fb and efifb unification

reguest for comments regarding an imac_fb and efifb unification

[Scott D. Davilla]

I've involved in development that involves a non-standard efi 
bootloader and both imac_fb and efifb console framebuffers and it 
seem redundant to have two console framebuffers that perform the same 
function. efi_fb is actually a simplification of imac_fb.

Both imac_fb and efifb are actually very simple in operation, they 
both assume a linear video frame buffer with fixed x,y dimensions.

In actual usage;

	imac_fb is used in two ways, 1) setup using command-line 
params or DMI info for traditional Apple desktops and 2) setup using 
command-line params that are created by mach_boot_linux, the AppleTV 
bootloader.

	efifb is always setup by using screen_info that the 
bootloader configures.

	Nether actually depends on EFI but rather neither can depend 
on  video/pc bios, these might/might not hang/crash the hardware.

So it seems that by adding command-line param setup to efifb and some 
DMI checks, imac_fb can be merged into efifb. efifb is really a 
strange name as it has no interaction with EFI, it just happens to 
get used under an EFI environment. It's really just a non-accelerated 
linear video frame buffer configured by screen_info boot params so it 
could be used by any hardware that has a linear framebuffer 
organization.

Which brings up the point, is there another more general console 
frame buffer that could replace both imac_fb and efifb? It seems that 
a generic console framebuffer that assumes a linear video framebuffer 
that does not make video bios calls (nor PC bios) and can be 
configured by screen_info params or command-line params would be 
something that already exists? Is there such a console frame buffer?

I'm willing to pursue this but I want to check the general consensus 
about such a venture and possible ramifications that I might not have 
considered.

Thanks
Scott

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: reguest for comments regarding an imac_fb and efifb unification

[Geert Uytterhoeven]

On Thu, 6 Mar 2008, Scott D. Davilla wrote:
> I've involved in development that involves a non-standard efi 
> bootloader and both imac_fb and efifb console framebuffers and it 
> seem redundant to have two console framebuffers that perform the same 
> function. efi_fb is actually a simplification of imac_fb.
> 
> Both imac_fb and efifb are actually very simple in operation, they 
> both assume a linear video frame buffer with fixed x,y dimensions.
> 
> In actual usage;
> 
> 	imac_fb is used in two ways, 1) setup using command-line 
> params or DMI info for traditional Apple desktops and 2) setup using 
> command-line params that are created by mach_boot_linux, the AppleTV 
> bootloader.
> 
> 	efifb is always setup by using screen_info that the 
> bootloader configures.
> 
> 	Nether actually depends on EFI but rather neither can depend 
> on  video/pc bios, these might/might not hang/crash the hardware.
> 
> So it seems that by adding command-line param setup to efifb and some 
> DMI checks, imac_fb can be merged into efifb. efifb is really a 
> strange name as it has no interaction with EFI, it just happens to 
> get used under an EFI environment. It's really just a non-accelerated 
> linear video frame buffer configured by screen_info boot params so it 
> could be used by any hardware that has a linear framebuffer 
> organization.
> 
> Which brings up the point, is there another more general console 
> frame buffer that could replace both imac_fb and efifb? It seems that 
> a generic console framebuffer that assumes a linear video framebuffer 
> that does not make video bios calls (nor PC bios) and can be 
> configured by screen_info params or command-line params would be 
> something that already exists? Is there such a console frame buffer?
> 
> I'm willing to pursue this but I want to check the general consensus 
> about such a venture and possible ramifications that I might not have 
> considered.

There exist a few more drivers for simple linear video frame buffer
devices with fixed x,y dimensions:
  - offb, for Open Firmware based machines,
  - vesafb, for VBE 2.0 compliant graphic boards.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: reguest for comments regarding an imac_fb and efifb unification

[Scott D. Davilla]

>  > Which brings up the point, is there another more general console
>>  frame buffer that could replace both imac_fb and efifb? It seems that
>>  a generic console framebuffer that assumes a linear video framebuffer
>>  that does not make video bios calls (nor PC bios) and can be
>>  configured by screen_info params or command-line params would be
>>  something that already exists? Is there such a console frame buffer?
>>
>>  I'm willing to pursue this but I want to check the general consensus
>>  about such a venture and possible ramifications that I might not have
>>  considered.
>
>There exist a few more drivers for simple linear video frame buffer
>devices with fixed x,y dimensions:
>   - offb, for Open Firmware based machines,
>   - vesafb, for VBE 2.0 compliant graphic boards.

vesafb would be nice but there is an implied VBE 2.0 compliance which 
includes video bios. I'll force my bootloader to vesafb and see how 
far it gets.

Speaking of VGA, orig_video_isVGA is nicely defined in 
include/linux/screen_info.h along with different values 
(VIDEO_TYPE_MDA to VIDEO_TYPE_EFI) but I've seen other usages where 
orig_video_isVGA is set to zero or one.

This usage is not define in screen_info.h? drivers/char/vga.c uses a 
zero to imply VIDEO_TYPE_EGAC otherwise some type of vga. kexec 
(userland) uses it to imply undefined vga.

As far as I can tell there is no real definition of orig_video_isVGA 
= 0 or orig_video_isVGA = 1 in the code. I crash and burn if 
orig_video_isVGA = 1. What's the story on this?

Scott


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: reguest for comments regarding an imac_fb and efifb unification

[Michal Suchanek]

On 06/03/2008, Scott D. Davilla <davilla@4pi.com> wrote:
> >  > Which brings up the point, is there another more general console
>  >>  frame buffer that could replace both imac_fb and efifb? It seems that
>  >>  a generic console framebuffer that assumes a linear video framebuffer
>  >>  that does not make video bios calls (nor PC bios) and can be
>  >>  configured by screen_info params or command-line params would be
>  >>  something that already exists? Is there such a console frame buffer?
>  >>
>  >>  I'm willing to pursue this but I want to check the general consensus
>  >>  about such a venture and possible ramifications that I might not have
>  >>  considered.
>  >
>  >There exist a few more drivers for simple linear video frame buffer
>  >devices with fixed x,y dimensions:
>  >   - offb, for Open Firmware based machines,
>  >   - vesafb, for VBE 2.0 compliant graphic boards.
>
>
> vesafb would be nice but there is an implied VBE 2.0 compliance which
>  includes video bios. I'll force my bootloader to vesafb and see how
>  far it gets.
>

Perhaps you want something like linfb which would act as backend for
various fb (auto)configuration methods. efifb through parameters
passed by efi bootloader on the commandline, imacfb by reading the mac
bios, offb by reading the ofw, vesafb by reading the vesa bios, etc.

However, I am not familiar with the kernel fb, all I can say is I
could probably test offb and imacfb if you did the merge.

iirc the offb was special in that one could load another fb over it
even before fb switching was possible (or was it ofconsole?)

Another speciality is vesafb_tng or whatever it's called which is
supposed to be able to change the resolution even after boot.

Thanks

Michal

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/