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 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.
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.
Allow top_down flag to have any value, only ASSERT it is positive
when needs to be positive and zero otherwise. Allows older server
bug of sending 4 instead of 1 in top down flag to not affect newer
clients (previous patch fixes server).
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
drawable_count was becoming negative. It tracks the number of
items in the worker->current_list ring. It was decremented correctly,
but incremented only in several cases. The cases it wasn't incremented
where:
red_current_add_equal found an equivalent drawable
by moving the increment to where the item is added to current_list, in
__current_add_drawable, the accounting remains correct.
This has no affect other then correct accounting, as drawable_count isn't
used for anything.
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.
Currently when compiled with the gui enabled if you specify a host to connect
to on the cmdline the gui flashes by (show_gui gets called, then the connect
handler calls hide_gui as soon as the connection is made).
This patch removes this ugly flashing by of the gui.
Currently we are calling show_info_layer from hide_gui in application.cpp, but
there are 2 cases where this does not happen:
1) When compiled without gui support hide_gui is a complete nop, so we never
show the info layer when compiled without gui support
2) When run with --controller we never show the gui, and hide_gui
checks if there is a gui to hide as the first thing and if not returns
resulting in show_info_layer not being called, and thus the info layer
not showing when launched from the xpi
This patch fixes both by adding a call to show_info_layer from
on_visibility_start note that on_visibility_start also calls hide_gui,
so in some cases show_info_layer may be called twice, this is not a
problem as show_info_layer is protected against this.
We are making all text send over the controller socket utf-8, rather then
having somethings as 8 bit (hostname) and others (title, menu) unicode16,
this patch completes this change by converting the menu handling.
The activex browser plugin is sending unicode16 text, where as the
xpi one is sending utf8 text. After discussing this on irc we've decided
that utf8 is what we want to use. So the client (this patch), and the
activex will be changed to expect resp. send utf8 text as the title.
The socket name used to communicate between the xpi browser plugin and the
spicec was predictable allowing a non priviliged user on the same system
to create the socket before spicec does and thus intercept the messages from
the xpi to the client, including login credentials. This security vulnerability
has been registred with mitre as CVE-2010-2792:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2792
This patch changes the controller code to instead read the socket name
from an environment variable which gets set by the xpi before executing
the spicec, making the socketname private between the client and the xpi.
Note that this means that the controller will only work with an xpi which
has matching changes, the changes are present in the latest version of the
xpi as available as update for / with RHEL-5.5 and RHEL-6.0 .
Now that Application::hide_me actually does what the name suggests
(hide the entire client, ie all client windows), the gui using it to
not show the gui layer leads to the entire client disappearing when
one presses close in the GUI or dismisses a GUI dialog. This patch makes
the GUI code call hide_gui instead of hide_me, fixing this.
There were 2 issues with window management under KDE
1) When an app does its own focus management like we do, kwin expects
an explicit raise for the app to get to the top, so we did have focus,
but would have other windows (partially) covering the client window
-> do a raise after setting focus to ourselves
2) When switching from fullscreen <-> window, we unmap and remap our
window, then set focus to ourselves. kwin thinks this means we're trying
to steal the focus without the user asking for it. This patch makes us
set the _NET_WM_USER_TIME property on our window, this helps kwin's
focus stealing code to see that we are really not stealing the focus,
just responding to a user event.
1) Make the order when starting up in fullscreen mode the same as when
switching from window -> fullscreen:
First set the mode, then make the window fullscreen
2) Change the order when leaving fullscreen mode, first restore the original
monitor mode, then make the window non fullscreen. Changing the monitor
mode in X11 causes the window manager to re-arrange windows, and if this
happens while compiz is busy mapping the window it gets confused and
maps the window with a maxmimized size.
Some window managers will ignore the fullscreen hint, unless WmSizeHints
allow them to resize the window so that they can give it the size of
the roo-window. This fixes fullscreen mode in compiz.
XRRSet* calls wait for a XReply, so add a missing XLockDisplay,
this fixes a hang (due to a race so not always) when switching between
windowed and fullscreen mode.
