Hi
On Mon, Jan 23, 2017 at 4:04 PM Gerd Hoffmann wrote:
> Hi,
> >
> > If you only ref, you could have the image being modified while it is
> > being saved asynchronously, this could result in tearing artefacts,
> > no?
>
> Yes, but you have that problem _anyway_. screendump qmp command can ru
Hi,
>
> If you only ref, you could have the image being modified while it is
> being saved asynchronously, this could result in tearing artefacts,
> no?
Yes, but you have that problem _anyway_. screendump qmp command can run
in parallel to guest vcpu, so it can race with guest display updates
Hi
On Thu, Jan 19, 2017 at 12:21 PM Gerd Hoffmann wrote:
> On Mi, 2017-01-18 at 20:03 +0400, Marc-André Lureau wrote:
> > +surface = qemu_console_surface(con);
> > +
> > +/* FIXME: async save with coroutine? it would have to copy or
> > lock
> > + * the surface. */
> > +ppm_save(
On Mi, 2017-01-18 at 20:03 +0400, Marc-André Lureau wrote:
> +surface = qemu_console_surface(con);
> +
> +/* FIXME: async save with coroutine? it would have to copy or
> lock
> + * the surface. */
> +ppm_save(filename, surface, &err);
> +
No need to lock or copy.
ppm_save() uses t
Make screendump async to provide correct screendumps.
HMP doesn't have async support, so it has to remain sync to avoid
potential races.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=1230527
Signed-off-by: Marc-André Lureau
---
qapi-schema.json | 5 +++-
include/ui/console.h | 1 +
