[Qemu-devel] [PATCH 1/6] kvm: qemu: fix screendump with multiple consoles

[Qemu-devel] [PATCH 1/6] kvm: qemu: fix screendump with multiple consoles

[Anthony Liguori]

From: Avi Kivity <avi@qumranet.com>

pretend to be the active console while a screendump takes place.

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

diff --git a/console.c b/console.c
index a1bc769..061135f 100644
--- a/console.c
+++ b/console.c
@@ -167,10 +167,15 @@ void vga_hw_invalidate(void)
 
 void vga_hw_screen_dump(const char *filename)
 {
+    TextConsole *previous_active_console;
+
+    previous_active_console = active_console;
+    active_console = consoles[0];
     /* There is currently no was of specifying which screen we want to dump,
        so always dump the dirst one.  */
     if (consoles[0]->hw_screen_dump)
         consoles[0]->hw_screen_dump(consoles[0]->hw, filename);
+    active_console = previous_active_console;
 }
 
 void vga_hw_text_update(console_ch_t *chardata)

[Qemu-devel] [PATCH 2/6] kvm: qemu: force screen resize if a display buffer does not exist

[Anthony Liguori]

From: Avi Kivity <avi@qumranet.com>

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

diff --git a/console.c b/console.c
index 061135f..055a3f1 100644
--- a/console.c
+++ b/console.c
@@ -1334,7 +1334,8 @@ CharDriverState *text_console_init(DisplayState *ds, const char *p)
 
 void qemu_console_resize(QEMUConsole *console, int width, int height)
 {
-    if (console->g_width != width || console->g_height != height) {
+    if (console->g_width != width || console->g_height != height
+        || !console->ds->data) {
         console->g_width = width;
         console->g_height = height;
         if (active_console == console) {

[Qemu-devel] [PATCH 3/6] kvm: qemu: revert "fix power management timer overflow handling"

[Anthony Liguori]

From: Avi Kivity <avi@qumranet.com>

The fix is bogus, causing sci to be deferred for longer and longer.

Noticed by Alex Williamson.

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

diff --git a/hw/acpi.c b/hw/acpi.c
index c305702..e3cd8d7 100644
--- a/hw/acpi.c
+++ b/hw/acpi.c
@@ -109,7 +109,6 @@ static void pm_update_sci(PIIX4PMState *s)
     if ((s->pmen & TMROF_EN) && !(pmsts & TMROF_EN)) {
         expire_time = muldiv64(s->tmr_overflow_time, ticks_per_sec, PM_FREQ);
         qemu_mod_timer(s->tmr_timer, expire_time);
-        s->tmr_overflow_time += 0x800000;
     } else {
         qemu_del_timer(s->tmr_timer);
     }

[Qemu-devel] [PATCH 4/6] kvm: qemu: revert ""QEMU keyboard issue with Gujin-2.2", by Etienne Lorrain."

[Anthony Liguori]

From: Avi Kivity <avi@qumranet.com>

This reverts commit 450f6dc8f7bdb183d64d81b4eef89049ea9e9259, which kills the
mouse in SuSE Linux 9.1.

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

diff --git a/hw/pckbd.c b/hw/pckbd.c
index 266c7f9..46d9b9d 100644
--- a/hw/pckbd.c
+++ b/hw/pckbd.c
@@ -211,7 +211,7 @@ static void kbd_write_command(void *opaque, uint32_t addr, uint32_t val)
 #endif
     switch(val) {
     case KBD_CCMD_READ_MODE:
-        kbd_queue(s, s->mode, 1);
+        kbd_queue(s, s->mode, 0);
         break;
     case KBD_CCMD_WRITE_MODE:
     case KBD_CCMD_WRITE_OBUF:

Re: [Qemu-devel] [PATCH 4/6] kvm: qemu: revert ""QEMU keyboard issue with Gujin-2.2", by Etienne Lorrain."

[Even Rouault]

This revert should also fix the issue with the PS/2 mouse in FC4 I've 
previously raised in that thread : 
http://lists.gnu.org/archive/html/qemu-devel/2008-01/msg00548.html

Le Thursday 17 July 2008 23:19:38 Anthony Liguori, vous avez écrit :
> From: Avi Kivity <avi@qumranet.com>
>
> This reverts commit 450f6dc8f7bdb183d64d81b4eef89049ea9e9259, which kills
> the mouse in SuSE Linux 9.1.
>
> Signed-off-by: Avi Kivity <avi@qumranet.com>
> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
>
> diff --git a/hw/pckbd.c b/hw/pckbd.c
> index 266c7f9..46d9b9d 100644
> --- a/hw/pckbd.c
> +++ b/hw/pckbd.c
> @@ -211,7 +211,7 @@ static void kbd_write_command(void *opaque, uint32_t
> addr, uint32_t val) #endif
>      switch(val) {
>      case KBD_CCMD_READ_MODE:
> -        kbd_queue(s, s->mode, 1);
> +        kbd_queue(s, s->mode, 0);
>          break;
>      case KBD_CCMD_WRITE_MODE:
>      case KBD_CCMD_WRITE_OBUF:

[Qemu-devel] Re: [PATCH 4/6] kvm: qemu: revert ""QEMU keyboard issue with Gujin-2.2", by Etienne Lorrain."

[Jan Kiszka]

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

Anthony Liguori wrote:
> From: Avi Kivity <avi@qumranet.com>
> 
> This reverts commit 450f6dc8f7bdb183d64d81b4eef89049ea9e9259, which kills the

I know that kvm manages qemu in a git tree, but I guess for people here
it is more handy to offer svn revision numbers instead (here: #3421).

> mouse in SuSE Linux 9.1.
> 
> Signed-off-by: Avi Kivity <avi@qumranet.com>
> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
> 
> diff --git a/hw/pckbd.c b/hw/pckbd.c
> index 266c7f9..46d9b9d 100644
> --- a/hw/pckbd.c
> +++ b/hw/pckbd.c
> @@ -211,7 +211,7 @@ static void kbd_write_command(void *opaque, uint32_t addr, uint32_t val)
>  #endif
>      switch(val) {
>      case KBD_CCMD_READ_MODE:
> -        kbd_queue(s, s->mode, 1);
> +        kbd_queue(s, s->mode, 0);
>          break;
>      case KBD_CCMD_WRITE_MODE:
>      case KBD_CCMD_WRITE_OBUF:
> 
> 
> 

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] Re: [PATCH 4/6] kvm: qemu: revert ""QEMU keyboard issue with Gujin-2.2", by Etienne Lorrain."

[Anthony Liguori]

Jan Kiszka wrote:
> Anthony Liguori wrote:
>   
>> From: Avi Kivity <avi@qumranet.com>
>>
>> This reverts commit 450f6dc8f7bdb183d64d81b4eef89049ea9e9259, which kills the
>>     
>
> I know that kvm manages qemu in a git tree, but I guess for people here
> it is more handy to offer svn revision numbers instead (here: #3421).
>   

Indeed, sorry, for these patches, I've been taking the commit messages 
directly from the git tree.

I'll try to fix-up manually in the future.

Regards,

Anthony Liguori

>> mouse in SuSE Linux 9.1.
>>
>> Signed-off-by: Avi Kivity <avi@qumranet.com>
>> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
>>
>> diff --git a/hw/pckbd.c b/hw/pckbd.c
>> index 266c7f9..46d9b9d 100644
>> --- a/hw/pckbd.c
>> +++ b/hw/pckbd.c
>> @@ -211,7 +211,7 @@ static void kbd_write_command(void *opaque, uint32_t addr, uint32_t val)
>>  #endif
>>      switch(val) {
>>      case KBD_CCMD_READ_MODE:
>> -        kbd_queue(s, s->mode, 1);
>> +        kbd_queue(s, s->mode, 0);
>>          break;
>>      case KBD_CCMD_WRITE_MODE:
>>      case KBD_CCMD_WRITE_OBUF:
>>
>>
>>
>>     
>
> Jan
>
>   

[Qemu-devel] [PATCH 5/6] kvm: qemu: improve scsi dma speed by increasing the dma buffer size

[Anthony Liguori]

From: Avi Kivity <avi@qumranet.com>

taken from Xen 17267:f4a92f0db20f, original patch by Samuel Thibault.

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

diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 44462d4..fc7fbe0 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -34,7 +34,7 @@ do { fprintf(stderr, "scsi-disk: " fmt , ##args); } while (0)
 #define SENSE_HARDWARE_ERROR  4
 #define SENSE_ILLEGAL_REQUEST 5
 
-#define SCSI_DMA_BUF_SIZE    65536
+#define SCSI_DMA_BUF_SIZE    131072
 
 typedef struct SCSIRequest {
     SCSIDeviceState *dev;

Re: [Qemu-devel] [PATCH 5/6] kvm: qemu: improve scsi dma speed by increasing the dma buffer size

[Anthony Liguori]

Sorry Paul, I should have CC'd you here.  Do you see any immediate 
problem doing this?  Didn't see any comments when from you when it was 
originally posted.

Regards,

Anthony Liguori

Anthony Liguori wrote:
> From: Avi Kivity <avi@qumranet.com>
>
> taken from Xen 17267:f4a92f0db20f, original patch by Samuel Thibault.
>
> Signed-off-by: Avi Kivity <avi@qumranet.com>
> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
>
> diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
> index 44462d4..fc7fbe0 100644
> --- a/hw/scsi-disk.c
> +++ b/hw/scsi-disk.c
> @@ -34,7 +34,7 @@ do { fprintf(stderr, "scsi-disk: " fmt , ##args); } while (0)
>  #define SENSE_HARDWARE_ERROR  4
>  #define SENSE_ILLEGAL_REQUEST 5
>  
> -#define SCSI_DMA_BUF_SIZE    65536
> +#define SCSI_DMA_BUF_SIZE    131072
>  
>  typedef struct SCSIRequest {
>      SCSIDeviceState *dev;
>
>
>   

[Qemu-devel] [PATCH 6/6] kvm: qemu: fix vga screendump

[Anthony Liguori]

From: Avi Kivity <avi@qumranet.com>

Commit 737d2050 ("Implement resolution switching in common console code")
uses qemu_console_resize() instead of dpy_resize().  This means console->ds
is examined instead of the VGA private ds, and the resize does not take place,
leading to a segfault.

Fix by modifying the DisplayState directly rather than swapping the pointer.

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

diff --git a/hw/vga.c b/hw/vga.c
index a059e32..95d6033 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -2516,11 +2516,11 @@ int ppm_save(const char *filename, uint8_t *data,
 static void vga_screen_dump(void *opaque, const char *filename)
 {
     VGAState *s = (VGAState *)opaque;
-    DisplayState *saved_ds, ds1, *ds = &ds1;
+    DisplayState saved_ds, *ds = s->ds;
 
     /* XXX: this is a little hackish */
     vga_invalidate_display(s);
-    saved_ds = s->ds;
+    saved_ds = *s->ds;
 
     memset(ds, 0, sizeof(DisplayState));
     ds->dpy_update = vga_save_dpy_update;
@@ -2528,7 +2528,6 @@ static void vga_screen_dump(void *opaque, const char *filename)
     ds->dpy_refresh = vga_save_dpy_refresh;
     ds->depth = 32;
 
-    s->ds = ds;
     s->graphic_mode = -1;
     vga_update_display(s);
 
@@ -2537,5 +2536,5 @@ static void vga_screen_dump(void *opaque, const char *filename)
                  s->ds->linesize);
         qemu_free(ds->data);
     }
-    s->ds = saved_ds;
+    *s->ds = saved_ds;
 }

Re: [Qemu-devel] [PATCH 6/6] kvm: qemu: fix vga screendump

[andrzej zaborowski]

2008/7/17 Anthony Liguori <aliguori@us.ibm.com>:
> From: Avi Kivity <avi@qumranet.com>
> Commit 737d2050 ("Implement resolution switching in common console code")
> uses qemu_console_resize() instead of dpy_resize().  This means console->ds
> is examined instead of the VGA private ds, and the resize does not take place,
> leading to a segfault.
>
> Fix by modifying the DisplayState directly rather than swapping the pointer.

The screen dumping is hacky but maybe it's a good idea to keep the
hacks local to hw/vga.c, with something like the following diff.  I
think we need to fix the screen dumping globally (some graphic cards
will need fixing too).

diff --git a/console.c b/console.c
index 1c94980..bc0c349 100644
--- a/console.c
+++ b/console.c
@@ -1334,8 +1334,7 @@ CharDriverState *text_console_init(DisplayState
*ds, const char *p)

 void qemu_console_resize(QEMUConsole *console, int width, int height)
 {
-    if (console->g_width != width || console->g_height != height
-        || !console->ds->data) {
+    if (console->g_width != width || console->g_height != height) {
         console->g_width = width;
         console->g_height = height;
         if (active_console == console) {
diff --git a/hw/vga.c b/hw/vga.c
index 5a3203c..5c66209 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -2228,8 +2228,6 @@ int pci_vga_init(PCIBus *bus, DisplayState *ds,
uint8_t *vga_ram_base,
 /********************************************************/
 /* vga screen dump */

-static int vga_save_w, vga_save_h;
-
 static void vga_save_dpy_update(DisplayState *s,
                                 int x, int y, int w, int h)
 {
@@ -2237,10 +2235,14 @@ static void vga_save_dpy_update(DisplayState *s,

 static void vga_save_dpy_resize(DisplayState *s, int w, int h)
 {
+}
+
+static void vga_save_dpy_alloc(DisplayState *s, int w, int h)
+{
     s->linesize = w * 4;
     s->data = qemu_malloc(h * s->linesize);
-    vga_save_w = w;
-    vga_save_h = h;
+    s->width = w;
+    s->height = h;
 }

 static void vga_save_dpy_refresh(DisplayState *s)
@@ -2281,26 +2283,27 @@ int ppm_save(const char *filename, uint8_t *data,
 static void vga_screen_dump(void *opaque, const char *filename)
 {
     VGAState *s = (VGAState *)opaque;
-    DisplayState *saved_ds, ds1, *ds = &ds1;
+    DisplayState saved_ds, *ds = s->ds;

     /* XXX: this is a little hackish */
-    vga_invalidate_display(s);
-    saved_ds = s->ds;
+    saved_ds = *s->ds;

     memset(ds, 0, sizeof(DisplayState));
     ds->dpy_update = vga_save_dpy_update;
     ds->dpy_resize = vga_save_dpy_resize;
     ds->dpy_refresh = vga_save_dpy_refresh;
     ds->depth = 32;
+    qemu_console_resize(s->console, -1, -1);

-    s->ds = ds;
     s->graphic_mode = -1;
+    ds->dpy_resize = vga_save_dpy_alloc;
+    vga_invalidate_display(s);
     vga_update_display(s);

     if (ds->data) {
-        ppm_save(filename, ds->data, vga_save_w, vga_save_h,
-                 s->ds->linesize);
+        ppm_save(filename, ds->data, ds->width, ds->height, ds->linesize);
+
         qemu_free(ds->data);
     }
-    s->ds = saved_ds;
+    *s->ds = saved_ds;
 }

Re: [Qemu-devel] [PATCH 6/6] kvm: qemu: fix vga screendump

[Anthony Liguori]

andrzej zaborowski wrote:
> 2008/7/17 Anthony Liguori <aliguori@us.ibm.com>:
>   
>> From: Avi Kivity <avi@qumranet.com>
>> Commit 737d2050 ("Implement resolution switching in common console code")
>> uses qemu_console_resize() instead of dpy_resize().  This means console->ds
>> is examined instead of the VGA private ds, and the resize does not take place,
>> leading to a segfault.
>>
>> Fix by modifying the DisplayState directly rather than swapping the pointer.
>>     
>
> The screen dumping is hacky but maybe it's a good idea to keep the
> hacks local to hw/vga.c, with something like the following diff.  I
> think we need to fix the screen dumping globally (some graphic cards
> will need fixing too).
>   

I agree the screen dumping is pretty hacky right now.  Instead of 
installing a new DisplayState, I've never understood why we can't just 
dump ds->data after an appropriate translation.

I think your patch looks better, but I can also code up a new screen 
dumping mechanism that doesn't take over DisplayState unless I'm missing 
something obvious.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 6/6] kvm: qemu: fix vga screendump

[andrzej zaborowski]

2008/7/20 Anthony Liguori <anthony@codemonkey.ws>:
> andrzej zaborowski wrote:
>>
>> 2008/7/17 Anthony Liguori <aliguori@us.ibm.com>:
>>
>>>
>>> From: Avi Kivity <avi@qumranet.com>
>>> Commit 737d2050 ("Implement resolution switching in common console code")
>>> uses qemu_console_resize() instead of dpy_resize().  This means
>>> console->ds
>>> is examined instead of the VGA private ds, and the resize does not take
>>> place,
>>> leading to a segfault.
>>>
>>> Fix by modifying the DisplayState directly rather than swapping the
>>> pointer.
>>>
>>
>> The screen dumping is hacky but maybe it's a good idea to keep the
>> hacks local to hw/vga.c, with something like the following diff.  I
>> think we need to fix the screen dumping globally (some graphic cards
>> will need fixing too).
>>
>
> I agree the screen dumping is pretty hacky right now.  Instead of installing
> a new DisplayState, I've never understood why we can't just dump ds->data
> after an appropriate translation.

With -no-graphic there's no ds->data, or it can have lower bpp than
what's otherwise available.

>
> I think your patch looks better, but I can also code up a new screen dumping
> mechanism that doesn't take over DisplayState unless I'm missing something
> obvious.

It's worth a try, dumping ds->data is perhaps the way to go but
ds->depth is being set to 32bit and various video cards are optimised
on the assumption that ds->depth doesn't change, so maybe there should
be a notification callback.

Regards

Re: [Qemu-devel] [PATCH 6/6] kvm: qemu: fix vga screendump

[Anthony Liguori]

andrzej zaborowski wrote:
> 2008/7/20 Anthony Liguori <anthony@codemonkey.ws>:
>   
> With -no-graphic there's no ds->data, or it can have lower bpp than
> what's otherwise available.
>   

Screen dumping with -no-graphic probably should just show a black screen 
anyway.

I don't think a lower depth is really that big of a deal.  It's what the 
user would be seeing anyway.  The simplicity seems really nice to me.

>> I think your patch looks better, but I can also code up a new screen dumping
>> mechanism that doesn't take over DisplayState unless I'm missing something
>> obvious.
>>     
>
> It's worth a try, dumping ds->data is perhaps the way to go but
> ds->depth is being set to 32bit and various video cards are optimised
> on the assumption that ds->depth doesn't change, so maybe there should
> be a notification callback.
>   

Yeah, that's a bug BTW and AFAIK it's only a problem with VMware VGA.  
There's nothing that keeps ds->depth from changing after a screen resize 
with SDL.  If a VNC client does SetPixelFormat that will also change 
ds->depth.  Right now, some VNC clients + VMware VGA will cause a SEGV 
because of the assumptions that ds->depth doesn't change.

Regards,

Anthony Liguori

> Regards
>
>
>   

Re: [Qemu-devel] [PATCH 6/6] kvm: qemu: fix vga screendump

[andrzej zaborowski]

2008/7/20 Anthony Liguori <anthony@codemonkey.ws>:
> andrzej zaborowski wrote:
>>
>> 2008/7/20 Anthony Liguori <anthony@codemonkey.ws>:
>>  With -no-graphic there's no ds->data, or it can have lower bpp than
>> what's otherwise available.
>>
>
> Screen dumping with -no-graphic probably should just show a black screen
> anyway.

I thought this was the main use case. You shouldn't need sdl installed
to perform the tests Avi talked about.

>
> I don't think a lower depth is really that big of a deal.  It's what the
> user would be seeing anyway.  The simplicity seems really nice to me.
>
>>> I think your patch looks better, but I can also code up a new screen
>>> dumping
>>> mechanism that doesn't take over DisplayState unless I'm missing
>>> something
>>> obvious.
>>>
>>
>> It's worth a try, dumping ds->data is perhaps the way to go but
>> ds->depth is being set to 32bit and various video cards are optimised
>> on the assumption that ds->depth doesn't change, so maybe there should
>> be a notification callback.
>>
>
> Yeah, that's a bug BTW and AFAIK it's only a problem with VMware VGA.

AFAIK also at least three other adapters.

>  There's nothing that keeps ds->depth from changing after a screen resize
> with SDL.  If a VNC client does SetPixelFormat that will also change
> ds->depth.  Right now, some VNC clients + VMware VGA will cause a SEGV
> because of the assumptions that ds->depth doesn't change.
>
> Regards,
>
> Anthony Liguori
>
>> Regards
>>
>>
>>
>
>
>
>

Re: [Qemu-devel] [PATCH 6/6] kvm: qemu: fix vga screendump

[Anthony Liguori]

andrzej zaborowski wrote:
> 2008/7/20 Anthony Liguori <anthony@codemonkey.ws>:
>   
>> andrzej zaborowski wrote:
>>     
>>> 2008/7/20 Anthony Liguori <anthony@codemonkey.ws>:
>>>  With -no-graphic there's no ds->data, or it can have lower bpp than
>>> what's otherwise available.
>>>
>>>       
>> Screen dumping with -no-graphic probably should just show a black screen
>> anyway.
>>     
>
> I thought this was the main use case. You shouldn't need sdl installed
> to perform the tests Avi talked about.
>   

You could still just do -vnc none to achieve the same effect.

>> I don't think a lower depth is really that big of a deal.  It's what the
>> user would be seeing anyway.  The simplicity seems really nice to me.
>>
>>     
>>>> I think your patch looks better, but I can also code up a new screen
>>>> dumping
>>>> mechanism that doesn't take over DisplayState unless I'm missing
>>>> something
>>>> obvious.
>>>>
>>>>         
>>> It's worth a try, dumping ds->data is perhaps the way to go but
>>> ds->depth is being set to 32bit and various video cards are optimised
>>> on the assumption that ds->depth doesn't change, so maybe there should
>>> be a notification callback.
>>>
>>>       
>> Yeah, that's a bug BTW and AFAIK it's only a problem with VMware VGA.
>>     
>
> AFAIK also at least three other adapters.
>   

Really?  Which ones?  I think both std-vga and cirrus are fine.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 6/6] kvm: qemu: fix vga screendump

[andrzej zaborowski]

2008/7/20 Anthony Liguori <anthony@codemonkey.ws>:
> andrzej zaborowski wrote:
>>
>> 2008/7/20 Anthony Liguori <anthony@codemonkey.ws>:
>>
>>>
>>> andrzej zaborowski wrote:
>>>
>>>>
>>>> 2008/7/20 Anthony Liguori <anthony@codemonkey.ws>:
>>>>  With -no-graphic there's no ds->data, or it can have lower bpp than
>>>> what's otherwise available.
>>>>
>>>>
>>>
>>> Screen dumping with -no-graphic probably should just show a black screen
>>> anyway.
>>>
>>
>> I thought this was the main use case. You shouldn't need sdl installed
>> to perform the tests Avi talked about.
>>
>
> You could still just do -vnc none to achieve the same effect.

What I mean is it should be totally independent of that and of X on
host, if you want to perform comparisons on the bitmaps (and for
various other reasons).

>
>>> I don't think a lower depth is really that big of a deal.  It's what the
>>> user would be seeing anyway.  The simplicity seems really nice to me.
>>>
>>>
>>>>>
>>>>> I think your patch looks better, but I can also code up a new screen
>>>>> dumping
>>>>> mechanism that doesn't take over DisplayState unless I'm missing
>>>>> something
>>>>> obvious.
>>>>>
>>>>>
>>>>
>>>> It's worth a try, dumping ds->data is perhaps the way to go but
>>>> ds->depth is being set to 32bit and various video cards are optimised
>>>> on the assumption that ds->depth doesn't change, so maybe there should
>>>> be a notification callback.
>>>>
>>>>
>>>
>>> Yeah, that's a bug BTW and AFAIK it's only a problem with VMware VGA.
>>>
>>
>> AFAIK also at least three other adapters.
>>
>
> Really?  Which ones?  I think both std-vga and cirrus are fine.

PXA270 lcdc, epson blizzard and s3c2410 lcdc (currently in
svn.openmoko.org only). It's easy to add notifications in these. In
VMware SVGA the guest needs to be somehow notified, it's possible the
guest polls the depth register already.

Regards

Re: [Qemu-devel] [PATCH 6/6] kvm: qemu: fix vga screendump

[Anthony Liguori]

andrzej zaborowski wrote:
> 2008/7/20 Anthony Liguori <anthony@codemonkey.ws>:
>   
> PXA270 lcdc, epson blizzard and s3c2410 lcdc (currently in
> svn.openmoko.org only). It's easy to add notifications in these. In
> VMware SVGA the guest needs to be somehow notified, it's possible the
> guest polls the depth register already.
>   

Yeah, a notification is needed.

Regards,

Anthony Liguori

> Regards
>
>
>   

Re: [Qemu-devel] [PATCH 6/6] kvm: qemu: fix vga screendump

[Anthony Liguori]

andrzej zaborowski wrote:
> 2008/7/20 Anthony Liguori <anthony@codemonkey.ws>:
>   
>> andrzej zaborowski wrote:
>>     
>>> 2008/7/20 Anthony Liguori <anthony@codemonkey.ws>:
>>>
>>>       
>>>> andrzej zaborowski wrote:
>>>>
>>>>         
>>>>> 2008/7/20 Anthony Liguori <anthony@codemonkey.ws>:
>>>>>  With -no-graphic there's no ds->data, or it can have lower bpp than
>>>>> what's otherwise available.
>>>>>
>>>>>
>>>>>           
>>>> Screen dumping with -no-graphic probably should just show a black screen
>>>> anyway.
>>>>
>>>>         
>>> I thought this was the main use case. You shouldn't need sdl installed
>>> to perform the tests Avi talked about.
>>>
>>>       
>> You could still just do -vnc none to achieve the same effect.
>>     
>
> What I mean is it should be totally independent of that and of X on
> host, if you want to perform comparisons on the bitmaps (and for
> various other reasons).
>   

-vnc none gives a consistent depth of 32-bit.

FWIW, I have a different approach to doing what Avi describes that uses 
a VNC client.  The advantage of this is that you can have a lot more 
control over the pixel format to avoid this sort of problem in the first 
place.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 6/6] kvm: qemu: fix vga screendump

[Jamie Lokier]

Anthony Liguori wrote:
> FWIW, I have a different approach to doing what Avi describes that uses 
> a VNC client.  The advantage of this is that you can have a lot more 
> control over the pixel format to avoid this sort of problem in the first 
> place.

I like that and would like to use it to grab screenshots periodically
to shrink and show thumbnails in a web page or GUI.  Isn't it better
to use VNC for that than asking QEMU to dump a screenshot itself,
because the latter will pause QEMU for a moment?

Only trouble is, I want that to work even if someone has connected by
VNC to QEMU to actually use it - and they might connect in exclusive mode.

An option to serve a read-only VNC on another port would be nice :-)

Just saying..

-- Jamie

[Qemu-devel] [PATCH 0/6] Various fixes from KVM tree

[Anthony Liguori]

This series contains various fixes from the KVM tree.  They all have appeared
on qemu-devel at some point.  These fixes are unrelated to KVM.