| Message ID | 1371730178-26025-1-git-send-email-agraf@suse.de |
|---|---|
| State | New |
| Headers | show |
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
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
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.
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
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
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(-)