[Qemu-devel] [PATCH 1/3] Fix SDL problems with BGR displays

[Qemu-devel] [PATCH 1/3] Fix SDL problems with BGR displays

[Anthony Liguori]

From: Avi Kivity <avi@qumranet.com>

kvm: qemu: revert qemu's sdl.c rev 1.40

this fixes problems with bgr displays.

Signed-off-by: Avi Kivity <avi@qumranet.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

diff --git a/sdl.c b/sdl.c
index bac60ea..719e2bd 100644
--- a/sdl.c
+++ b/sdl.c
@@ -89,7 +89,7 @@ static void sdl_resize(DisplayState *ds, int w, int h)
     ds->data = screen->pixels;
     ds->linesize = screen->pitch;
     ds->depth = screen->format->BitsPerPixel;
-    if (screen->format->Bshift > screen->format->Rshift) {
+    if (ds->depth == 32 && screen->format->Rshift == 0) {
         ds->bgr = 1;
     } else {
         ds->bgr = 0;

[Qemu-devel] [PATCH 2/3] Fix task register type after reset

[Anthony Liguori]

From: Avi Kivity <avi@qumranet.com>

kvm: qemu: fix task register type after reset

Breaks reboots.

Signed-off-by: Avi Kivity <avi@qumranet.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

diff --git a/target-i386/helper.c b/target-i386/helper.c
index 852f093..7962d6b 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -403,7 +403,7 @@ void cpu_reset(CPUX86State *env)
     env->ldt.limit = 0xffff;
     env->ldt.flags = DESC_P_MASK | (2 << DESC_TYPE_SHIFT);
     env->tr.limit = 0xffff;
-    env->tr.flags = DESC_P_MASK | (11 < DESC_TYPE_SHIFT);
+    env->tr.flags = DESC_P_MASK | (11 << DESC_TYPE_SHIFT);
 
     cpu_x86_load_seg_cache(env, R_CS, 0xf000, 0xffff0000, 0xffff,
                            DESC_P_MASK | DESC_S_MASK | DESC_CS_MASK | DESC_R_MASK);

[Qemu-devel] [PATCH 3/3] Fix -daemonize option

[Anthony Liguori]

When using -daemonize, we want to avoid chdir() until after we've opened the
block devices.  It's also perfectly fine to use -dameonize along with SDL.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

diff --git a/vl.c b/vl.c
index f057a5e..d94ebb1 100644
--- a/vl.c
+++ b/vl.c
@@ -8626,11 +8626,6 @@ int main(int argc, char **argv)
     }
 
 #ifndef _WIN32
-    if (daemonize && !nographic && vnc_display == NULL) {
-	fprintf(stderr, "Can only daemonize if using -nographic or -vnc\n");
-	daemonize = 0;
-    }
-
     if (daemonize) {
 	pid_t pid;
 
@@ -8668,7 +8663,6 @@ int main(int argc, char **argv)
 	    exit(1);
 
 	umask(027);
-	chdir("/");
 
         signal(SIGTSTP, SIG_IGN);
         signal(SIGTTOU, SIG_IGN);
@@ -8974,6 +8968,7 @@ int main(int argc, char **argv)
 	if (len != 1)
 	    exit(1);
 
+	chdir("/");
 	TFR(fd = open("/dev/null", O_RDWR));
 	if (fd == -1)
 	    exit(1);

Re: [Qemu-devel] [PATCH 1/3] Fix SDL problems with BGR displays

[Andreas Färber]

Hi,

Am 22.07.2008 um 22:51 schrieb Anthony Liguori:

> From: Avi Kivity <avi@qumranet.com>
>
> kvm: qemu: revert qemu's sdl.c rev 1.40
>
> this fixes problems with bgr displays.

What problems exactly are you fixing? Could other backends such as  
Cocoa be affected, too?

> Signed-off-by: Avi Kivity <avi@qumranet.com>
> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
>
> diff --git a/sdl.c b/sdl.c
> index bac60ea..719e2bd 100644
> --- a/sdl.c
> +++ b/sdl.c
> @@ -89,7 +89,7 @@ static void sdl_resize(DisplayState *ds, int w,  
> int h)
>     ds->data = screen->pixels;
>     ds->linesize = screen->pitch;
>     ds->depth = screen->format->BitsPerPixel;
> -    if (screen->format->Bshift > screen->format->Rshift) {
> +    if (ds->depth == 32 && screen->format->Rshift == 0) {
>         ds->bgr = 1;
>     } else {
>         ds->bgr = 0;
>

Why does BGR depend on a depth of 32?

Andreas

Re: [Qemu-devel] [PATCH 1/3] Fix SDL problems with BGR displays

[Anthony Liguori]

Andreas Färber wrote:
> Hi,
>
> Am 22.07.2008 um 22:51 schrieb Anthony Liguori:
>
>> From: Avi Kivity <avi@qumranet.com>
>>
>> kvm: qemu: revert qemu's sdl.c rev 1.40
>>
>> this fixes problems with bgr displays.
>
> What problems exactly are you fixing? Could other backends such as 
> Cocoa be affected, too?

The original commit in question is 2974.  I don't have the ability to 
test Cocoa but we received a bug report about a BGR display regression 
shortly after this commit.  Reverting this particular part of the commit 
made the problem go away.  See 
http://thread.gmane.org/gmane.comp.emulators.kvm.devel/7773

Perhaps Blue Swirl can comment if reverting this part of the patch 
regresses some of the test cases he was working with when he committed 
the original patch?

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 1/3] Fix SDL problems with BGR displays

[Blue Swirl]

On 7/23/08, Anthony Liguori <aliguori@us.ibm.com> wrote:
> Andreas Färber wrote:
>
> > Hi,
> >
> > Am 22.07.2008 um 22:51 schrieb Anthony Liguori:
> >
> >
> > > From: Avi Kivity <avi@qumranet.com>
> > >
> > > kvm: qemu: revert qemu's sdl.c rev 1.40
> > >
> > > this fixes problems with bgr displays.
> > >
> >
> > What problems exactly are you fixing? Could other backends such as Cocoa
> be affected, too?
> >
>
>  The original commit in question is 2974.  I don't have the ability to test
> Cocoa but we received a bug report about a BGR display regression shortly
> after this commit.  Reverting this particular part of the commit made the
> problem go away.  See
> http://thread.gmane.org/gmane.comp.emulators.kvm.devel/7773
>
>  Perhaps Blue Swirl can comment if reverting this part of the patch
> regresses some of the test cases he was working with when he committed the
> original patch?

I can't reproduce the problem anymore, even reverting the patch
changes nothing at depth 16. There seems to be other bugs involved,
for example at depth 15 everything looks cosmic. Maybe VGA memory
accesses assume some host endianness which are wrong on big endian
host.

Re: [Qemu-devel] [PATCH 1/3] Fix SDL problems with BGR displays

[Anthony Liguori]

Blue Swirl wrote:
> On 7/23/08, Anthony Liguori <aliguori@us.ibm.com> wrote:
>   
> I can't reproduce the problem anymore, even reverting the patch
> changes nothing at depth 16. There seems to be other bugs involved,
> for example at depth 15 everything looks cosmic. Maybe VGA memory
> accesses assume some host endianness which are wrong on big endian
> host.
>   

Okay, I'll commit the partial revert since it does at least fix some 
displays.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 1/3] Fix SDL problems with BGR displays

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]

On 7/23/08, Blue Swirl <blauwirbel@gmail.com> wrote:
> On 7/23/08, Anthony Liguori <aliguori@us.ibm.com> wrote:
>  > Andreas Färber wrote:
>  >
>  > > Hi,
>  > >
>  > > Am 22.07.2008 um 22:51 schrieb Anthony Liguori:
>  > >
>  > >
>  > > > From: Avi Kivity <avi@qumranet.com>
>  > > >
>  > > > kvm: qemu: revert qemu's sdl.c rev 1.40
>  > > >
>  > > > this fixes problems with bgr displays.
>  > > >
>  > >
>  > > What problems exactly are you fixing? Could other backends such as Cocoa
>  > be affected, too?
>  > >
>  >
>  >  The original commit in question is 2974.  I don't have the ability to test
>  > Cocoa but we received a bug report about a BGR display regression shortly
>  > after this commit.  Reverting this particular part of the commit made the
>  > problem go away.  See
>  > http://thread.gmane.org/gmane.comp.emulators.kvm.devel/7773
>  >
>  >  Perhaps Blue Swirl can comment if reverting this part of the patch
>  > regresses some of the test cases he was working with when he committed the
>  > original patch?
>
>
> I can't reproduce the problem anymore, even reverting the patch
>  changes nothing at depth 16. There seems to be other bugs involved,
>  for example at depth 15 everything looks cosmic. Maybe VGA memory
>  accesses assume some host endianness which are wrong on big endian
>  host.
>

This patch gets 15 bit display working for me. SDL BitsPerPixel never
indicates any values other than multiples of 8, so we need to check
for strange depths. Any comments?

[-- Attachment #2: sdl_fix_15bits.diff --]
[-- Type: plain/text, Size: 665 bytes --]

Re: [Qemu-devel] [PATCH 1/3] Fix SDL problems with BGR displays

[Anthony Liguori]

Blue Swirl wrote:
> This patch gets 15 bit display working for me. SDL BitsPerPixel never
> indicates any values other than multiples of 8, so we need to check
> for strange depths. Any comments?
>   

It looks sane to me.

Regards,

Anthony Liguori