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
I changed RedScreen::resize not to call rearrange_monitors. Instead,
the monitor should be configured correctly from Application, before
calling resize.
In addition, I made some cleanups to allow reusing rearrange_monitors code.
Both connect_secure() and connect_unsecure() call connect_to_peer().
Prior to this commit spicec.log reported all connections as unsecure,
as connect_secure() called connect_unsecure() to make the connection.
This fixes RH bug #653545
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
The WAN options (--color-depth and --disable-effects) need
support from the guest agent to be working. Currently they are
only supported on Windows. While I don't want to explicitly
mention Windows in --help output, we can hint that it won't
work with all guests in --help. This fixes RH bug #712941
There is a double free in client/x11/platform.cpp.
In get_selection(), in the exit: case with ret_val == -1 and data != NULL,
*data_ret (which is returned to the caller) has already been
assigned "data", so it will be pointing to freed memory when "data" is
XFree'd'. Then in handle_selection_notify, get_selection_free is called on
this pointer, which causes a double free.
When the length of the read data = 0, set the returned value to NULL,
this way subsequent free attempts will be a noop.
Fixes RH bug #710461
Enable image randomized base address, hindering some types of
security attacks by making it more difficult for an attacker
to predict target addresses.
Commit 774e5bd36f changed
- dest->source.pixmap.x_image->data +
+ (uint8_t *)pixman_image_get_stride(dest->source.pixmap.pixman_image) +
The correct accessor to use is pixman_image_get_data. Thanks to gcc
4.6 for warning about a "different size" int to pointer conversion.
The server Makefile.am rules for marshallers generation are
prefixed with AM_V_SILENT to integrate nicely with automake silent
rules. The same AM_V_SILENT prefix isn't used in client/Makefile.am
resulting in verbose output even when automake silent mode is
enabled. This commit removes this verbosity.
When OpenGL is enabled, build fails in DisplayChannel::create_surface
because Canvas *canvas is declared twice. Remove the first
declaration to fix compilation.
instead of ..\..\..\spice-protocol. Relative path to another git tree is a bit
ugly, since it requires spice-protocol to be in a specific location.
SPICE_PROTOCOL_DIR should also be used in windows qxl and vdagent instead of
SPICE_COMMON_DIR, which is an old and confusing name, due to the common
directory in spice git repo.
Having a loglevel variable is much more useful if we can actually change
its value without a recompile. Use a SPICEC_LOG_LEVEL environment variable so
we can do this from the spice xpi / activex too (by setting the environment
variable before starting the browser).
After shift+F11, both in Windows 7 and xp clients, WM_KEYUP events were missing for
SHIFT and F11. For F11 it was less important since unpress_all was preformed for all keys.
However, we perform sync for all the keyboard modifiers and the GetKeyboardState returns "down" for shift.
In windows7 client, we sometimes received afterwards a F11 KEYDOWN event repetition, and this caused SHIFT+F11 to be called again.
Not performing hiding of the windows while changing client resolutions, solved the problem of missing events, and I don't see any difference
in how spice looks while toggling to full screen.
Using GetAsyncKeyState, returns "UP" for shift in windows 7, and helps avoid performing shift+f11 again, if there is an F11 repetition
before we receive the KEYUP event for shift.
Video streams from Linux guests are oriented top-down, where gdi_canvas_put_image always
received display context for down-top oriented bitmap. I fixed create_bitmap
to consider the stream orientation.
This fixes fdo bug #32896:
"Subject in certificates is stored in following format (values separated by
comma and space):
grep Subject: server-cert.pem | awk -F": " '{print $2}'
O=REDHAT, CN=10.34.58.2
While spicec expects that values in host subject are separated only by comma:
spicec --host-subject "O=REDHAT,CN=10.34.58.2"
"
In this case, ignoring spaces make it much easier to directly copy and paste
the subject line from certificates.
Although ICCCM 2.2. Responsibilities of the Selection Owner:
http://tronche.com/gui/x/icccm/sec-2.html#s-2.2
Clearly states (about selection notify events):
The owner should set the specified selection, target, time, and property
arguments to the values received in the SelectionRequest event.
xsel sets the selection notify event target member to the incr atom when it
is going to send the clipboard data incremental, rather then setting it to
the UTF8_STRING atom (which was the target of the SelectionRequest).
Work around this (esp as it is likely other programs may get this wrong too)
and accept the incr atom as a valid target in a selection notify event.
This fixes Alon's test with running:
python -c "print list(range(1000))" | xsel -i -b
on the client.
Some apps (bad xsel, bad!) send invalid Atoms in their TARGETS property,
causing spicec to exit because of an XError. This patch makes spicec survive
this scenario.
For more info on the xsel bug, see:
https://bugzilla.redhat.com/show_bug.cgi?id=690214
In some cases rhev-m changes the hotkey for releasing the mouse grab
to ctrl + alt. This makes it impossible to send ctrl + alt + other-key
to the guest, even when using sticky alt.
What happens is:
-press alt until sticky alt activates
-release alt (but recorded state stays pressed due to sticky alt)
-press ctrl
-hotkey code sees ctrl+alt pressed, releases mouse grab
-mouse grab release code does an unpress all -> end of sticky state.
This patch makes it possible to atleast send ctrl + alt + del (or other key)
using sticky alt. Note: even with this patch it is still a bad idea to
use ctrl + alt as hotkey combi.
This avoids us trying to restore the original resolution when we're fullscreen
and an X error happens. As restoring fullscreen is a bad idea then as this
involves making more X calls, which can get us stuck (in side an XLockDisplay
call for example).
uses VSC_Error with code==VSC_SUCCESS instead. This means that the VSC_Error
message is overloaded. Instead of the other option of adding a message id,
since the connection is TCP so no messages may be dropped or reordered, by
having each message followed by a response there is no ambiguity. Still
this commit adds a queue for messages that we only have one of which outstanding
at a time, i.e. send, wait for response, send the next, etc. This further
simplifies the logic, while not adding much overhead since only when spicec
starts up it has a situation where it needs to send two events (ReaderAdd
and ATR for Card Insert).
This patch stops us from drawing the spice client watermark at the top of
the virtual machine view. We have had requests through several channels to
remove this as it has little added value, and is seen as annoying by some.
Given that we now also have a bugzilla for this I think it is time we really
remove it.
(cherry picked from commit 392ed65dda)
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.
separate initialization into before command line parsing and after,
call later only if command line parsing succeeds (in particular, it
"fails" if --help is given).
