From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <09544819dcab84e23d48f6bd0eed24ec@plan9.bell-labs.com>
To: 9fans@9fans.net
Date: Wed, 27 Jan 2010 12:36:34 -0500
From: geoff@plan9.bell-labs.com
In-Reply-To: <20100127135832.GA32067@endeavour>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] vgaradeon (was Re:  Problem of last update?)
Topicbox-Message-UUID: c8a5679c-ead5-11e9-9d60-3106f5b1d025

Remember that, on the pc, you should always be able to revert to
monitor=vesa and indeed aux/vga attempts that if it can't recognise
your graphics controller, but it can fail if you're trying to use a
non-vesa resolution.  It even works on multiprocessors now.

	aux/vga -m vesa -p >/tmp/vesa

will generate a list of acceptable vesa modes, including resolutions,
in /tmp/vesa.  The redirection is necessary to avoid interacting with
the vga subsystem while dumping it.

My long-term goal is to eliminate all the vga drivers but vgavesa,
which make up about 10% of the pc kernel port by line count.  This may
not be possible due to currently-working graphics cards with broken
vesa bioses nor desirable because the native drivers are vastly faster
than the vesa driver (though I think we're closing that gap), but it's
worth attempting.  I've used the vesa driver on my usual plan 9
terminals and it's hard to see a difference in performance compared
with the native vga drivers.