Hi
- Original Message -
> Windows guests with multi-monitors will often send down the same image
> via different channels. If these instances are not counted, one channel
> can delete an image before all the rest of the channels are finished with
> it. In this case, the client will hang.
>
Windows guests with multi-monitors will often send down the same image
via different channels. If these instances are not counted, one channel
can delete an image before all the rest of the channels are finished with
it. In this case, the client will hang.
Addresses bug: https://bugzilla.redhat.c
Locking the individual calls that access the pixmap cache in fill_bits is
not adequately thread safe. Often a windows guest with multiple monitors
will be sending the same image via different threads. Both threads can
be in fill_bits at the same making changes to the cache for the same
image. This
On 06/19/2015 02:22 PM, David Mansfield wrote:
Hi All,
We (4 of us in my company) have been very happy with spice over the
last year or so running with dual 1920x1200 monitors, for which
qxl-vga.vgamem_mb always needed to be set to 32 (default is 16) or
Xorg-qxl doesn't get enough video ram.
Hi All,
We (4 of us in my company) have been very happy with spice over the last
year or so running with dual 1920x1200 monitors, for which
qxl-vga.vgamem_mb always needed to be set to 32 (default is 16) or
Xorg-qxl doesn't get enough video ram. I even bumped it to 64MB and we
can run a 3940
hi
- Original Message -
> It is ok to send monitor configuration even for displays which are not
> disabled or enabled. Because the guest having support for the sparse
> monitor configuration (VD_AGENT_CAP_SPARSE_MONITORS_CONFIG) will not
> resize the monitor which is disabled / undefined.
hi
- Original Message -
> ---
> src/channel-main.c | 24 ++--
> 1 file changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/src/channel-main.c b/src/channel-main.c
> index c55d097..4e8046e 100644
> --- a/src/channel-main.c
> +++ b/src/channel-main.c
> @@ -74,6
Hey,
On Fri, Jun 19, 2015 at 06:37:01PM +0200, Christophe Fergeau wrote:
> Hey,
>
> On Thu, Jun 18, 2015 at 11:58:20AM +0200, Christophe Fergeau wrote:
> > It's not directly used by spice-common, but this way spice-gtk and
> > spice-server can share the same implementation.
> > ---
> > m4/spice-
Hey,
On Thu, Jun 18, 2015 at 11:58:20AM +0200, Christophe Fergeau wrote:
> It's not directly used by spice-common, but this way spice-gtk and
> spice-server can share the same implementation.
> ---
> m4/spice-deps.m4 | 24
> 1 file changed, 24 insertions(+)
>
> diff --gi
---
src/channel-main.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/src/channel-main.c b/src/channel-main.c
index c55d097..4e8046e 100644
--- a/src/channel-main.c
+++ b/src/channel-main.c
@@ -74,6 +74,12 @@ typedef struct SpiceFileXferTask {
G
It is ok to send monitor configuration even for displays which are not
disabled or enabled. Because the guest having support for the sparse
monitor configuration (VD_AGENT_CAP_SPARSE_MONITORS_CONFIG) will not
resize the monitor which is disabled / undefined.
Fixes:
https://bugs.freedesktop.org/sho
red_marshall_image() allows to use other than QUIC compression only
when auto_lz or auto_glz image compression is set.
---
Also the LZ4 part of code in red_marshall_image could not be triggered
---
server/red_worker.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git
When KMS is enabled, the mm_time value of a QXLDrawable is undefined.
This results in severe synchronization problems. This patch sets it to
zero to force the spice-server to use the local clock.
---
src/qxl_surface.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/qxl_surface.c b/src/qxl_
When KMS is enabled, the mm_time value of a QXLDrawable is undefined.
This results in severe synchronization problems. This patch sets it to
zero to force the spice-server to use the local clock.
---
src/qxl_surface.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/qxl_surface.c b/src/qxl_
As one interface was added bump the version and put a comment to avoid
too much updates.
Signed-off-by: Frediano Ziglio
Acked-by: Christophe Fergeau
---
configure.ac | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 1802ff1..2aaf88d 10064
This patch set allows to set maximum monitors.
Mainly change is contained in first patch while the second just
bump some version information.
Changes from v3:
- renamed spice_qxl_set_monitors_config_limit to
spice_qxl_set_max_monitors;
- use UINT_MAX instead of UINT16_MAX for unsigned int
maxi
spice-server will attempt to limit number of monitors.
Guest machine can send monitor list it accepts. Limiting the number sent
by guest will limit the number of monitors client will try to enable.
The guest usually see client monitors enabled and start using it so
not seeing client monitor won't t
- Original Message -
> From: "Christophe Fergeau"
> To: "Marc-André Lureau"
> Cc: spice-de...@freedesktop.org
> Sent: Friday, June 19, 2015 12:25:52 PM
> Subject: Re: [Spice-devel] [spice-gtk] spicy-*: Remove translation support
>
> On Thu, Jun 18, 2015 at 06:06:51PM +0200, Marc-André
On Thu, Jun 18, 2015 at 06:06:51PM +0200, Marc-André Lureau wrote:
> ack thanks
Ok, pushed. Any thoughts about having the translations on
fedora.zanata.org ?
Christophe
pgpGwdueIJSSD.pgp
Description: PGP signature
___
Spice-devel mailing list
Spice-de
I had already acked these 2 patches when Fidencio sent them save for one
small change that I see you have made (the num_caps addition). If there
are no more changes, ACK.
Christophe
On Thu, Jun 18, 2015 at 07:51:16PM +0200, Lukas Venhoda wrote:
> This small series is a first effort to fix client-
On Thu, Jun 18, 2015 at 07:51:16PM +0200, Lukas Venhoda wrote:
> This small series is a first effort to fix client-side endianess
> problems. With the patches applied (plus the ones for spice-common), we
> can connect to and play with a guest running on a LE machine with a BE
> client. However, the
On Thu, Jun 18, 2015 at 07:50:27PM +0200, Lukas Venhoda wrote:
> Quic magic would have to be converted when sending to BE client.
> This ensures, that both client and server always have the same quick magic.
Same comment as for the lz magic, this is not "the same quic magic", we
just want it to be
On Thu, Jun 18, 2015 at 07:50:28PM +0200, Lukas Venhoda wrote:
> Converts all decoded words in quic from little endian to local
> machine endianness.
ACK, I'm fairly sure more fixes in the encoding path will be needed
(maybe in encode_32, maybe a bit higher/lower in the stack than this
function).
On Thu, Jun 18, 2015 at 07:50:26PM +0200, Lukas Venhoda wrote:
> Commit d39dfbfe changes to be lz magic always treated as LE when encoded.
>
> Changing lz magic to constant instead of a runtime coversion from string
> to int is a better way to go. This way lz magic will stay the same on
> both BE
On Fri, Jun 19, 2015 at 11:12:51AM +0200, Christophe Fergeau wrote:
> >>> On Thu, Jun 18, 2015 at 05:40:29PM +, Klaus Hochlehnert wrote:
> >> From: Victor Toso [mailto:victort...@redhat.com]
> >On Thu, Jun 18, 2015 at 06:57:10PM +, Klaus Hochlehnert wrote:
> >>> Is the lz4 package too old
>>> On Thu, Jun 18, 2015 at 05:40:29PM +, Klaus Hochlehnert wrote:
>> From: Victor Toso [mailto:victort...@redhat.com]
>On Thu, Jun 18, 2015 at 06:57:10PM +, Klaus Hochlehnert wrote:
>>> Is the lz4 package too old in Ubuntu 14.04?
>>
>> Maybe, which version do you have?
>> pkg-config --mod
26 matches
Mail list logo
