From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:57516)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UUbqd-0001OZ-8r
	for qemu-devel@nongnu.org; Tue, 23 Apr 2013 07:57:29 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UUbqb-000341-Vr
	for qemu-devel@nongnu.org; Tue, 23 Apr 2013 07:57:23 -0400
Received: from mx1.redhat.com ([209.132.183.28]:59083)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UUbqb-00033t-Ma
	for qemu-devel@nongnu.org; Tue, 23 Apr 2013 07:57:21 -0400
Message-ID: <5176771D.8070705@redhat.com>
Date: Tue, 23 Apr 2013 13:57:17 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <1366275680-15416-1-git-send-email-kraxel@redhat.com>
	<87ppxq6hmn.fsf@blackfin.pond.sub.org>
	<5174DEE5.20406@redhat.com> <517504CB.6040303@redhat.com>
	<20130422085043.4a3e891c@redhat.com>
	<51753471.5080803@redhat.com> <8738uiqzm1.fsf@codemonkey.ws>
	<51756D68.1050705@redhat.com> <87obd6h2jg.fsf@codemonkey.ws>
In-Reply-To: <87obd6h2jg.fsf@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RfC PATCH 0/5] console: qom-ify & extent
 screendump monitor command
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>, Luiz Capitulino <lcapitulino@redhat.com>

  Hi,

>> True, but I'm not sure we want to go there.  We'd need to add support
>> for options like JPG quality factor etc.
> 
> PNG would be extremely handy and would go a long way to eliminating the
> concern about size.  We already link against libpng too.

vnc uses libpng when available, but it isn't mandatory today.

So we have the choice to (a) make it a hard dependency or (b) make png
support optional.  (b) pretty much implies that nobody will use it
because they can't depend on it being available, so it's largely pointless.

> You can imagine an interface like:
> 
> { "type": "Blob",
>   "data": { "format": "DataFormat", "data": "str" } }
> 
> ...
> 
> { "union": "ImageOptions",
>   "data": { "ppm": "PPMOptions", 
>             "png": "PNGOptions" } }
> 
> { "command": "display-get-screenshot",
>   "data": { "id": "str", "*ImageOptions": "options",
>                            "*format": "DataFormat" },
>   "returns": "Blob" }

> I think it's worth implementing.  A local screenshot I have is 2.3Mb as
> a PPM but only 320k as a PNG.

I don't think it is useful to send image files as base64 over qmp.

We should either send the image file to a file (or filehandle via
fdset).  This would be very simliar to the current screendump command,
and libvirt can easily wind up a pipe to tools like cjpeg or just ask
qemu to dump into a file.

Or we'll go send the raw pixel data over qmp, maybe with optional
compression, so the receiving side doesn't has to bother with decoding
some image file format, like this:

{ "type" : "DisplayContent",
  "data  : { "width"       : int,
             "height"      : int,
             "data"        : str }

cheers,
  Gerd