On Fri, 2017-04-28 at 05:55 -0400, Frediano Ziglio wrote:
> >
> > On Thu, 2017-04-27 at 15:20 -0500, Jonathon Jongsma wrote:
> > > Previously, if the user attempted to transfer a file that had the
> > > same
> > > name as a file that already exists on the guest, we would just
> > > fail
> > > the
>
>
>
> Hi,
>
> I've observed some latency issues, for example, changing focus from one
> terminal to another is a bit sluggish. Typing isn't too bad.
> Interaction with the sliding GNOME unlock screen and drawing the desktop
> after unlock is painfully
On 02/05/17 16:07, Frediano Ziglio wrote:
>>
>>
>>
>> On 02/05/17 15:22, Frediano Ziglio wrote:
Hi,
I've observed some latency issues, for example, changing focus from one
terminal to another is a bit sluggish. Typing isn't too bad.
Interaction with the sl
Hi,
On Tue, May 02, 2017 at 10:07:53AM -0400, Frediano Ziglio wrote:
> > In particular, rendering the gray background of the GNOME unlock screen
> > appears very slow, it renders one line at a time from top to bottom, it
> > takes several seconds. Rendering the desktop background image (default
>
>
>
>
> On 02/05/17 15:22, Frediano Ziglio wrote:
> >>
> >>
> >>
> >> Hi,
> >>
> >> I've observed some latency issues, for example, changing focus from one
> >> terminal to another is a bit sluggish. Typing isn't too bad.
> >> Interaction with the sliding GNOME unlock screen and drawing the des
On 02/05/17 15:22, Frediano Ziglio wrote:
>>
>>
>>
>> Hi,
>>
>> I've observed some latency issues, for example, changing focus from one
>> terminal to another is a bit sluggish. Typing isn't too bad.
>> Interaction with the sliding GNOME unlock screen and drawing the desktop
>> after unlock is p
On 02/05/17 12:43, Christophe Fergeau wrote:
> On Tue, May 02, 2017 at 11:39:08AM +0200, Daniel Pocock wrote:
>>
>>
>> Hi,
>>
>> I've observed that the Xorg process in my virtual server
>> sometimes crashes when I launch Firefox. Xorg.0.log had an error
>> about "Out of video memory: Could no
Upon change of display mode the driver waits until all the
queued drawables pushed to the host or discarded. This eliminates
server warnings "rendering incorrect" in "get_drawable" when the
drawable command was created by guest driver just before change
of display mode and posted to the server duri
>
>
>
> Hi,
>
> I've observed some latency issues, for example, changing focus from one
> terminal to another is a bit sluggish. Typing isn't too bad.
> Interaction with the sliding GNOME unlock screen and drawing the desktop
> after unlock is painfully slow.
>
Looks like your problems are d
Upon change of display mode the driver waits until all the
queued drawables pushed to the host or discarded. This eliminates
server warnings "rendering incorrect" in "get_drawable" when the
drawable command was created by guest driver just before change
of display mode and posted to the server duri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/05/17 14:46, Christophe Fergeau wrote:
> On Tue, May 02, 2017 at 02:16:00PM +0200, Daniel Pocock wrote:
>>
>>
>> On 02/05/17 13:54, Christophe Fergeau wrote:
>>> On Tue, May 02, 2017 at 01:46:20PM +0200, Daniel Pocock wrote:
>>>
On Tue, May 02, 2017 at 02:16:00PM +0200, Daniel Pocock wrote:
>
>
> On 02/05/17 13:54, Christophe Fergeau wrote:
> > On Tue, May 02, 2017 at 01:46:20PM +0200, Daniel Pocock wrote:
> >>
> >>
> >> On 02/05/17 12:43, Christophe Fergeau wrote:
> >>> On Tue, May 02, 2017 at 11:39:08AM +0200, Daniel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/05/17 13:54, Christophe Fergeau wrote:
> On Tue, May 02, 2017 at 01:46:20PM +0200, Daniel Pocock wrote:
>>
>>
>> On 02/05/17 12:43, Christophe Fergeau wrote:
>>> On Tue, May 02, 2017 at 11:39:08AM +0200, Daniel Pocock wrote:
>>>
On Tue, May 02, 2017 at 01:46:20PM +0200, Daniel Pocock wrote:
>
>
> On 02/05/17 12:43, Christophe Fergeau wrote:
> > On Tue, May 02, 2017 at 11:39:08AM +0200, Daniel Pocock wrote:
> >>
> >>
> >> Hi,
> >>
> >> I've observed that the Xorg process in my virtual server
> >> sometimes crashes when
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/05/17 12:43, Christophe Fergeau wrote:
> On Tue, May 02, 2017 at 11:39:08AM +0200, Daniel Pocock wrote:
>>
>>
>> Hi,
>>
>> I've observed that the Xorg process in my virtual server
>> sometimes crashes when I launch Firefox. Xorg.0.log had
On Mon, 24 Apr 2017, Christophe Fergeau wrote:
[...]
> > +c->streams[op->id] = display_stream_create(channel, op->surface_id,
> > op->flags, op->codec_type);
> > +if (c->streams[op->id] == NULL) {
> > +spice_printerr("could not create the %u video stream", op->id);
> > des
On Tue, May 02, 2017 at 11:39:08AM +0200, Daniel Pocock wrote:
>
>
> Hi,
>
> I've observed that the Xorg process in my virtual server sometimes
> crashes when I launch Firefox. Xorg.0.log had an error about "Out of
> video memory: Could not allocate 7274816 bytes", so I increased video
> RAM fr
On Tue, May 02, 2017 at 05:46:52AM -0400, Frediano Ziglio wrote:
> Acked-by: Frediano Ziglio
Thanks, I've pushed the 3 patches.
Christophe
signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https:/
Hi,
I've observed some latency issues, for example, changing focus from one
terminal to another is a bit sluggish. Typing isn't too bad.
Interaction with the sliding GNOME unlock screen and drawing the desktop
after unlock is painfully slow.
The virtual server I connect to runs Debian jessie a
>
> The red_get_* methods in red-parse-qxl.c return a boolean, even though
> their return type is an int, and they return 1/0. This commit changes
> this to the more explicit bool/true/false.
> ---
> server/red-parse-qxl.c | 74
> +-
> server/red-p
Hi,
I've observed that the Xorg process in my virtual server sometimes
crashes when I launch Firefox. Xorg.0.log had an error about "Out of
video memory: Could not allocate 7274816 bytes", so I increased video
RAM from 64MB to 256MB. On the last crash the error about memory was
not there, but
On Tue, May 02, 2017 at 04:58:22AM -0400, Frediano Ziglio wrote:
> >
> > From: Frediano Ziglio
> >
> > Reverse return values of the various bool methods so that 'true' means
> > success, and 'false' failure rather than the opposite.
> Obviously cannot ack
>
Looks good to me,
Acked-by: Christo
>
> From: Frediano Ziglio
>
> Reverse return values of the various bool methods so that 'true' means
> success, and 'false' failure rather than the opposite.
> ---
> server/red-parse-qxl.c | 78
> ++---
> server/red-worker.c | 14 ---
>
> ---
> server/red-parse-qxl.c | 32
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/server/red-parse-qxl.c b/server/red-parse-qxl.c
> index a3c897d12..287a43eea 100644
> --- a/server/red-parse-qxl.c
> +++ b/server/red-parse-qxl.c
> @@ -435
On Mon, May 01, 2017 at 09:54:19AM -0500, Jonathon Jongsma wrote:
> I believe that this is the only patch of the series that has not been
> formally ACKed yet. Any takers? In the first version of the patch
> Frediano found a bug where I was returning too early from
> playback_channel_client_constru
25 matches
Mail list logo
