On Wed, 14 Mar 2012 07:28:44 -0600
Eric Blake wrote:
> On 03/14/2012 07:19 AM, Alon Levy wrote:
>
> >> Also, when returning the image via fd, we could offload its writing to
> >> a bh. This would give us a poor man's async support, where the biggest
> >> drawback would the lack of error detectio
On 03/14/2012 07:19 AM, Alon Levy wrote:
>> Also, when returning the image via fd, we could offload its writing to
>> a bh. This would give us a poor man's async support, where the biggest
>> drawback would the lack of error detection (can this operation fail anyway?).
>>
>
> It leaves detection
On Wed, Mar 14, 2012 at 10:13:19AM -0300, Luiz Capitulino wrote:
> On Wed, 14 Mar 2012 10:01:15 +
> Stefan Hajnoczi wrote:
>
> > On Wed, Mar 14, 2012 at 9:51 AM, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > >> The most practical first step would be simply sending the ppm over a
> > >> socket fr
On Wed, 14 Mar 2012 12:42:36 +0100
Kevin Wolf wrote:
> Am 14.03.2012 10:42, schrieb Stefan Hajnoczi:
> > On Tue, Mar 13, 2012 at 1:17 PM, Gerd Hoffmann wrote:
> >> Hi,
> >>
> >>> If you want to do it as part of the QEMU codebase then a thread is
> >>> probably the best way - it avoids the troub
On Wed, 14 Mar 2012 10:01:15 +
Stefan Hajnoczi wrote:
> On Wed, Mar 14, 2012 at 9:51 AM, Gerd Hoffmann wrote:
> > Hi,
> >
> >> The most practical first step would be simply sending the ppm over a
> >> socket from ppm_save(). The 'screendump' command today already blocks
> >> so no new badn
Am 14.03.2012 10:42, schrieb Stefan Hajnoczi:
> On Tue, Mar 13, 2012 at 1:17 PM, Gerd Hoffmann wrote:
>> Hi,
>>
>>> If you want to do it as part of the QEMU codebase then a thread is
>>> probably the best way - it avoids the troubles of forking a
>>> multithreaded program and letting go of resour
On Wed, Mar 14, 2012 at 9:51 AM, Gerd Hoffmann wrote:
> Hi,
>
>> The most practical first step would be simply sending the ppm over a
>> socket from ppm_save(). The 'screendump' command today already blocks
>> so no new badness is being added. There would be no threads or fancy
>> image encodin
Hi,
> The most practical first step would be simply sending the ppm over a
> socket from ppm_save(). The 'screendump' command today already blocks
> so no new badness is being added. There would be no threads or fancy
> image encoding.
Adding scaling / compression support will add more overhe
On Tue, Mar 13, 2012 at 1:17 PM, Gerd Hoffmann wrote:
> Hi,
>
>> If you want to do it as part of the QEMU codebase then a thread is
>> probably the best way - it avoids the troubles of forking a
>> multithreaded program and letting go of resources (guest memory, file
>> descriptors) that aren't n
Hi,
> If you want to do it as part of the QEMU codebase then a thread is
> probably the best way - it avoids the troubles of forking a
> multithreaded program and letting go of resources (guest memory, file
> descriptors) that aren't needed across fork.
That pretty much requires async monitor c
On Tue, Mar 13, 2012 at 11:14 AM, Marc-André Lureau wrote:
> Hi
>
> - Mensaje original -
>> Yeah it wants png, jpeg, tiff. What I'm concerned about is that QEMU
>> should be doing emulation/virtualization, not processing images for
>> an
>> end-user. Its main loop is not structured to do
Hi
- Mensaje original -
> Yeah it wants png, jpeg, tiff. What I'm concerned about is that QEMU
> should be doing emulation/virtualization, not processing images for
> an
> end-user. Its main loop is not structured to do utility tasks
> unrelated to running the guest. If implemented prop
On Mon, Mar 12, 2012 at 7:27 PM, Marc-André Lureau
wrote:
> On Mon, Mar 12, 2012 at 7:06 PM, Stefan Hajnoczi wrote:
>>
>> I think ppm for lossless and png for small file size are good options to
>> have. Beyond that it's up to the caller to deal with the screenshot,
>> which might be scaling, de
On 2012-03-12 22:22, Michael Roth wrote:
> On Mon, Mar 12, 2012 at 01:57:14PM -0500, Anthony Liguori wrote:
>> On 03/12/2012 01:56 PM, Marc-André Lureau wrote:
>>> On Mon, Mar 12, 2012 at 7:53 PM, Anthony Liguori
>>> wrote:
Why not just return the screendump through QMP?
>>>
>>> in base64, b
On Mon, Mar 12, 2012 at 01:57:14PM -0500, Anthony Liguori wrote:
> On 03/12/2012 01:56 PM, Marc-André Lureau wrote:
> >On Mon, Mar 12, 2012 at 7:53 PM, Anthony Liguori
> >wrote:
> >>Why not just return the screendump through QMP?
> >
> >in base64, base85?
>
> I think Jan had patches for base64 b
Hi
On Mon, Mar 12, 2012 at 4:42 PM, Eric Blake wrote:
> Libvirt would also benefit from screendump to fd:name (where name refers
> to an fd passed via getfd).
Is this all it takes? or am I missing something?
+} else if (strstart(uri, "fd:", &p)) {
+int fd = strtol(p, NULL, 0);
+
On Mon, Mar 12, 2012 at 7:06 PM, Stefan Hajnoczi wrote:
>
> I think ppm for lossless and png for small file size are good options to
> have. Beyond that it's up to the caller to deal with the screenshot,
> which might be scaling, detecting diffs, encoding in a fancier format,
> etc.
Daniel Berra
On Mon, Mar 12, 2012 at 02:11:26PM +0100, Marc-André Lureau wrote:
> Next, I would like to add support for a scaling factor too (a typical use
> case is to show a small thumbnail of the desktop). Specifying only the
> requested "width" or "height" should be supported. Should we rely on pixman
>
On 03/12/2012 01:56 PM, Marc-André Lureau wrote:
On Mon, Mar 12, 2012 at 7:53 PM, Anthony Liguori wrote:
Why not just return the screendump through QMP?
in base64, base85?
I think Jan had patches for base64 blobs but I think it got tangled up in
VMState related controversy.
Jan, am I cor
On Mon, Mar 12, 2012 at 7:53 PM, Anthony Liguori wrote:
> Why not just return the screendump through QMP?
in base64, base85?
--
Marc-André Lureau
On 03/12/2012 08:11 AM, Marc-André Lureau wrote:
Hi,
The current screendump command can only save to disk very large PPM files.
The following patches add support for screendump in a UNIX socket, following the syntax
used for migration URI: "unix:/path/to/socket".
Why not just return the scre
On Mon, Mar 12, 2012 at 02:11:26PM +0100, Marc-André Lureau wrote:
> Hi,
>
> The current screendump command can only save to disk very large PPM files.
>
> The following patches add support for screendump in a UNIX socket,
> following the syntax used for migration URI: "unix:/path/to/socket".
To
On 03/12/2012 07:11 AM, Marc-André Lureau wrote:
> Hi,
>
> The current screendump command can only save to disk very large PPM files.
>
> The following patches add support for screendump in a UNIX socket, following
> the syntax used for migration URI: "unix:/path/to/socket".
Libvirt would also
Hi,
The current screendump command can only save to disk very large PPM files.
The following patches add support for screendump in a UNIX socket, following
the syntax used for migration URI: "unix:/path/to/socket".
The last 3 patches add support for dumping in PNG format. This can reduce the
24 matches
Mail list logo
