qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Gives user ability to select endian format for video di


From: Programmingkid
Subject: Re: [Qemu-devel] Gives user ability to select endian format for video display - fixes Mac OS X guest color issue.
Date: Thu, 8 Jan 2015 12:07:52 -0500

On Jan 8, 2015, at 4:02 AM, Gerd Hoffmann wrote:

>  Hi,
> 
>> VGA: Using shared surface for depth=32 swap=1
> 
> Ok, 32bpp.  byteswapping needed.
> 
> I guess the host is a intel macintosh then?

Yes. I unfortunately don't have a fast enough PowerPC Mac to handle QEMU. It 
would be interesting to find out if this color issue is on PowerPC hosts. 

> 
> Having a quick look at the cocoa code it seems it doesn't look at the
> color masks and shifts, only the color depth.  So having the UI handle
> the byteswapping that way isn't going to fly.
> 
> Try setting force_shadow (vga.c, needs git master) to one.  That way
> vga.c will byteswap and not expect the UI to do it.  Alternatively make
> cocoa UI properly handle the color masks and shifts, so non-native
> ordering works.

Is this what you mean?
 s->force_shadow = 1;
    share_surface = (!s->force_shadow) &&
            ( depth == 32 || (depth == 16 && !byteswap) );

I tried it out and didn't notice any change in colors for the Mac OS X guest. 


I do have an idea. What if on cocoa_update(DisplayChangeListener ...), we find 
out the format of the framebuffer. 

The DisplayChangeListener object has a QemuConsole object. The QemuConsole 
object has a DisplaySurface object. The DisplaySurface object has a 
pixman_format_code_t format variable. This format variable tells us what format 
the framebuffer is in. So is it possible to use it? The format types are listed 
in pixman.h.

If it reports the correct format like BGR, then it would be possible to 
automatically adjust the UI to display the correct colors. I am currently 
attempting this, but accessing the format variable is not as easy as I thought 
it would be. I think the code will look something like this: 
dcl->con->surface->format. 


> I have some patches from benh in the pipeline allowing to negotiate
> supported formats for shared buffers, with that in place hard-coded
> assumptions about what formats the UI code is able to handle will go
> away.  Guess I should rank them up in my priority list ;)

Sounds interesting. 

> 
> cheers,
>  Gerd

Thanks. 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]