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.
Currenty, we check the agent caps in RedClient::handle_agent_connected
for VD_AGENT_CAP_DISPLAY_CONFIG and if present send display_config, but at
this time we have not received the caps yet, so remove this.
Also the send_agent_display_config call in on_agent_announce_capabilities
lacks a check for _agent_disp_config_sent, and we send the display config
before announcing that we may do so by sending our own caps, which seems
inpolite.
Spice client controller enables external control (e.g., by XPI or ActiveX) of
the client functionality.
The controller protocol enables setting parameters (host, port, sport, pwd,
secure channels, disabled channels, title, menus, hotkeys etc.), connecting
the server, showing and hiding the client etc.
The controller is based on the cross-platform named pipe.
Spice foreign menu enables external control of the client menu.
The foreignmenu protocol enables an external application to:
add a submenu, set its title, clear it, add/modify/remove an item etc.
Foreign menu is based on the cross-platform named pipe.
We are keeping track of tokens for sending agent data to the client, but
the client send an initial value of ~0, and never gives us new send tokens
so this is all rather useless -> remove it.
Note that it is kept in the migration data struct for compatibility reasons.
read_from_vdi_port(), called from vdagent_char_device_wakeup() may
fail to consume all data because no buffers are available in the
read_bufs ring. When this happens we would fail to ever read more data
from the agent on the guest as the port is throttled and stays throttled
until we've consumed all data from the current buffer.
This patch re-enables the call to read_from_vdi_port() from
vdi_read_buf_release(), so that we will try the read again when space
becomes available in the read_bufs ring.
Together with another nasty hack in the linux guest virtio_console
driver, where it waits for a write to be acked by the host before
continuing with the next one, this can lead to a linux guest
getting stuck / hang (until the write is read by the spice-server
which never happens becaus of the above issues).
Note that even with this patch, the guest will still gets stuck due to
a bug in watch_update_mask in spice-core in qemu, which causes writing
to the client to never resume once it blocked. A patch for this has been
submitted to qemu.
read_from_vdi_port() MUST always be called in a while loop until it returns 0.
This is needed because it can cause new data available events and its
recursion protection causes those to get lost. Calling it until it returns 0
ensures that all data has been consumed.
Example scenario where we can fail to read the available data otherwise:
- server/reds.c: vdagent_char_device_wakeup get called
by hw/spice-vmc.c because data has arrived from the guest,
- hw/spice-vmc.c: vmc_read get calls
- If the vmc_read call depletes the current buffer it calls
virtio_serial_throttle_port(&svc->port, false)
- This causes vmc_have_data to get called, which if in the
mean time another buffer has arrived causes
vdagent_char_device_wakeup to gets called again
(so recursively)
- vdagent_char_device_wakeup is protected against recursive
calling and ignores the second call (a nasty hack)
- if no other data arrives, the arrived data will not get read
The use of epoll in the client is totally overkill in terms of
scalability, and its a problem for portability. The OSX port converts
this to use select, but keeps some of the old complexities in the code.
This new patch makes it simpler and look much more like the windows
code.
This patch adds a channel event callback to the spice core interface.
This new callback will be called for three events:
(1) A new connection has been established.
(2) The channel is ready (i.e. authentication is done,
link message verification passed all tests, channel
is ready to use).
(3) Channel was disconnected.
Qemu will use this to send notifications to the management app.
Since libX11-1.3.4 the multi-threading handling code of libX11 has been
changed, see:
http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=933aee1d5c53b0cc7d608011a29188b594c8d70b
This causes several issues. One of them is the display inside the
client not getting updated when there are no XEvents being generated,
this is caused by the following part of the referenced commit message:
Caveats:
- If one thread is waiting for events and another thread tries to read a reply,
both will hang until an event arrives. Previously, if this happened it might
work sometimes, but otherwise would trigger either an assertion failure or
a permanent hang.
We were depending on the otherwise behavior and apparently were lucky.
This can be seen by starting F14 in runlevel 3 and then doing startx
and not touching the mouse / keyb afterwards. Once you move the mouse
(generate an event you see the UI contents being updated but not before.
Another thing both I and Alon (iirc) have seen are hangs where 2
threads are stuck in XSync waiting for a reply simultaneously. This might
be related to libxcb version, according to the libX11 commit a libxcb
newer then 1.6 was needed, and my system had 1.5 at the time I saw this
after updating to libxcb 1.7 I can no longer reproduce.
This patch tackles both problems (and is needed for the 1st one
indepently of the 2nd one possibly being fixed) by adding XLockDisplay
calls around all libX11 calls which wait for a reply or an event.
Without this patch spicec reproducely hangs in
GlzDecoderWindow::pre_decode_update_window().
When GlzDecoderWindow::will_overflow() returns true,
GlzDecoderWindow::pre_decode_update_window(),
waits for a call to GlzDecoderWindow::post_decode()
to free up some memory
This happens even though there still is pci memory
available (otherwise the driver would not have
been able to send an image to decode in the first
place).
The GlzDecoderWindow::post_decode() call never happens
as the server is waiting for a reply to the decode
of the hanging image, causing the client to hang
for ever.
This patch fixes this by simply removing the
"attempted" pci memory accounting. As there is no
need for that, as the driver already must keep
track of pci memory usage.
I've verified that both the old and new Xorg drivers
take care of not overusing the pci memory themselves
I would expect the same to be true for the windows
driver.
Note the calculating of the glz_window_size in
red_client.cpp cannot be removed as the calculated
value is send as part of the SpiceMsgcDisplayInit on
connect.
Every time an events comes past where the Window is None (which happens
about once every 5 minutes or so), this annoying "invalid window" message
gets printed. Remove it!
ClipboardListener callbacks can run from another thread then the
main channel loop thread, where agent messages are normally dispatched from.
So they may not send agent messages directly, instead they should post
events to the main channel loop.
Well almost remove it, it was possible that another x11 app would acquire
selection ownership, and we would receive a release message from the
agent before having processed the xselection ownership change event.
Then we would set the selection owner to none, overriding the new owner.
As the comment in the patch indicates there still is a minute window left
where something similar can happen after this patch. Nothing we can do
about that (I blame the libX11 selection API).
