vdagent/vdagent.cpp: In member function 'void
VDAgent::on_clipboard_grab()':
vdagent/vdagent.cpp:951:52: warning: suggest parentheses around
assignment used as truth value [-Wparentheses]
rhbz#958051
It may be that a _displays entry will be NULL.
I encountered it when running with multiple QXL devices, for one of
which the driver failed to load since it was "out of resources".
Iterations over _displays should handle that case.
We found four such iterations, and fixed them in this patch.
vdagent is stopped, so a new instance is to be launched by vdservice.
imho, this seems simpler than cleaning agent in/out msg state and
reseting the vio-serial device to cleanup pending msgs.
rhbz #956133
(Win7 class includes Win8/Vista/Server2012/Server2008/R2)
This new api was introduced in Vista/2K8 to keep track of clipboard changes,
without the need to trust the (mis)behavior of other applications registered
to the clipboard.
If the issue is reproduced on XP as well, it can be hacked by a periodic call
to ChangeClipboardChain & SetClipboardViewer as described in
http://social.msdn.microsoft.com/Forums/en-US/csharplanguage/thread/
521183dc-7872-472e-8104-8c0d75b1bf53
rhbz #919451
CxImage DIB to PNG encoding seems to ignore pallete in some scenarios.
This issue happens when copying a png from FireFox, but with IE it's ok.
rhbz #919150
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)
