vdagent/desktop_layout.cpp:121:763: warning: format '%u' expects
argument of type 'unsigned int', but argument 8 has type
'std::vector<DisplayMode*>::size_type {aka long long unsigned int}'
[-Wformat=]
The _s functions need a recent msvcrt version, not shipped in XP by
default.
Furthermore, it appears that their sscanf_s usage was missing the extra
buffer size argument.
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
0ba6e2936 was trying to fix CreateDC() failing when the monitor is
disabled, unfortunately, enabling monitor with an arbitrary resolution
may still fail (the previous resolution, or the current one).
This patch address the issue by first trying the current resolution, and
falling back to a well-known resolution. This causes a temporary client
resolution change (bad), which is immediately adjusted to the arbitrary
resolution.
We may want to improve agent->driver communication of arbitrary
resolution before the driver is loaded, perhaps using registry or via
the spice server. Any of these solution will unfortunately take some more
time which we are missing.
https://bugzilla.redhat.com/show_bug.cgi?id=922394
(seem to solve related bugs, like mouse offset, or flashing monitors)
(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
Teach vdagent to attach monitors. A monitor needs to be enabled before
we can set the custom resolution. Fortunately, the client doesn't seem
to have time to catch that, so things are smooth.
This is require to allow the virt-viewer display menu to work properly
and enable extra monitors: https://bugzilla.redhat.com/show_bug.cgi?id=919530
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
vdagent terminates when the global event is set by vdservice. vdservice is also
responsible to reset the event in any case, without trusting vdagent to do so.
Otherwise, it may terminate the following vdagent instance immediately as well.
Regression was due to commit 2d03cc.
rhbz #868254
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
Aliasing _ftime_s to _ftime when OLDMSVCRT is defined makes it
possible to remove the timestamp-less implementation of LOG()
while still getting a binary working on Windows XP. I've tested
this with a MinGW build, hopefully this won't break VC++ builds...
vdlog.cpp has an #ifdef check for OLDMSVC to choose between using
swprintf or swprintf_s. Since vdcommon.h provides a compat #define
for swprintf_s when OLDMSVC is set, it's better to use this one.
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().
The problem on XP was failing to terminate agent running on session>0,
since during agent process creation, a handle was not set, so it was NULL.
Therefore, the new agent created (at the session we switched to) was unable
to open vitio-serial which was still used by the other running agent instance.
rhbz#868254
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
