From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LCz9p-0002xp-Mj for qemu-devel@nongnu.org; Wed, 17 Dec 2008 11:21:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LCz9o-0002xX-Al for qemu-devel@nongnu.org; Wed, 17 Dec 2008 11:21:57 -0500 Received: from [199.232.76.173] (port=41245 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LCz9o-0002xN-5T for qemu-devel@nongnu.org; Wed, 17 Dec 2008 11:21:56 -0500 Received: from mail.gmx.net ([213.165.64.20]:49057) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1LCz9n-0007yf-3J for qemu-devel@nongnu.org; Wed, 17 Dec 2008 11:21:55 -0500 Message-ID: <4949271B.7030105@gmx.net> Date: Wed, 17 Dec 2008 17:21:47 +0100 From: Carl-Daniel Hailfinger MIME-Version: 1.0 Subject: Re: [Bochs-developers] [Qemu-devel] [PATCH 0/3] Add BIOS splash image support References: <1229440810-12394-1-git-send-email-Laurent.Vivier@bull.net> <49480F6D.2010302@codemonkey.ws> <1229464268.26715.12.camel@frecb07144> <4948435D.1090204@gmx.net> <1229519355.4116.6.camel@frecb07144> In-Reply-To: <1229519355.4116.6.camel@frecb07144> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent Vivier Cc: bochs developers , qemu-devel@nongnu.org, kvm developers On 17.12.2008 14:09, Laurent Vivier wrote: > Le mercredi 17 décembre 2008 à 01:10 +0100, Carl-Daniel Hailfinger a > écrit : > >> On 16.12.2008 22:51, Laurent Vivier wrote: >> >>> Le mardi 16 décembre 2008 à 22:46 +0200, Blue Swirl a écrit : >>> >>> >>>> On 12/16/08, Anthony Liguori wrote: >>>> >>>> >>>>> Blue Swirl wrote: >>>>> >>>>> >>> >>> >>>>>> The control channel may still be needed. >>>>>> >>>>>> Alternatively the BIOS could load the image and fade parameters from a >>>>>> new ROM or from the configuration device and draw it to screen. This >>>>>> would need some PNG support to BIOS, or that the image stored in raw >>>>>> form. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Yeah, having QEMU render to the VGA directly is a bit ugly. It would be >>>>> nicer if the BIOS actually rendered the image but I'm not sure I think we >>>>> should reject the patch just because it doesn't. >>>>> >>>>> >>>> Actually this way the image can be in full color even if the emulated >>>> device was an EGA in text mode. >>>> >>>> >>> And you can provide the image name on the command line, and complexity >>> is in Qemu, not in BIOS. >>> >>> >> If one of the goals of QEMU is to be somewhat similar to hardware, this >> should be done in the BIOS. >> > > A lot of things in Qemu are already not similar to hardware: virtio, > firmware configuration device, instruction timing... > > >> What happens if the BIOS provides a splash screen? Will it override the >> QEMU splash screen? >> > > Yes. The BIOS asks Qemu to display the image... or not. > What happens if you run a native BIOS/EFI/whatever for the hardware emulated in QEMU? Some people try to do exactly that. >>> But in fact, my first idea was to read the image data from the >>> configuration device (which is always possible with LOGO_CMD_OFFSET), >>> but when I saw how it has been done in VirtualBox, I though it was a >>> good idea. >>> >>> >> Modern x86 BIOSes read the splash screen from the BIOS ROM and the >> settings from NVRAM (sometimes the BIOS ROM is used for that as well by >> reflashing a sector of the ROM on every boot). >> > > A BIOS, by definition, is not modern... ;-) > Agreed. > (Openfirmware is...) > Even EFI is more modern than OpenFirmware. However, the most important question here is how you quantify modernness ;-) Speaking as a coreboot (really modern x86 firmware) developer, I'd like to keep the number of workarounds for QEMU hardware quirks to a minimum. Regards, Carl-Daniel -- http://www.hailfinger.org/