Dear Developers
The mouse movement is too slow inside a windows client. The windows remote
machine is located in a KVM server Red Hat 6.0. I installed the stable
client but it is unusable unless the mouse works better. Any ideas?
Also where is the experimental MAC OS X client?
Federico
_
Hi,
On 04/01/2011 05:30 PM, Alon Levy wrote:
On Fri, Apr 01, 2011 at 05:13:04PM +0200, Hans de Goede wrote:
The agent message filter keeps track of messages as they are being send
reset the relevant filter to its initial state when one of the 2 ends
of the agent<->client "tunnel" disconnects.
On Fri, Apr 01, 2011 at 06:19:11PM +0200, Christophe Fergeau wrote:
> MIN() is already defined in spice-protocol/spice/macros.h
Hrm, and the patch below isn't the one I meant to sent, the correct one is
attached.
Christophe
From e61aebb30b529351a21ac37a5f2a149f773a9664 Mon Sep 17 00:00:00 2001
Fr
spice configure.ac has some code to detect if the compiler has
a special attribute to tag some functions so that they generate a
warning when their return value isn't checked. However, this test
is broken (the gcc attribute name is "warn_unused_result", not
"__warn_unused_result__" and WARN_UNUSED_
MIN() is already defined in spice-protocol/spice/macros.h
---
server/tests/test_util.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/server/tests/test_util.h b/server/tests/test_util.h
index 5344a4f..c63f051 100644
--- a/server/tests/test_util.h
+++ b/server/tests/t
Hi,
Here are two more patches which remove unused "code" from spice. I
requested a merge request for spice-gtk since the 2nd patch applies to it
too.
Christophe
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org
On Fri, Apr 01, 2011 at 05:13:04PM +0200, Hans de Goede wrote:
> The agent message filter keeps track of messages as they are being send
> reset the relevant filter to its initial state when one of the 2 ends
> of the agent<->client "tunnel" disconnects.
I'm guessing this is related to my windows
On Fri, Apr 01, 2011 at 05:13:03PM +0200, Hans de Goede wrote:
> read_from_vdi_port calls dispatch_vdi_port data, which will disconnect
> the guest agent if it sends invalid data. It would then try to read more
> data from the disconnected guest agent resulting in a NULL ptr dereference,
> this pat
On Fri, Apr 01, 2011 at 05:13:02PM +0200, Hans de Goede wrote:
> write_to_vdi_port() was checking for reds->agent_state.connected to determine
> wether it could write queued data. But agent_state.connected reflects if
> *both* ends are connected. If the client has disconnected, but the guest agent
On Fri, Apr 01, 2011 at 05:13:01PM +0200, Hans de Goede wrote:
> We were calling reds_reset_vdp on client disconnect, which is not a good
> idea. reds_reset_vdp does 3 things:
ACK.
>
> 1) It resets the state related to reading chunks from the spicevmc virtio
>port. If the client disconnects
The check this patch removes causes us to not set vdagent to NULL, nor
update the mouse mode when the guest agent disconnects when no client is
attached. Which leads to a non working mouse, and on agent reconnect a
"spice_server_char_device_add_interface: vdagent already attached" message
instead o
This can happen for example when a SPICE_MSGC_MAIN_AGENT_START message
from the client and the vdagent disconnecting race.
---
server/reds.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 05f52a0..b349d77 100644
--- a/server/reds.c
+++
This ensures that if the client or agent connects to the client-agent
"tunnel" while the other side is halfway through sending a multi part
message, the rest of the message gets discarded, and the connecting
party starts getting data at the beginning of the next message.
---
server/reds.c | 56 +
---
server/agent-msg-filter.c | 30 ++
server/agent-msg-filter.h |5 +++--
server/reds.c |9 +
3 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/server/agent-msg-filter.c b/server/agent-msg-filter.c
index 3867d11..cd1f78c 100
Filter all data from client, even when there is no agent connected
to keep filter state correct.
---
server/reds.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 3c7077a..7a3399e 100644
--- a/server/reds.c
+++ b/s
The agent message filter keeps track of messages as they are being send
reset the relevant filter to its initial state when one of the 2 ends
of the agent<->client "tunnel" disconnects.
---
server/reds.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/server/reds.c b/serv
read_from_vdi_port calls dispatch_vdi_port data, which will disconnect
the guest agent if it sends invalid data. It would then try to read more
data from the disconnected guest agent resulting in a NULL ptr dereference,
this patch fixes this.
---
server/reds.c |2 +-
1 files changed, 1 inserti
write_to_vdi_port() was checking for reds->agent_state.connected to determine
wether it could write queued data. But agent_state.connected reflects if
*both* ends are connected. If the client has disconnected, but the guest agent
is still connected and some data is still pending (like a final clipb
We were calling reds_reset_vdp on client disconnect, which is not a good
idea. reds_reset_vdp does 3 things:
1) It resets the state related to reading chunks from the spicevmc virtio
port. If the client disconnects while the guest agent is in the middle
of sending a chunk, this will lead to
Hi all,
While merging and testing Marc-Andre's multi selection copy paste agent
patches I found a server agent handling bug, then another, etc.
Note as the Subject indicates this patch set is against the 0.8 branch,
I'll forward port it to master of course, but after working on this for
1.5 days
It's not obvious how qemu should be started so that vdagentd can
find its com.redhat.spice.0 virtio device. It's explained at
http://spice-space.org/page/Whiteboard/AgentProtocol but is easier
to find if it's explained in README too.
---
README | 17 +
1 files changed, 17 inserti
Hi,
The agent protocol requires sending messages in 2048 byte chunks, this
means that 1 message can span multiple chunks. In the past this never
happened but now that we support copy and paste this can easily
happen with a large copy and paste.
There are 4 scenarios to keep in mind here:
1) The
Hello Bill,
could you please send us your qemu command line (ps -ef | grep qemu on host).
And also your spicec command line?
Also it would be useful to print out iptables settings on host (iptables -L).
Lubos
- Original Message -
From: "Bill George"
To: spice-devel@lists.freedesktop.o
23 matches
Mail list logo
