Previously, when a client disconnects, the vdagent executable exited.
The agent was restarted immediately in order to be ready for the next
client to reconnect.
This is generally fine, but there are certain situations
where it causes issues. For example, if client A is connected to a guest
and client B connects to the same guest, client A will be forcibly
disconnected and causes the the vdagent to restart. This scenario is
racy because the agent can take some time to exit and restart. Client B
may think that the agent is connected at startup and may send agent
messages to the guest. At some point the server will recieve
notification that the agent has exited and send an AGENT_DISCONNECTED
message to client B. After the agent has been fully restarted, an
AGENT_CONNECTED message will be sent to the client, but any messages
sent between client connection and the AGENT_DISCONNECTED message will
be lost. This causes problems especially with fullscreen mode in
virt-viewer.
The solution is to not exit and restart the agent when a client
disconnects. This is how the linux vdagent behaves. Instead, we simply
cancel all ongoing file transfers and reset the clipboard when a client
is disconnected.
Fixes: rhbz#1064495
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Make clipboard_formats and image_types static and constant.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This patch updates the display configurations only when needed.
Currently vdagent updates the display configurations almost on every
"VD_AGENT_MONITORS_CONFIG" request, this approach is redundant as some
"VD_AGENT_MONITORS_CONFIG" requests don't apply any change to the
display configurations.
A good example of why this is needed, is the 'resize-guest' feature of
the spice-widget which when enabled causes the client to send periodic
"VD_AGENT_MONITORS_CONFIG" requests in order to resize the guest even
when no change is required. Prior to this patch the screen would
periodically flicker when using Virt-manager or Spicy due to this issue.
Signed-off-by: Sameeh Jubran <sameeh@daynix.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
As _stop_event is not mandatory, we are initializing the events array
with something that might be NULL. The problem is with the following
patch as I'm introducing a new non mandatory event and logic starts to
get a bit hard to follow.
So this patch makes explicit if we are setting or receiving a
_stop_event or not and uses an auxiliary enum and array 'actions' to
work around this non mandatory events and the return value of
MsgWaitForMultipleObjectsEx()
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
>From WTSRegisterSessionNotification() we are aware of session changes
(WM_WTSSESSION_CHANGE) such as Lock/Unlock events.
We can use that to disable features such as drag-and-drop.
Tested on: Windows 7, Windows XP
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1323628
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Mouse coordinates can be 0..(width-1) and 0..(height-1)
Normalization of mouse coordinates (for SendInput) was done
against w,h and thus right-most and down-most coordinates
could never be reached.
Fix it by normalizing against (w-1) and (h-1).
Also added protection against a case of 0 or 1 (for any of w,h)
Fixes rhbz#1032037
If the client hasn't been updated to handle multi-monitor configurations
that are not multi-head, vd_agent won't issue the MONITORS_CONFIG driver
escape.
These changes will ensure that the new MONITORS_CONFIG escape in commit:
6023630562 will not break with an older
client.
This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1248196
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
