Patchwork Graphics: Switch to 800x600x32 as default mode

login
register
mail settings
Submitter Alexander Graf
Date June 20, 2013, 12:09 p.m.
Message ID <1371730178-26025-1-git-send-email-agraf@suse.de>
Download mbox | patch
Permalink /patch/252889/
State New
Headers show

Comments

Alexander Graf - June 20, 2013, 12:09 p.m.
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.

So let's switch to 32 bit color as the default graphic mode.

Reported-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Peter Maydell - June 20, 2013, 12:19 p.m.
On 20 June 2013 13:09, Alexander Graf <agraf@suse.de> 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...

thanks
-- PMM
Alexander Graf - June 20, 2013, 12:23 p.m.
On 20.06.2013, at 14:19, Peter Maydell wrote:

> On 20 June 2013 13:09, Alexander Graf <agraf@suse.de> 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?


Alex
Mark Cave-Ayland - June 21, 2013, 4:07 p.m.
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<agraf@suse.de>  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.
Peter Maydell - June 21, 2013, 4:48 p.m.
On 21 June 2013 17:07, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:
> 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
> :)

Yeah, "guests don't run on 16 bit and they would break on 16 bit
hardware too" is a reasonable rationale. What I was trying to
establish was whether the problem was that or "QEMU's 16 bit
emulation is broken (possibly for some corner case Linux doesn't
use)". (I've seen problems with ARM 16 bit graphics before which
were actually emulation bugs in the framebuffer device model for
some use cases.)

thanks
-- PMM

Patch

diff --git a/arch_init.c b/arch_init.c
index a8b91ee..8ba3d07 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -65,7 +65,7 @@  int graphic_depth = 8;
 #else
 int graphic_width = 800;
 int graphic_height = 600;
-int graphic_depth = 15;
+int graphic_depth = 32;
 #endif