This change broke primary clipboard copying from remote to client, on win32.
There is a pending ::clipboard-grab emission, so the channel is not
idle, and it will handle emission and resume in the inner loop without
issue. We should really handle this situation with care though, and the
best would be to teach gtk+ to do async clipboard request.
This reverts commit e3efa8cec5.
The main channel must be idle to avoid entering the nested loop,
or it will never reach the condition to leave it.
This should not happen. It can happen currently when the remote sends a
clipboard request while the clipboard is grabbed by the remote. In this
case, while the clipboard-request signal is emitted by main channel, the
clipboard_get() loop is entered, but the main coroutine will not be
woken up to proceed with the request, the main channel will remain
"frozen" and it won't be possible to leave cleanly from the inner loop.
The application appears to be frozen, because it can't quit properly.
Related to:
https://bugzilla.redhat.com/show_bug.cgi?id=1083489
When destroying the primary surface, we need to signal it, since
listeners might be referencing the data pointer. Currently, this only
happens during channel finalize().
This could help with rhbz#1082555.
The channel state is not synchronous.
It may happen that we want to set and unset quickly a modifier, but the
guest modifier state hasn't been updated yet, and will still be seen as
unset, preventing the last unset change.
There are gtk+ version checks in several source files to add
compatibility implementations of gtk3 functions not available
in gtk2. This commit gathers all of them in a gtk-compat.h header,
similar to what is done for glib-compat.h
This fixes this warning/error:
channel-webdav.c: In function 'demux_to_client':
channel-webdav.c:318:5: error: format '%ld' expects argument of type 'long
int', but argument 5 has type 'gssize' [-Werror=format=]
CHANNEL_DEBUG(self, "pushing %ld to client %p", size, client);
Connect to the GdkKeymap::state-changed signal to detect when the client
keyboard modifiers have changed. This keeps the client and the guest in sync
even when the SpiceDisplay widget isn't focused. New values are only sent down
to the guest if the new value is different than the current value.
In certain circumstances, the keyboard modifiers get out-of-sync between the
guest and the client. This is easy to reproduce with the following steps:
- launch virt-viewer with a guest that is not running
- start the guest
- while guest is booting, enable CAPS LOCK on the client
- after guest finishes booting, it will set its modifiers to a default value
(e.g. numlock on, capslock off)
- now capslock is OFF in the guest, but ON in the client
- toggle caps lock
- now capslock is ON in the guest, but OFF in the client
This moves the responsibility for synchronizing client and guest modifiers into
SpiceGtkSession. It can't be handled easily within the SpiceDisplay widget since
there can be multiple display widgets for each inputs channel.
A new function (spice_gtk_session_sync_keyboard_modifiers()) was added so that
synchronization can be triggered manually if desired. But it also registers a
signal handler for the InputsChannel::inputs-modifiers signal to detect when the
guest has changed its modifiers. The signal handler simply overrides the guests
modifiers and sets them back to the value from the client.
configure.ac tries to assign a default value of 0 to the micro version if it's
empty, but the shell variable assignemnt doesn't work because there's whitespace
around the '=' sign.
This results in SPICE_GTK_MICRO_VERSION being defined to (), which causes a
compilation failure in files that include it.
A client setting this capability indicates to the server that it's able
to handle SASL authentication, and it also indicates that if SASL is
to be used for authentication, then it won't expect a valid 'pub_key' field
in SpiceLinkReply.
The reason for making guarantees about not looking at the pub_key field is
that its presence and size is hardcoded in the protocol, but in some
hardened setups (using fips mode), generating a RSA 1024 bit key as
expected is forbidden and fails. With this new capability, the server
knows the client will be able to handle SASL if needed, and can skip
the generation of the key altogether. This means that on the setups
described above, SASL authentication has to be used.
See spice-common for protocol details. phodav, a webdav server library,
is imported thanks to a submodule, until this project has a stable API
and releases.
The webdav channel is reponsible for handling port events and
multiplexing the request streams. Extra care has been made to avoid
blocking and to enable some fairness between concurrent streams, however
this has been particularly tricky and is likely to have some issues
left.
The webdav server is run in a seperate thread, using libsoup. The client
communication is done via a local tcp socket, but protected to only
accept local connection and with a pretty strong password.
The home directory is exported for the remote to browse, which seems to
be a sensible default atm.
When building with mingw64, several warnings about using the wrong format
specifier for gssize/gsize occur similar to:
win-usb-dev.c: In function 'g_udev_client_list_devices':
win-usb-dev.c:145:21: error: format '%i' expects argument of type 'int', but argument 7 has type 'gssize' [-Werror=format=]
name, errstr, rc);
This commit makes use of the G_GSIZE_FORMAT/G_GSSIZE_FORMAT macros provided
by glib to silence these warnings.
I've checked that this does not introduce new warnings on linux and mingw32
builds.
Fix screenshot of secondary displays, with an area position != (0,0).
This has never been working correctly since the surface display "area"
was introducted in:
commit e3bb7b1cfd
Author: Marc-André Lureau <marcandre.lureau@redhat.com>
Date: Tue Jun 12 19:24:47 2012 +0200
display: learn to restrict display to an area
https://bugzilla.redhat.com/show_bug.cgi?id=1029761
cc1: warnings being treated as errors
spice-uri.c: In function ‘spice_uri_parse’:
spice-uri.c:105: error: ‘saveptr’ may be used uninitialized in this
function [-Wuninitialized]
spice-uri.c:105: error: ‘saveptr2’ may be used uninitialized in this
function [-Wuninitialized]
While looking at the SASL code, I noticed some memory leaks in error paths.
This commit adds a cleanup: block to free some of the memory dynamically
allocated in that function, and remove the corresponding g_free() from
the regular code flow. This should ensure that both the regular path
and the error paths free the same memory.
This fixes at least this 'mechlist' leak which I got during regular SASL
PLAIN authentication:
==3452== 6 bytes in 1 blocks are definitely lost in loss record 140 of 11,706
==3452== at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.s
==3452== by 0x35BAC4EE6E: g_malloc (gmem.c:104)
==3452== by 0x5BF7CAA: spice_channel_perform_auth_sasl (spice-channel.c:1440)
==3452== by 0x5BF9033: spice_channel_recv_link_msg (spice-channel.c:1727)
==3452== by 0x5BFAECD: spice_channel_coroutine (spice-channel.c:2348)
==3452== by 0x5C35D6D: coroutine_trampoline (coroutine_ucontext.c:63)
==3452== by 0x5C35A1B: continuation_trampoline (continuation.c:51)
==3452== by 0x31342479BF: ??? (in /usr/lib64/libc-2.18.so)
==3452== by 0x75F2940591224CFF: ???
==3452== by 0xE756E5F: ???
==3452== by 0xE7589BF: ???
==3452== by 0xFFEFFF78F: ???
==3452== by 0x5BFCD92: g_io_wait_helper (gio-coroutine.c:43)
=
This is recommended by autoconf documentation
http://nondot.org/sabre/Mirrored/autoconf-2.12/autoconf_3.html#SEC15
and some #defines in config.h can change what happens in system headers,
so config.h has to be included first.
The only file which does not get this treatment is
gtk/spice-client-gtk-module.c as this breaks the build on gtk+2:
CC SpiceClientGtk_la-spice-client-gtk-module.lo
In file included from /usr/include/python2.7/pyconfig.h:6:0,
from /usr/include/python2.7/Python.h:8,
from /usr/include/pygtk-2.0/pygobject.h:5,
from spice-client-gtk-module.c:20:
/usr/include/python2.7/pyconfig-64.h:1182:0: error: "_POSIX_C_SOURCE" redefined [-Werror]
#define _POSIX_C_SOURCE 200112L
^
In file included from /usr/include/limits.h:25:0,
from /usr/lib/gcc/x86_64-redhat-linux/4.8.2/include/limits.h:168,
from /usr/lib/gcc/x86_64-redhat-linux/4.8.2/include/syslimits.h:7,
from /usr/lib/gcc/x86_64-redhat-linux/4.8.2/include/limits.h:34,
from /usr/lib64/glib-2.0/include/glibconfig.h:11,
from /usr/include/glib-2.0/glib/gtypes.h:34,
from /usr/include/glib-2.0/glib/galloca.h:34,
from /usr/include/glib-2.0/glib.h:32,
from /usr/include/glib-2.0/gobject/gbinding.h:30,
from /usr/include/glib-2.0/glib-object.h:25,
from ./glib-compat.h:24,
from ../config.h:201,
from spice-client-gtk-module.c:18:
/usr/include/features.h:228:0: note: this is the location of the previous definition
# define _POSIX_C_SOURCE 200809L
^
cc1: all warnings being treated as errors
After e124a3b2e which added the SPICE_GTK_CHECK_VERSION macro, a non-fatal
'./configure: line 15251: x24: command not found' appears in configure
output. This is because [ ] is not interpreted as the 'test' command by
autoconf, but is rather used as a way to quote configure.ac content.
This commit replaces the use of [] with a more typical AS_IF.
wocky-http-proxy.c and vmcstream.c make use of functions that were
not available in glib 2.26 so we need fallback for them through
glib-compat.h or spice-gtk won't build with older glibs.
Since 1fcaaa15f8, display_surface is
allocated using gslice. However MSG_DISPLAY_MODE handler didn't allocate
using GSlice. This can eventually lead to a crash when freeing, such as:
Thread no. 1 (6 frames)
#2 g_slice_free1 at gslice.c:1097
#3 iter_remove_or_steal at ghash.c:787
#4 clear_surfaces at /lib64/libspice-client-glib-2.0.so.8
#5 spice_display_channel_finalize at
/lib64/libspice-client-glib-2.0.so.8
#7 spice_channel_delayed_unref at /lib64/libspice-client-glib-2.0.so.8
#12 gtk_main at gtkmain.c:1158
https://bugzilla.redhat.com/show_bug.cgi?id=1069546
Although reusing BIO_new_socket() once again is a hack, it seems
to be the easiest way... The proper solution is certainly to start
using GTls instead, but that will require a glib 2.28 dep bump.
