wnd_proc() is called during ChangeDisplaySettings(), when handling
monitors config. However, calling get_displays() will overwrite the
desired config.
So, while updating from 1 to 4 enabled monitors, when the 2nd monitor
config is enabled, the current config is read, and overwrite the rest of
the config, so first time only 2nd monitor is enabled, second time, 3rd
monitor etc.
https://bugzilla.redhat.com/show_bug.cgi?id=1111144
Do not send clipboard data bigger than last received
VDAgentMaxClipboard.
If a larger amount of data needs to be transferred between client and guest,
a different mechanism should be used, not clipboard.
The spice-protocol git-submodule is updated to include VD_AGENT_MAX_CLIPBOARD
and related definitions.
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.
