Re: [Qemu-devel] [PATCH] Graphics: Switch to 800x600x32 as default mode

[Mark Cave-Ayland]

On 20/06/13 13:23, Alexander Graf wrote:

> On 20.06.2013, at 14:19, Peter Maydell wrote:
>
> > On 20 June 2013 13:09, Alexander Graf<address@hidden>  wrote:
> > > We have stayed at 800x600x15 as default graphics mode for the last 9 years.
> > > If there ever was a reason to be there, surely nobody remembers it.
> > >
> > > However, recently non-Linux PPC guests started to show bad effects on 15 bit
> > > color mode. They do work just fine with 32 bits however.
> >
> > Have we identified what the actual problem with these guests is?
> > 32 bit might be a more sensible default but "it masks a bug"
> > doesn't seem like a very solid justification for the change...
>
> Since Linux works just fine, I'd say it falls under the category of "QEMU diverges 
> from typical test systems".
>
> Mark, have you explored the breakages any deeper?

It seems to be that several OS images in my OpenBIOS test suite are 
expecting either an 8-bit or 32-bit display depth. For example Darwin 
and older versions of HelenOS will freeze if they don't have a 8bpp or 
32bpp display (and newer versions of HelenOS only work because they 
realised that no-one had tested 15bpp before running under QEMU and 
noticed the bug). I suspect it's because of the recent MMU fixes in 
openbios-ppc which enable it to run a lot more images than before is why 
no-one actually noticed before :)

Everything is happy on an 8bpp display except for OpenBSD (which only 
runs on 32bpp) which would favour the higher bit depth, although as I 
mentioned in my previous text, the console text seems much fainter on a 
32bpp display.

My general feeling is that since several test images expect either an 
8bpp or 32bpp display then 15bpp is not something that ever existed on 
real Mac hardware, although I don't know if this is the case or not. 
While there is some debate as to whether 8bpp or 32bpp is better, the 
current default definitely seems to be the worst choice for compatibility.


ATB,

Mark.