Timothy Miller wrote:
On 5/29/05, Alexander van Heukelum <[EMAIL PROTECTED]> wrote:
Questions? Remarks? Should I shut up?
This is all being over-blown. We want to be JUST VGA-compatible
enough to be usable AND NO MORE. VGA is LEGACY and should be done
away with. It's a thorn in our side and does nothing for anyone but
x86 users, and hopefully some day, people will find a way to get rid
of that too.
I don't disagree in the least, especially about the thorn bit...
However, as legacy as it may be, the VGA core will be "most" people's
first interaction with the chip. I say "most" since I figure it's a
safe bet that over half the individuals who purchase a card based on
this chip will be running an x86 machine. I'm not including embedded
sales in this since the success it that realm has different driving
criteria. The Windows install is currently entirely VESA VGA (I
think). Most Linux installs are either text or VESA VGA. Several people
have mentioned using linux frame buffer drivers and the fact that this
card will have great open driver support. Both are good points,
however, consider this. The Mandrake 10.1 distro I have sitting next to
me knows nothing of this card. The distros on the market when the card
finally ships will most likely know nothing of the card. There will be
a lag between the fb drivers availability in the kernel and their
inclusion in most distro installs. None of my live CDs and rescue disks
know anything of this card and I'm not going to want to go out and
rebuild them just so they will boot a usable system with this card.
If people first interaction with the card is a functional but barely
usable VGA core, we endanger the project with a very bad first
impression: "Man, they couldn't even get VGA right, the rest of the
card must be garbage too."
We need to figure out how to do the BARE MINIMUM. Also, keep in mind
that time is valuable. Sure, clever solutions are welcome, and people
are having some fun, but we need a quick-and-dirty solution. Maybe
it's quicker just to code the damn thing in verilog and skip the
nanoprocessor. I'm willing to dedicate some extra logic for the sake
of not wasting the time of the volunteers who are working on it.
Ok, so let's look at this from an engineering point of view. What are
our requirements? I posit the following:
1. Text modes
80x25
80x40
80x50
2. Graphics modes
320x200 8 bit color
320x240 8 bit color (Mode X)
320x400 8 bit color (Windows Splash)
640x480 4 bit color
640x480 8,16, 24 bit color (VESA)
800x600 8,16, 24 bit color (VESA)
1024x768 8,16,24 bit color (VESA)
Now for comments.
For graphics modes, I'd really like to drop support for the 16bpp modes,
but I don't know what the impact of this would be.
Once we support one 8bpp mode (or any other bpp count for that matter)
supporting others is not a big issue.
Timothy pointed out that there is no real need for the 9th bit in the
text mode outputs which means we can use 640 pixel modes for text. If
we don't mind having 80 pixels blank at the bottom of the screen, we
could use 640x480 for text modes, otherwise we need 640x400.
Personally, I'd opt for adding the extra 640x400 mode to make text fill
the screen, as that is what people will expect to see and it isn't
horribly expensive to add the support.
Patrick M
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
