From: "Scott D. Davilla" <davilla@4pi.com>
To: Linux Frame Buffer Device Development
<linux-fbdev-devel@lists.sourceforge.net>
Subject: reguest for comments regarding an imac_fb and efifb unification
Date: Thu, 6 Mar 2008 14:05:17 -0500 [thread overview]
Message-ID: <p0623091ac3f5e718e844@[192.168.9.5]> (raw)
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/
next reply other threads:[~2008-03-06 19:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-06 19:05 Scott D. Davilla [this message]
2008-03-06 19:39 ` reguest for comments regarding an imac_fb and efifb unification Geert Uytterhoeven
2008-03-06 20:37 ` Scott D. Davilla
[not found] ` <p0623091cc3f5f9111ec0@192.168.9.5>
2008-03-07 7:49 ` Michal Suchanek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='p0623091ac3f5e718e844@[192.168.9.5]' \
--to=davilla@4pi.com \
--cc=linux-fbdev-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).