From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BV29P-000896-C6 for qemu-devel@nongnu.org; Tue, 01 Jun 2004 01:49:27 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BV29I-00084q-OX for qemu-devel@nongnu.org; Tue, 01 Jun 2004 01:49:27 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BV29I-00084n-MH for qemu-devel@nongnu.org; Tue, 01 Jun 2004 01:49:20 -0400 Received: from [81.209.184.159] (helo=dd2718.kasserver.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BV28X-0000IZ-Uc for qemu-devel@nongnu.org; Tue, 01 Jun 2004 01:48:34 -0400 Message-ID: <40BC18B6.9040300@fabianowski.de> Date: Tue, 01 Jun 2004 07:48:38 +0200 From: Bartosz Fabianowski MIME-Version: 1.0 Subject: Re: Subject: Re: [Qemu-devel] VGA BIOS source code References: <200405312200.03734.bobb@absamail.co.za> <40BB92D1.6040508@fabianowski.de> <200405312114.08329.kyle@silverbeach.net> In-Reply-To: <200405312114.08329.kyle@silverbeach.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: kyle@silverbeach.net, qemu-devel@nongnu.org > Is there a reasons for the a c b ordering? No ;) > I think you are probably a little harsh on this code. It may be far from > perfect, but it does (mostly) work. Yes, it does work. Maybe I was a bit harsh in my wording after wasting a day on it, sorry. > Getting something in place that pretends to be a known chipset and that can > act like a dumb framebuffer would probably help. That seems to be the > direction that Fabrice and Co. are going. That seems like a good idea. Though if you are pretending to be some particular chip set, you should be prepared to emulate the most weird register settings that drivers could set for that chip set. So if the goal is to reach close to 100% compatibility, I fear a substantial subset of the entire spec for the chosen subset will have to be implemented. Since my main interest is in running Windows inside QEMU, I could also envision adding another driver later, similar to what is done in VMWare. It would be a windows driver that acts as a dumb stub and forwards every request to the dumb side. Since it would be designed from the ground up only for QEMU, it could be limited in its functionality to really only being a frame buffer and nothing else. This would probably accelerate the emulation quite a bit. - Bartosz