Terminate agent politely instead of ugly TerminateProcess(), so now
VD_AGENT_CLIPBOARD_RELEASE is sent (if guest owned the clipboard),
followed by cleanup.
rhbz #903379
Currently, a SetClipboardData failure is followed by useless wait for timeout
(VD_CLIPBOARD_TIMEOUT_MS).
In addition, we remove the clipboard open-empty-set-close retry, which became
irrelevant with the current on_clipboard_request().
currently:
-handling client disconnect during clipboard data trasfer is buggy
-agent also timeouts on large paste from client (>10sec)
therfore:
-reduce VD_CLIPBOARD_TIMEOUT_MS to 3sec from previous clipboard chunk
-remove _clipboard_event and use _control_event(CONTROL_CLIPBOARD) instead
-use _clipboard_tick for clipboard timeout, updated on each clipboard chunk
-use cleanup_in_msg() to reset incoming message state
rhbz#833835
User Interface Privilege Isolation is usually used only for specific windows of
system security applications (anti-viruses etc.), so with this patch mouse will
be irresponsive for these windows but keep working for the rest. A complete
solution might be switching to server mouse mode while the agent is still active.
This is only part of the message corruption solution.
The other part is fixing virtio-serial / spice-qemu-char throttling code.
-replace write_[lock/unlock/completion] calls with [new/enqueue]_message
-remove clipboard specific _out_msg_* class members
-remove ugly loop - while (a->_out_msg && a->write_clipboard());
-add _message_mutex for message queue
-fix pending_write race using _write_mutex
-TODO: enqueue large message without dividing it to chunks in advance
rhbz #846427
Waiting for a Windows event will not last if it is already set.
For example, the client may send clipboard_release() messages
while we are not waiting in on_clipboard_request(), and this will
SetEvent(clipboard_event)
The following clipboard request will thus not wait for the data,
resulting in an empty clipboard & paste for the guest application.
We could say there is fundamentally a race as there is no obvious
way to know if a received message is related to the current request,
but by reseting the event before waiting for new events to come, we
at least clear the past events.
The convention in vdagent codebase seems to put a space before
the opening parenthesis in initialization list, this commit fixes
2 inconsistencies related to that.
VDAgent::_mouse_x and VDAgent::_mouse_y are both signed but are
always assigned values from VDAgentMouseState which are unsigned.
gcc warns about this so change them to unsigned values.
Given that all clipboard handling is async, it is possible to for
example receive a request for clipboard data from the client
while the agent no longer owns the clipboard (ie a
VD_AGENT_CLIPBOARD_RELEASE message is in transit to the client).
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.(citing hansg)
clean ups: capability checks, return values
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.(citing hansg)
-enable the clipboard support
-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)
-bonus (no cost): support image cut & paste, currently only with win client
The configuration is received from Spice client.
The main usage of this option is for disabling display features in order to accelerate Spice performance over limited network connections.
