Having a loglevel variable is much more useful if we can actually change
its value without a recompile. Use a SPICEC_LOG_LEVEL environment variable so
we can do this from the spice xpi / activex too (by setting the environment
variable before starting the browser).
After shift+F11, both in Windows 7 and xp clients, WM_KEYUP events were missing for
SHIFT and F11. For F11 it was less important since unpress_all was preformed for all keys.
However, we perform sync for all the keyboard modifiers and the GetKeyboardState returns "down" for shift.
In windows7 client, we sometimes received afterwards a F11 KEYDOWN event repetition, and this caused SHIFT+F11 to be called again.
Not performing hiding of the windows while changing client resolutions, solved the problem of missing events, and I don't see any difference
in how spice looks while toggling to full screen.
Using GetAsyncKeyState, returns "UP" for shift in windows 7, and helps avoid performing shift+f11 again, if there is an F11 repetition
before we receive the KEYUP event for shift.
Video streams from Linux guests are oriented top-down, where gdi_canvas_put_image always
received display context for down-top oriented bitmap. I fixed create_bitmap
to consider the stream orientation.
This fixes fdo bug #32896:
"Subject in certificates is stored in following format (values separated by
comma and space):
grep Subject: server-cert.pem | awk -F": " '{print $2}'
O=REDHAT, CN=10.34.58.2
While spicec expects that values in host subject are separated only by comma:
spicec --host-subject "O=REDHAT,CN=10.34.58.2"
"
In this case, ignoring spaces make it much easier to directly copy and paste
the subject line from certificates.
Although ICCCM 2.2. Responsibilities of the Selection Owner:
http://tronche.com/gui/x/icccm/sec-2.html#s-2.2
Clearly states (about selection notify events):
The owner should set the specified selection, target, time, and property
arguments to the values received in the SelectionRequest event.
xsel sets the selection notify event target member to the incr atom when it
is going to send the clipboard data incremental, rather then setting it to
the UTF8_STRING atom (which was the target of the SelectionRequest).
Work around this (esp as it is likely other programs may get this wrong too)
and accept the incr atom as a valid target in a selection notify event.
This fixes Alon's test with running:
python -c "print list(range(1000))" | xsel -i -b
on the client.
Some apps (bad xsel, bad!) send invalid Atoms in their TARGETS property,
causing spicec to exit because of an XError. This patch makes spicec survive
this scenario.
For more info on the xsel bug, see:
https://bugzilla.redhat.com/show_bug.cgi?id=690214
In some cases rhev-m changes the hotkey for releasing the mouse grab
to ctrl + alt. This makes it impossible to send ctrl + alt + other-key
to the guest, even when using sticky alt.
What happens is:
-press alt until sticky alt activates
-release alt (but recorded state stays pressed due to sticky alt)
-press ctrl
-hotkey code sees ctrl+alt pressed, releases mouse grab
-mouse grab release code does an unpress all -> end of sticky state.
This patch makes it possible to atleast send ctrl + alt + del (or other key)
using sticky alt. Note: even with this patch it is still a bad idea to
use ctrl + alt as hotkey combi.
This avoids us trying to restore the original resolution when we're fullscreen
and an X error happens. As restoring fullscreen is a bad idea then as this
involves making more X calls, which can get us stuck (in side an XLockDisplay
call for example).
uses VSC_Error with code==VSC_SUCCESS instead. This means that the VSC_Error
message is overloaded. Instead of the other option of adding a message id,
since the connection is TCP so no messages may be dropped or reordered, by
having each message followed by a response there is no ambiguity. Still
this commit adds a queue for messages that we only have one of which outstanding
at a time, i.e. send, wait for response, send the next, etc. This further
simplifies the logic, while not adding much overhead since only when spicec
starts up it has a situation where it needs to send two events (ReaderAdd
and ATR for Card Insert).
This patch stops us from drawing the spice client watermark at the top of
the virtual machine view. We have had requests through several channels to
remove this as it has little added value, and is seen as annoying by some.
Given that we now also have a bugzilla for this I think it is time we really
remove it.
(cherry picked from commit 392ed65dda)
For not too old spice-migration, minor is 1.
For older (ancient) spice-migration, minor is 0.
Affects only VM migration while a spice client is connected.
separate initialization into before command line parsing and after,
call later only if command line parsing succeeds (in particular, it
"fails" if --help is given).
We could introduce another boolean to prevent changes, or just reuse
_active_modifiers_event = true to prevent further update.
Additionaly this patch restore the keyboard state when focusing out,
which is fine when dealing with full remote desktop, but should be
reconsidered if/when SPICE supports remote windows managed by client
window manager for instance, imho.
We use get_opt_long, which allows non ambiguous abbreviations, but
since we didn't like that we have code that checks for abbreviations and
issues an error. But that code only handled separate argument and key like:
--bla value
and didn't handle them in the same arguemnts, like:
--bla=value
This patch fixes that, and gives a slightly better error report (it still
contains the =value part though)
The problem is that RedWindow::show calls the XLib MoveWindow function
on the window after it has been mapped, moving it to the location in
_show_pos. This is seen by the window manager as the application saying
I know exactly where I want my window to be placed, don't do placing for
me. Which causes the client window to always be shown at pos 0x0, even
though that may not be the best location.
What this patch does is:
1) It makes RedWindow::show not call MoveWindow when a window is
first created normally and then shown
2) It makes RedWindow::show still call MoveWindow when:
-when the window has been shown before, and was hidden for some
reason (controller interface), and is now being re-shown
so that it ends up being re-shown at its old position
-when the window is a fullscreen window (screen.cpp always
calls move on the window before showing it to set its position)
-when the user switch from windowed mode -> fullscreen ->
windowed mode again, to make sure that the windowed mode window
is shown in the same position as before switching to fullscreen
mode
If connect_unsecure failed due to protocol version mismatch, don't try to
connect_secure with the same version, but retry (connect_secure or
connect_unsecure) with older version. catch (...) is handled by caller
at RedChannel::run().
This solves the following bug: when "new" Spice client (protocol version 2)
with given secure_port connects to "old" server which is not using the same
secure_port (or not using a secure_port at all), the client exits immediately.
In this scenario, the client first tries to use Spice protocol version 2 to
connect the unsecure port, and altough this fails due to version mismatch, it
tries to connect to the secure port with the same protocol version 2, which is
a wrong behavior, fails due to socket error 10061 (WSAECONNREFUSED -
Connection refused) and handled mistakenly by immediate exit, instead of
retrying with protocol version 1.
Currently when going / starting fullscreen if the guest resolution for one of
the monitors is higher then that monitor on the client can handle, we show a
white screen. Leaving the user stuck (unless they know the fullscreen key
switch combi) with a white screen when starting the client fullscreen from
the XPI.
This patch changes the client to fall back to windowed mode in this case
instead.
When XIM + ibus is in use XIM creates an invisible window for its own
purposes, we sometimes get a _GTK_LOAD_ICONTHEMES ClientMessage event on
this window. Since this window was not explicitly created by spicec, it
does not have a Window Context (with the event handling function for the
window in question) set. This would cause spicec to throw an unhandled
exception and exit.
This patch replaces the exception throwing with silently ignoring
ClientMessage events on Windows without a Context and logging a warning
for other event types.
Currently modifier keys (ctrl, alt) can get stuck when using the x11 client.
To reproduce under gnome:
-focus the client window without causing it to grab the keyborad (click on
the title bar not the window)
-press crlt + alt + right arrow to switch virtual desktop
-press crlt + alt + left arrow to switch back
-notice ctrl + alt are stuck pressed
What is happening here is:
-We get a focus out event, caused by the hotkey combi key grab, focus event
notify mode == NotifyGrab, and release all keys -> good
-We get another focus out event, as we really loose the focus.
notify mode == NotifyWhileGrabbed, which we ignore as we already lost
focus before
-We get a focus in event, as the focus is returning to us, but we don't
really have the focus yet, as the hotkey combi key grab is still active
(ie ctrl + alt are still pressed).
We now sync the vm's modifier key state with the current X-server state,
telling the vm ctrl + alt are pressed. Note we do this by directly reading
the X-server keyboard status, we are not getting any key press events from the
X-server -> bad
-We get another focus in event, as we really get the focus back,
notify mode == NotifyUngrab. We ignore this one as already have gained the
focus before. If we were to sync the vm modifier state here, all would be
well we would no longer see the modifier keys pressed, or if we would we
would get a release event when they get released (testing has shown both).
The solution here is to ignore the first focus in event, and do the modifier
sync on the second focus in event, or more in general to ignore focus events
where notify mode == NotifyWhileGrabbed.
