Hi all:
I am now using spice now, but stucked by some problems.
My vm is XP, and I can the monitor refresh rate! It is always 100HZ, and
it it too high, How can I decrease it ?
Thanks a lot!
Yours.
___
Spice-devel mailing list
Hi Naga,
Tested and reproduced it on Win7.
I don't have a patch yet for solving it, but you comment out the line:
//ret = _running = false;
so vdagent won't exit, although mouse will not be effective on such apps.
If it's a must, meanwhile you can always switch back to server mouse
mode by
- Original Message -
Hi Naga,
Tested and reproduced it on Win7.
I bet you'd see this in any many personal FW / Antivirus, to prevent a
malicious software from manipulating it via the mouse (and disable it, for
example).
I'd try with ZoneAlarm
Similarly to SPICE_MSG_AGENT_CONNECTED, the msg notifies the main
channel about attaching an agent. In addition the msg also contains the
number of tokens allocated to the client.
---
spice/enums.h|1 +
spice/protocol.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff
The main difference between semi-seamless and seamless migration is that
while in semi-seamless migration the state of all the channels is
being completely reset after migration is complete, in seamless migration
the essential parts of the state are restored on the server side, and
are left the
The msg is used for setting the number of allocated client tokens when
we notify the client that the agent is attached.
---
common/messages.h |2 ++
spice-protocol|2 +-
spice.proto |4
3 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/common/messages.h
see spice-protocol for more details
commit 1ad5d259cb4b695ec3106de7ccd082e031e7ae11
---
common/client_marshallers.h |1 +
common/messages.h | 15 ++-
spice-protocol |2 +-
spice.proto | 24 +---
spice1.proto
for checking if all the channel clients connected support the cap
---
server/red_channel.c | 28
server/red_channel.h |4
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/server/red_channel.c b/server/red_channel.c
index 2a7acbf..1cad9eb
send SPICE_MSG_MAIN_AGENT_CONNECTED_TOKENS
---
server/main_channel.c | 17 -
server/reds.c | 16 ++--
spice-common |2 +-
3 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/server/main_channel.c b/server/main_channel.c
index
if vdi_port_read_buf_process failes, we detach the agent and also release
the read buffer. We shouldn't try reading from the device afterwards.
---
server/reds.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 8d6dbfb..53f0a39 100644
The list of attached char_devices will be used in the next patch
for notifying each instance of SpiceCharDeviceState when the vm
is started or stopped.
---
server/char_device.c |1 +
server/reds.c| 44
server/reds.h|1 +
3
When vm state changes (started/stopped), we notify all the
attached SpiceCharDeviceStates about the change. This is mainly required
for avoiding writing/reading to/from the device during the non-live
stage of migration.
spice version will be bumped in one of the following patches.
---
This new call is used in order to identify whether qemu, or
the management (e.g. libvirt), support seamless migration.
If it is supported, qemu spice cmd-line configuration should have
seamless-migration=on.
In addition, we disable seamless migration support if multiple clients
are allowed.
New api entries:
spice_server_vm_start
spice_server_vm_stop
spice_server_set_seamless_migration
---
server/spice-server.syms |7 +++
server/spice.h |2 +-
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/server/spice-server.syms
The file will hold the declarations of the different migration
data messages (depending on the channel), that will be passed
from the src server to the dst server, via the client, using
SPICE_MSG_MIGRATE_DATA.
---
server/Makefile.am |1 +
server/migration_protocol.h | 49
Also Update server and client according to the change of
SpiceMsgMainMigrationBegin: it now holds all the fields inside
SpiceMigrationDstInfo.
---
client/red_client.cpp | 18 +-
server/main_channel.c | 16
spice-common |2 +-
3 files changed, 18
sending SPICE_MSG_MAIN_MIGRATE_BEGIN_SEAMLESS and handling
SPICE_MSGC_MAIN_MIGRATE_CONNECTED_SEAMLESS
The src side signals the client to establish a connection
to the destination.
In seamless migration, the client is also used to perform
a sort of handshake with the destination, for verifying
if
- handle SPICE_MSGC_MAIN_MIGRATE_DST_DO_SEAMLESS
- reply with SPICE_MSG_MAIN_MIGRATE_DST_SEAMLESS_ACK/NACK
- prepare the channels for migration according to the migration
type (semi/seamless)
see spice-protocol for more details:
commit 1ad5d259cb4b695ec3106de7ccd082e031e7ae11
---
In semi-seamless, SPICE_MSG_MAIN_MIGRATE_END is sent.
In seamless, each channel migrates separately.
The src waits till all the clients are disconnected (or a timeout), and
then it notifies qemu that spice migration has completed.
The patch doesn't include the per-channel logic for seamless
---
server/red_channel.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/server/red_channel.c b/server/red_channel.c
index 1cad9eb..a108bc2 100644
--- a/server/red_channel.c
+++ b/server/red_channel.c
@@ -461,6 +461,7 @@ static void
The relevant code is common to all channels.
The patch also contains a fix to the return value for
handle_migrate_data callback: s/uint64_t/int
---
server/inputs_channel.c |3 ++-
server/main_channel.c |5 +++--
server/red_channel.c| 38 ++
Tracking the channels that wait for migration data. If there
is a new migration process pending, when all the channels have
restored their state, we begin the new migration.
---
server/main_channel.c| 11 +++-
server/main_channel.h|3 +-
server/main_dispatcher.c | 32
---
server/reds.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index d53b245..3b53056 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -4111,7 +4111,7 @@ SPICE_GNUC_VISIBLE int
spice_server_migrate_connect(SpiceServer *s, const char*
---
server/migration_protocol.h | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/server/migration_protocol.h b/server/migration_protocol.h
index 2b7f4c2..7a1cb1d 100644
--- a/server/migration_protocol.h
+++ b/server/migration_protocol.h
@@ -31,6 +31,26
When restoring migration data, we also restore data that is addressed to
the device, and that might have been originated from more than 1
message. When the write buffer that is assoicated with this data is
released, we need to free all the relevant tokens.
---
server/char_device.c | 40
---
server/char_device.c | 69 ++
server/char_device.h |5 +++
2 files changed, 74 insertions(+), 0 deletions(-)
diff --git a/server/char_device.c b/server/char_device.c
index 419b7df..84121e6 100644
--- a/server/char_device.c
+++
---
server/char_device.c | 24 +++-
server/char_device.h |3 ++-
server/reds.c| 13 +++--
server/smartcard.c |3 ++-
server/spicevmc.c|3 ++-
5 files changed, 32 insertions(+), 14 deletions(-)
diff --git a/server/char_device.c
---
server/char_device.c | 49 +
server/char_device.h |3 +++
2 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/server/char_device.c b/server/char_device.c
index d97c6dd..b85a24d 100644
--- a/server/char_device.c
+++
The above is the default behaviour for red_channel_client, if
client_cbs.migrate is not registered as part of red_channel_register_client_cbs
---
server/spicevmc.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/server/spicevmc.c b/server/spicevmc.c
index
---
server/spicevmc.c | 60
1 files changed, 55 insertions(+), 5 deletions(-)
diff --git a/server/spicevmc.c b/server/spicevmc.c
index a1092d2..b14ba63 100644
--- a/server/spicevmc.c
+++ b/server/spicevmc.c
@@ -31,6 +31,7 @@
#include
---
server/spicevmc.c | 31 +--
1 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/server/spicevmc.c b/server/spicevmc.c
index b14ba63..1ce3169 100644
--- a/server/spicevmc.c
+++ b/server/spicevmc.c
@@ -206,12 +206,39 @@ static void
Attach/detach a client to a SpiceCharDeviceState upon its
connection/disconnection, instead of upon reader_add/remove messages.
When the client is removed from a SpiceCharDeviceState, all the
messages from this client are removed from the device write queue.
This shouldn't happen when we only
The enum should start from PIPE_ITEM_TYPE_CHANNEL_BASE, otherwise,
PIPE_ITEM_TYPE_ERROR is handled like PIPE_ITEM_TYPE_SET_ACK.
---
server/smartcard.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/server/smartcard.c b/server/smartcard.c
index 44a3fae..bbd6826 100644
The above is the default behaviour for red_channel_client, if
client_cbs.migrate is not registered as part of red_channel_register_client_cbs
---
server/smartcard.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/server/smartcard.c b/server/smartcard.c
index
---
server/migration_protocol.h | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/server/migration_protocol.h b/server/migration_protocol.h
index 127ab0a..67ad1bf 100644
--- a/server/migration_protocol.h
+++ b/server/migration_protocol.h
@@ -62,6 +62,20 @@
---
server/smartcard.c | 56 +++
1 files changed, 51 insertions(+), 5 deletions(-)
diff --git a/server/smartcard.c b/server/smartcard.c
index bc1c6e4..15f5324 100644
--- a/server/smartcard.c
+++ b/server/smartcard.c
@@ -26,6 +26,7 @@
#include
The pipe item is used for sending messages that don't have body.
---
server/red_channel.c | 39 +++
server/red_channel.h |4
2 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/server/red_channel.c b/server/red_channel.c
index
A channel pipe item type must start from PIPE_ITEM_TYPE_CHANNEL_BASE.
SPICE_MSG_MIGRATE value eq. PIPE_ITEM_TYPE_SET_ACK. Setting a pipe item
type to SPICE_MSG_MIGRATE, leads to red_channel handling PIPE_ITEM_TYPE_SET_ACK.
Also removed sending SPICE_MSG_MIGRATE. It will be handled in the next
---
server/migration_protocol.h | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/server/migration_protocol.h b/server/migration_protocol.h
index 67ad1bf..d2a5575 100644
--- a/server/migration_protocol.h
+++ b/server/migration_protocol.h
@@
---
server/reds.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 7e31b18..a31bad9 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -158,7 +158,7 @@ static VDIReadBuf *vdi_port_read_buf_ref(VDIReadBuf *buf);
static void
Before sending the above msg, if there is a pending partial msg that
has been read from the agent, we send it to the client. The alternative
was to keep the msg as part of the migration data, and then
to send it to the destination server via the client and to wait there
for the msg chunk
Also removed some unused definitions from reds that used to belong to
old agent and migration code.
---
server/main_channel.c | 14 +-
server/reds.c | 102 +++-
server/reds.h |2 +-
3 files changed, 95 insertions(+), 23
Also removed old migration leftovers.
---
server/main_channel.c | 34 --
server/main_channel.h | 21 --
server/reds.c | 162 +---
server/reds.h |4 +-
4 files changed, 168 insertions(+), 53 deletions(-)
diff --git
If reading/writing from the device have occured before migration data
has arrived, the migration data might no longer be relvant, and we
disconnect the client.
---
server/char_device.c | 22 ++
server/char_device.h | 14 +++---
server/reds.c| 44
A channel pipe item type must start from PIPE_ITEM_TYPE_CHANNEL_BASE.
SPICE_MSG_MIGRATE value eq. PIPE_ITEM_TYPE_SET_ACK. Setting a pipe item
type to SPICE_MSG_MIGRATE, leads to red_channel handling PIPE_ITEM_TYPE_SET_ACK.
---
server/inputs_channel.c | 24 +++-
1 files
The default callback sends SPICE_MSG_MIGRATE to the client.
---
server/inputs_channel.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/server/inputs_channel.c b/server/inputs_channel.c
index 9f96624..d753bac 100644
--- a/server/inputs_channel.c
+++
---
server/migration_protocol.h | 73 +++
1 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/server/migration_protocol.h b/server/migration_protocol.h
index d2a5575..285d86d 100644
--- a/server/migration_protocol.h
+++
---
server/red_worker.c | 55 ++
1 files changed, 3 insertions(+), 52 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 7c71ba0..9e9908e 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -253,8 +253,6 @@ enum {
---
server/red_worker.c | 52 +-
1 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 9e9908e..d37bbac 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -79,6 +79,7 @@
Restoring display channel from migration data.
Not notifying client about changes that are artifacts of loading the vm.
Remove legacy migration code.
---
server/red_worker.c | 223 ++-
1 files changed, 149 insertions(+), 74 deletions(-)
diff --git
snd channel wasn't added to be part of the client's channels list.
As a result, when the client was destroyed, or migrated, snd channel
client wasn't destroy, or its migration callback wasn't called.
However, due to adding dummy channels to the client, we need special
handling for calls to
Due to the fix in the previous patch, snd_disconnect_channel can be
called both when there is write/read error in the channel, or from
red_client_destroy (which calls client_cbs.disconnect).
Multiple calls to snd_disconnect_channel resulted in calling
channel-cleanup(channel) more than once
The playback and record channel send SPICE_MSG_MIGRATE to the client.
Both playback and record channel does not have a state to restore:
while in the legacy migration implementation the record channel
used to restore the mode and start time, it looks unnecessary since
the client receives from the
The relevant flags reside in RedChannelClient and RedClient
---
server/inputs_channel.c |1 -
server/main_channel.c |2 +-
server/red_channel.c|7 +++
server/red_channel.h|5 ++---
server/red_worker.c |7 +++
server/smartcard.c |1 -
If the server is a destination of seamless migration, send msgs to the client,
even though an init msg has not been sent to the client.
---
server/main_channel.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/server/main_channel.c b/server/main_channel.c
index
---
server/inputs_channel.c | 52 --
1 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/server/inputs_channel.c b/server/inputs_channel.c
index 684dec6..fcf3f82 100644
--- a/server/inputs_channel.c
+++ b/server/inputs_channel.c
@@ -37,6
Pending motion acks, and keyboard modifiers messages will be sent
by the destination after receiving the migration data.
---
server/inputs_channel.c | 30 +-
1 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/server/inputs_channel.c
---
server/main_channel.c |1 +
server/migration_protocol.h |2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/server/main_channel.c b/server/main_channel.c
index 22660f5..0fd5ab6 100644
--- a/server/main_channel.c
+++ b/server/main_channel.c
@@ -1184,6 +1184,7 @@
---
gtk/channel-main.c | 12
spice-common |2 +-
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/gtk/channel-main.c b/gtk/channel-main.c
index 0c15dfa..91c9167 100644
--- a/gtk/channel-main.c
+++ b/gtk/channel-main.c
@@ -163,6 +163,7 @@ static void
Update channel-main as well to support the change made to
SpiceMsgMainMigrationBegin: it now holds all the destination fields
inside SpiceMigrationDstInfo.
---
gtk/channel-main.c |6 +++---
spice-common |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git
Flow:
(1) *src* main channel coroutine (main_handle_migrate_begin_seamless):
handles SPICE_MSG_MAIN_MIGRATE_BEGIN_SEAMLESS; yields to the main loop,
supplying it the destination information needed for connection.
(2) main context (migrate_connect):
Establishes a new session for
In order to save migration time, and probably also decrease migration
data size, we push the flush mark to the src server before any other
message. All the other pending msgs will be sent later to the
destination server (see next patch).
---
gtk/channel-base.c |7 +++
1 files changed, 3
When swapping the src and dest channels's, we need to keep
the xmit_queue and msg serials. Their state is expected to stay the same
after migration.
---
gtk/channel-main.c |4 +++-
gtk/spice-channel-priv.h |2 +-
gtk/spice-channel.c | 12 +++-
gtk/spice-session-priv.h
Otherwise, we will not create smartcard channel on the destination
side, and we will create audio channels, no matter if they existed
of didn't exist for the src side.
---
gtk/spice-session.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/gtk/spice-session.c
On Tue, Aug 14, 2012 at 03:43:14PM -0500, Jeremy White wrote:
ACK.
---
configure.ac |6 +++---
server/reds.c| 14 ++
server/spice-server.syms |4
server/spice.h |1 +
4 files changed, 22 insertions(+), 3 deletions(-)
diff
On Tue, Aug 14, 2012 at 07:14:06PM -0500, Jeremy White wrote:
Hmm. I'm not sure this is complete; in writing the patch for the qxl
driver, I realized I wanted to key off of SPICE_SERVER_VERSION,
which I want to bump to 0x000b02. But then if I do that, how should
I map out spice-server.syms?
mzawdx wang píše v Út 14. 08. 2012 v 23:27 +0800:
Yeah. I think so. For HTML5, en. Is spice-xpi a possible select ?
No, spice-xpi is not a client, it's a browser plugin that launches
standalone client.
There is an ongoing effort for HTML5/JS client, you can browse the
archives here for
Yaniv Kaul wrote:
- Original Message -
Hi Naga,
Tested and reproduced it on Win7.
I bet you'd see this in any many personal FW / Antivirus, to prevent a
malicious software from manipulating it via the mouse (and disable it, for
example).
I'd try with ZoneAlarm
On 08/15/2012 01:05 PM, Arnon Gilboa wrote:
Yaniv Kaul wrote:
- Original Message -
Hi Naga,
Tested and reproduced it on Win7.
I bet you'd see this in any many personal FW / Antivirus, to prevent
a malicious software from manipulating it via the mouse (and disable
it, for example).
Arnon,
I tried //ret = _running = falseearlier and noticed vdagent was not stopped
but had seen mouse tracking offset issue.
I can't stop VDService because VDAgent functionality is mandatory.
As Yaniv suggestion, will it be possible keep running VDAgent and keeping
server mode for such apps?
Add a new arbitrary keyboard scancodes message.
For now, it will be used to avoid unwanted key repeatition when there
is jitter in the network and too much time between DOWN and UP
messages, instead the client will send the press release scancode in
a sequence from a single message.
If the
Add a new arbitrary keyboard scancodes message.
For now, it will be used to avoid unwanted key repeatition when there
is jitter in the network and too much time between DOWN and UP
messages, instead the client will send the press release scancode in
a sequence.
See also:
Handle SPICE_MSGC_INPUTS_KEY_SCANCODE message, allowing arbitrary
keyboard scancode sequence.
---
server/inputs_channel.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/server/inputs_channel.c b/server/inputs_channel.c
index e14e995..8df657e 100644
--- a/server/inputs_channel.c
Factor out the keyboard scancode manipulation function, to be reusable
by newer code.
---
gtk/channel-inputs.c | 22 --
gtk/spice-util-priv.h |1 +
gtk/spice-util.c | 21 +
3 files changed, 26 insertions(+), 18 deletions(-)
diff --git
If the server is capable of SPICE_INPUTS_CAP_SCANCODE, then we send
can send a single message with key press and release, to avoid
unwanted guest side key repeatition due to network jitter.
If the server is not capable, spice-gtk will use some compatibility
mode and send the existing DOWN and UP
- use a more explicit SendKeyType enum
- if the key is a modifier key, we don't want to delay press event
---
gtk/spice-widget.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/gtk/spice-widget.c b/gtk/spice-widget.c
index 2bb7b38..a3369d5 100644
---
The delay before the press event is sent to the server if the key is
kept pressed. If the key is released within that time, that delay is
ignored and a single key-press-release event will be sent.
---
gtk/spice-widget-priv.h |1 +
gtk/spice-widget.c | 27 +++
2
Until now, Spice clients only sent seperate key events for press and
release. But this may result in unwanted key repeatition from guest VM
side. It seems OSes have various implementation. While MS Windows rely
on hardware key repeats (which are several sequential press events),
otoh, X11 uses
On 08/15/2012 11:15 PM, Ricardo Esteves wrote:
Hi,
I logged in to ovirt manager using IE9 (64 bits) and when I click the
console icon of my VM nothing happens.
virt-viewer-0.5.3_x64.exe
http://spice-space.org/download/gtk/windows/virt-viewer-0.5.3_x64.exeis
installed.
There is no firefox
On VMWare Workstation, there is no such problems. I think it is the issue
of QXL driver.
Thanks.
2012/8/15 flooding Controlled flooding2...@gmail.com
Hi all:
I am now using spice now, but stucked by some problems.
My vm is XP, and I can the monitor refresh rate! It is always 100HZ, and
80 matches
Mail list logo
