This patch make it easier to spot warnings in compilation. It should
work with older versions of automake that don't support silent rules.
If you want verbose build, make V=1.
Signed-off-by: Uri Lublin <uril@redhat.com>
https://bugs.freedesktop.org/show_bug.cgi?id=34795
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).
This patch adds symbol versions to the spice server library. Each
symbol which is exported by libspice-server gets tagged with the
(stable) version where it appeared first. This way the linker and rpm
are able to figure which version of the spice-server libary is required
by a particular qemu binary/package.
[ 0.8 branch: drop 0.10 symbols from list ]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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.
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 of a successful re-add of the agent interface .
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.
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.
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.
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 clipboard
release from the client), then this data should be written to the guest agent.
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 an inconsistent state, and lots
of printing of "dispatch_vdi_port_data: invalid port" messages caused
by this inconsistent state sometimes followed by a segfault.
This can be triggered by copy and pasting something large (say
a screenshot) from the guest to the spice-gtk client, as the spice-gtk
client currently has a bug causing it to crash when receiving a multi
chunk vdagent messages. Without this patch (and with the spice-gtk bug
present) I can consistently reproduce this.
2) It clears any buffered writes from the client to the guest still pending
because the virtio port cannot consume data fast enough. Since the agent
itself is still running fine, throwing away writes for it because the
client has disconnected makes no sense. Esp, since on clean exit the
client may very well send a clipboard release message directly
before closing the connection, and this may get lost this way.
3) It sets client_agent_started to false, this is the only thing which
actually makes sense to do on client disconnect.
Note that since we no longer reset the vdp state on client disconnect, we
must now reset it on agent disconnect even if we don't have a client. So
the reds_reset_vdp call in reds_agent_remove() gets moved to the top,
above both the agent_state.connected and reds->peer checks which will
both fail in the no client case.
Also bump SPICE_SERVER_VERSION to 0x000801 as 0.8.1 will be the
first version with the new API for this, and we need to be able to
detect the presence of this API in qemu.
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.
The current assert(reds->agent_state.connected) tiggers if when
the agent disconnected there was still data waiting to be sent (for
instance if there is a bug in the client handling clipboard and it
is killed while a large clipboard transfer is in progress). So first
call to reds_agent_remove happens from spice_server_char_device_remove_interface,
and then it is called again (triggering the assert) from free_item_data
from read_from_vdi_port because of the channel destruction.
Other option would be to not call it from one of the paths - but that
is suboptimal:
* if there is no data in the pipe, the second call never happens.
* the second call has to be there anyway, because it may fail during
parsing data from the agent.
This patch fixes a segfault on this assert when a client starts passing
from guest agent to client a large clipboard and dies in the middle. There
is still another assert happening occasionally at marshaller which I don't
have a fix for (but it doesn't seem to be related).
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).
spice-server tries to use the migration information without checking
whenever this is available in the first place ...
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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).
The device already sends one. There are actually two connections going
on:
server to client - this is the smartcard channel, it reuses the VSC protocol.
server to device - this is an internal connection using VSC too.
We generally just passthrough all messages from the client to the device,
and from the device to the client. We only rewrite the reader_id because
the device knows about a single id (it is actually a card id), and we
may manage more then one in the future.
Bottom line is that there was an extra VSC_Error message reaching the client.
