| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Also Update server and client according to the change of
SpiceMsgMainMigrationBegin: it now holds all the fields inside
SpiceMigrationDstInfo.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch will replace the common/ directory with the spice-common
project. It is for now a simple project subdirectory shared with
spice-gtk, but the goal is to make it a proper library later on.
With this change, the spice-server build is broken. The following
commits fix the build, and have been seperated to ease the review.
v2
- moves all the generated marshallers to spice-common library
- don't attempt to fix windows VS build, which should somehow be
splitted with spice-common (or built from tarball only to avoid
generation tools/libs deps)
v3
- uses libspice-common-client
- fix a mutex.h inclusion reported by Alon
|
| |
|
|
|
|
| |
Remove any blank lines at the end of all source files
|
| |
|
|
|
|
|
|
|
|
| |
protocols.
It can't actually happen right now, since switch-host migration scheme will take
place if the src/target server has protocol 1.
(cherry picked from commit 4b2bf4d88c253502003aa5e4b93a045742eec9b4 branch 0.8)
|
|
|
|
|
|
|
| |
Implement on_disconnect_mig_src and on_connect_mig_target in order to avoid
unnecessary cleanups done in on_(disconnet|connect).
In addition, do not request guest display settings changes after migration.
(cherry picked from commit f91d202eb3bf631cf5e70277d1aabffec7da9393 branch 0.8)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(1) disconnect all channels from the migration src
(2) after all channels are disconnected, clean global resources
(3) send SPICE_MSGC_MAIN_MIGRATE_END to migration target
(4) wait for SPICE_MSG_MAIN_INIT
(4) switch all channels to migration target
(cherry picked from commit 510a4ff7c4f188fe6d0fb12198b8f9fdb74b9a2d branch 0.8)
Conflicts:
client/red_channel.h
|
|
|
|
|
|
|
|
|
| |
RHBZ 725009, 738270
(cherry picked from commit 31ed2519a752b7332ed40d0d7ab02e938c0e65cb branch 0.8)
Conflicts:
client/red_client.cpp
|
|
|
|
|
|
| |
Even if VDAgentDisplayConfig::depth will be unused if the
VD_AGENT_DISPLAY_CONFIG_FLAG_SET_COLOR_DEPTH isn't set, it's
better to initialize it anyway to avoid warnings from valgrind.
|
|
|
|
|
|
| |
3f8d7e59dbd94b1837503f37b5065698df3ffbc7 introduced a regression, after
sending one attach_channels message we never send another one.
Fix by resetting on disconnect.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changelog from Arnon Gilboa, patch from me:
Commit eb6f55409412 caused the following regression:
When client runs without the auto-conf or disable-effects options
(either from CLI or controller), which is the case when using Spice
from Admin Portal, the client will unecessarily wait for 30sec before
connecting to a Windows guest with an agent running (this won't happen
with linux guests or without an agent running).
The mentioned patch assumed that on_agent_reply() of
VD_AGENT_DISPLAY_CONFIG will call send_main_attach_channels() and
connect. However, when auto-conf or disable-effects are not used,
on_agent_reply() will ignore the reply and not call
send_main_attach_channels(). Therefore, send_main_attach_channels()
will only be called on agent timeout.
The solution is to activate agent timer only if auto-conf or
disable-effects. Otherwise, simply call send_main_attach_channels().
Fixes rhbz #726441
|
|
|
|
|
|
|
|
|
|
| |
When the client connects to a spice VM, if an agent is detected,
there will be a few messages exchanged to exchange capabilities,
display resolutions, ... This exchange has a timeout in case
something goes wrong. However, when it fires, the client dies.
This commit changes this and lets the client connects to the
guest when the timeout happens.
rhbz #673973
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
492f7a9b fixed unwanted timeouts during initial client startup,
but it also caused a bad regression when connecting to
RHEL6+agent guests: the SPICE_MSGS_MAIN_ATTACH_CHANNELS message
was sent multiple times, once in RedClient::handle_init, then
once again in RedClient::on_agent_announce_capabilities (which
can even be triggered multiple times). Sending this message multiple
times is a big NO and causes the server to close the client connection,
and the client to die. Add a _msg_attach_message_sent boolean to
make sure we only send this message once.
rhbz #712938
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you try to connect to a linux guest with WAN options, SPICE window opens up
and is blank - it then fails with vdagent timeout message. It should give a
warning that this is only applicable for windows guest and still connect to
guest.
It all starts in RedClient::handle_init
This function checks whether we have an agent or not, because if we have an
agent, there will be some kind of handshake to check both sides capabilities
before all the spice channels are created.
When there is no agent running, the startup process goes on with
SPICE_MSGC_MAIN_ATTACH_CHANNELS
When there is a windows agent running, VD_AGENT_ANNOUNCE_CAPABILITIES and
VD_AGENT_DISPLAY_CONFIG messages are sent to the agent, and when processing the
agent answer to the VD_AGENT_DISPLAY_CONFIG message,
SPICE_MSGC_MAIN_ATTACH_CHANNELS will be sent and the startup process will go
on.
However, when there is no agent running but --color-depth was used, handle_init
won't send the SPICE_MSGC_MAIN_ATTACH_CHANNELS message but will wait for the
agent handshake to proceed to its end, which won't happen, so it will timeout
waiting for agent answers.
Similarly, the linux agent handles VD_AGENT_ANNOUNCE_CAPABILITIES messages, but
it doesn't handle VD_AGENT_DISPLAY_CONFIG messages, so we'll never reach the
point where a SPICE_MSGC_MAIN_ATTACH_CHANNELS will be sent.
This commit fixes this in 2 places:
- unconditionnally send SPICE_MSGC_ATTACH_CHANNELS when no agent is running in
handle_init
- send SPICE_MSGC_MAIN_ATTACH_CHANNELS in
RedClient::on_agent_announce_capabilities if the agent doesn't have the
VD_AGENT_CAP_DISPLAY_CONFIG capability
This fixes RH bug #712938
|
|
|
|
|
|
|
| |
Fixed since v1:
- don't include C code, rather use the common lib
- add missing spice_openssl_verify_free() call
- keep the extra-parsing of subject for error reporting
|
|
|
|
| |
This is more explicit about what it does, and not much longer
|
|
|
|
|
|
|
|
| |
When using config.h, it must be the very first include in all source
files since it contains #define that may change the compilation process
(eg libc structure layout changes when it's used to enable large file
support on 32 bit x86 archs). This commit adds it at the beginning
of all .c and .cpp files
|
|
|
|
|
|
|
| |
For not too old spice-migration, minor is 1.
For older (ancient) spice-migration, minor is 0.
Affects only VM migration while a spice client is connected.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
|
|
| |
which is useful when calling RedClient::on_clipboard_notify(VD_AGENT_CLIPBOARD_NONE, NULL, 0);
|
|
|
|
|
|
|
|
|
|
|
| |
Currenty, we check the agent caps in RedClient::handle_agent_connected
for VD_AGENT_CAP_DISPLAY_CONFIG and if present send display_config, but at
this time we have not received the caps yet, so remove this.
Also the send_agent_display_config call in on_agent_announce_capabilities
lacks a check for _agent_disp_config_sent, and we send the display config
before announcing that we may do so by sending our own caps, which seems
inpolite.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this patch spicec reproducely hangs in
GlzDecoderWindow::pre_decode_update_window().
When GlzDecoderWindow::will_overflow() returns true,
GlzDecoderWindow::pre_decode_update_window(),
waits for a call to GlzDecoderWindow::post_decode()
to free up some memory
This happens even though there still is pci memory
available (otherwise the driver would not have
been able to send an image to decode in the first
place).
The GlzDecoderWindow::post_decode() call never happens
as the server is waiting for a reply to the decode
of the hanging image, causing the client to hang
for ever.
This patch fixes this by simply removing the
"attempted" pci memory accounting. As there is no
need for that, as the driver already must keep
track of pci memory usage.
I've verified that both the old and new Xorg drivers
take care of not overusing the pci memory themselves
I would expect the same to be true for the windows
driver.
Note the calculating of the glz_window_size in
red_client.cpp cannot be removed as the calculated
value is send as part of the SpiceMsgcDisplayInit on
connect.
|
| |
|
|
|
|
|
|
|
|
| |
ClipboardListener callbacks can run from another thread then the
main channel loop thread, where agent messages are normally dispatched from.
So they may not send agent messages directly, instead they should post
events to the main channel loop.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Atleast under x11 there is a race condition when setting the clipboard
owner to guest from the RedClient code rather then doing it in Platform.
After the XSetSelectionOwner() in Platform::on_clipboard_grab(), which runs
from the main message loop thread, the x11 event thread can receive a
SelectionRequest event from another x11 app, before the RedClient code
has set the clipboard owner, which will trigger the owner != guest
check in the SelectionRequest event handling code.
By moving the setting of the owner in to Platform::on_clipboard_grab() it
gets protected by the clipboard lock, which closes this tiny race.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make sure we process the XFixesSetSelectionOwnerNotify event caused by
us setting the clipboard owner to none, directly after setting the owner
to none. Otherwise we may end up changing the clipboard owner to none, after
it has already been re-owned because the XFixesSetSelectionOwnerNotify event
to owner none is event is still pending when we set the new owner, and
then changes the owner back to none once processed messing up our clipboard
ownership state tracking.
I saw this happening when doing copy twice in succession inside the guest.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Given that all clipboard handling is async, it is possible to for
example receive a request for clipboard data from the agent
while the client no longer owns the clipboard (ie a
VD_AGENT_CLIPBOARD_RELEASE message is in transit to the agent).
Thus it is necessary to keep track of our notion of clipboard ownership
and check received clipboard messages (both from other apps on the client
machine and from the agent) to see if they match our notion and if not
drop, or in case were a counter message is expected nack the clipboard
message.
|
|
|
|
|
|
|
|
|
|
| |
Rename the 4 platform clipboard functions which get called
upon receival of an agent clipboard message to on_clipboard_*
The old set_clipboard_* names were confusing as they suggest being
a class property setter (like set_event_listener) rather then
event handler, and set_clipboard_owner was causing a name conflict
with the next patch in this series.
|
|
|
|
|
|
|
|
|
|
| |
This way the events will always get generated and other things
(such as clipboard ownership administration, see the next patches)
can be done in repsonse to the events, even though no message will be send.
This patch also removes the !_agent_caps check from the capability
checks, this is not needed as VD_AGENT_HAS_CAPABILITY checks _agent_caps_size
which will be 0 when _agent_caps is NULL.
|
|
|
|
|
|
|
|
|
| |
Currently we send a VD_AGENT_CLIPBOARD_RELEASE when we receive a
VD_AGENT_CLIPBOARD_REQUEST with a type which we do not support. This is not
correct, as this means given up clipboard ownership while we may be able
to answer requests with different types. The correct response is to
nack the request by sending a VD_AGENT_CLIPBOARD (data) message with a type
of VD_AGENT_CLIPBOARD_NONE.
|
|
|
|
|
|
|
| |
A clipboard owner can indicate that it can supply the data the clipboard
owns in multiple formats, so make the data passed with a
VD_AGENT_CLIPBOARD_GRAB message an array of types rather then a single
type.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-includes most of Hans' review fixes (up to the SelectionRequest comment [4]) & X11 wips sent by Hans (10x!)
-use the VD_AGENT_CLIPBOARD_* types in the platform code
-add ifs for VD_AGENT_CAP_CLIPBOARD_BY_DEMAND in both sides
-support the GRAB/REQUEST/DATA/RELEASE verbs in both ways
-pasting clipboard data is now "only-by-demand" from both sides (client and agent), whose behavior is symmetric
-client and agent don't read or send the contents of the clipboard unnecessarily (e.g. copy, internal paste, repeating paste, focus change)
-set client as clipboard listener instead of application
-add atexit(cleanup) in win platform
linux:
-instead of clipboard atom selection instead of XA_PRIMARY
-enable USE_XRANDR_1_2 and support clipboard in MultyMonScreen
-send utf8 with no null termination, remove ++size
-add xfixes in configure.ac & Makefile.am
windows:
-bonus: support image cut & paste, currently only on windows
not done yet:
-clipboards formats are still uint32_t, not mime types stores as strings
-platform_win is still used, not the root window
-not replaced the ugly windows CF_DIB in agent/winclient
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove all uses of @end in the marshaller, instead just using
the C struct array-at-end-of-struct. To make this work we also remove
all use of @end for switches (making them C unions).
We drop the zero member of the notify message so that we can avoid this
use of @end for a primitive in the marshaller (plus its useless to send
over the wire).
We change the offsets and stuff in the migration messages to real pointers.
|
|
|
|
|
|
|
|
| |
* windows - untested
* linux - small strings both ways, large implemented differently:
* client to guest - support INCR
* guest to client - we supply a single possibly very large property
* requires server changes in next patch to work with spice-vmc
|
|
|
|
| |
color depth and disabling some display options (helpful on WAN)
|
|
|
|
|
|
|
| |
Protocol is 0 (auto), 1 (old), or 2 (new). This is (apart from 0) the
same as the major number for the stable protocol. However, the current major
is ~(-1) to signify it being unstable, so don't use the major number as source
for setting or comparing protocol.
|
| |
|
|
|
|
| |
This is required to support multiple versions
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a message has been read from the network we now pass it into
the generated demarshaller for the channel. The demarshaller converts
the network data to in-memory structures that is passed on to the
spice internals.
Additionally it also:
* Converts endianness
* Validates sizes of message and any pointers in it
* Localizes offsets (converts them to pointers)
* Checks for zero offsets in messages where they are not supported
Some of this was previously done using custom code in the client, this
is now removed.
|
| |
|
|
|
|
| |
disconnecting from the current host and connecting to the target host.
|