The Windows MSI product version is restricted to a 3 component
version number, whose fields are a max value of 255.255.65536
Since the main virt-viewer version takes up 3 components already,
we have the munge the micro version together with the first
component of the release version. eg we have
$VERSION[0].$VERSION[1].($VERSION[2] << 8 + $RELEASE[0])
This causes problems for RHEL which needs to have 2-component
release versions to deal with z-stream builds. eg a RHEL
version might be virt-viewer-0.5.6-2.el6_4.3 and we've
no easy way of adding the final '.3' to the Windows product
version.
If we reduce the primary virt-viewer version to just 2 components,
then we can leave the 3rd component for exclusive use by the RPM
release number. eg so we'd make product version up using
$VERSION[0].$VERSION[1].($RELEASE[0] << 8 + $RELEASE[1])
In course of normal development, we'd increase the $VERSION[0]
for each release. ie next release is 1.0, then 2.0, then 3.0.
This means we retain the ability to put out "stable" branch
releases for any historical version by doing 1.1, 1.2 instead
of having to re-add a 3rd component.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
You can reproduce the error by starting the client in kiosk and shuting
down the guest.
#0 0x000000317e432915 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x000000317e4340f5 in abort () at abort.c:92
#2 0x000000317fc4a98a in g_logv (log_domain=0x318730e657 "Gtk",
log_level=<value optimized out>, format=
0x31873a50a8 "A floating object was finalized. This means that
someone\ncalled g_object_unref() on an object that had only a
floating\nreference; the initial floating reference is not owned by
anyone\nand must be remo"..., args1=0x7fffffffd5f0)
at gmessages.c:557
#3 0x000000317fc4aa23 in g_log (log_domain=<value optimized out>,
log_level=<value optimized out>,
format=<value optimized out>) at gmessages.c:577
#4 0x000000318717ba72 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#5 0x0000000000426eb5 in
virt_viewer_display_spice_finalize (obj=0x6fec20
[VirtViewerDisplaySpice])
at virt-viewer-display-spice.c:67
#6 0x0000003180c106a4 in g_object_unref (_object=0x6fec20) at
gobject.c:2712
#7 0x0000000000425b5d in destroy_display (data=0x6fec20) at
virt-viewer-session-spice.c:596
#8 0x000000317fc1667b in g_ptr_array_foreach (array=0x74a040,
func=0x425ae7 <destroy_display>, user_data=0x0)
at garray.c:1306
#9 0x000000317fc16e7b in g_ptr_array_free (farray=0x74a040,
free_segment=1) at garray.c:938
#10 0x000000317fc2906a in g_data_set_internal (datalist=<value optimized
out>, key_id=1297, data=0x0, destroy_func=0)
at gdataset.c:351
#11 g_datalist_id_set_data_full (datalist=<value optimized out>,
key_id=1297, data=0x0, destroy_func=0) at gdataset.c:598
#12 0x00000000004268d0 in
virt_viewer_session_spice_channel_destroy (s=0x800000 [SpiceSession],
channel=
This unref doesn't seem to be related to any reference, although it
was probably introduced in the first place to clear the floating ref,
wrongly. See following commit for a working solution.
rhbz#1104064 had a couple of symptoms. The first was fixed in
6edde57862.
The second symptom is that displays could also become tiny when clicking 'View >
Zoom > Normal Size'. This was because VirtViewerDisplay returned early from
_display_set_zoom_level() if the zoom level was being set to the current zoom
setting. However, the calling function (_window_set_zoom_level()) also tries to
queue a resize event for itself after setting the zoom level on the display. If
the display doesn't queue a resize event for itself, its size request will only
be 50x50 during the window resize negotiation. This causes the display to become
tiny and zoomed out. Queueing a resize on the display widget ensures that it
will request the proper size during the next allocation.
When enabling a new display on linux guests, the new window would be tiny
(50x50) and zoomed way out. This was caused by the fact that when the display
widget received the 'map' event, it unconditionally cleared the 'dirty' flag,
which meant that it would only request 50x50 size. This behavior was intended to
fix a bug on the windows client which wprevented windows from resized smaller
than the guest display resolution. Unfortunately, due to the timing of the 'map'
and allocate events, the widget became very small.
Instead of clearing the 'dirty' flag directly when a widget is mapped, we
now queue a resize event, which will guarantee that the widget attains its
desired size and will then clear its dirty flag (allowing it to be resized).
Testing on windows indicates that this fix still solves the 'unshrinkable
window' problem while also preventing the tiny secondary display bug.
Resolves: rhbz#1104064
Some display have no associated window (for ex, if it doesn't fit
on client monitors).
(remote-viewer:22275): remote-viewer-CRITICAL **: virt_viewer_window_set_display: assertion `VIRT_VIEWER_IS_WINDOW(self)' failed
(remote-viewer:22275): remote-viewer-CRITICAL **: virt_viewer_app_remove_nth_window: assertion `win != NULL' failed
https://bugzilla.redhat.com/show_bug.cgi?id=1107518
Trying to connect to a remote virtual machine using
virt-viewer -c qemu+ssh://example.com/system --direct $vm_name
will currently fail with an error message saying it's not possible to
localhost. This happens with VMs which listen on a wildcard address (eg
'0.0.0.0').
This was introduced by commit 74b1b62 which changes the host to connect to
to 'localhost' when trying to connect through ssh to a VM listening on a
wildcard address. This is only valid when using a ssh tunnel, and should
not be done with --direct. The fallback code which uses the hostname from
the libvirt URI is what makes the most sense in this situation (wildcard
listen address + --direct).
This commit introduces a virt_viewer_app_get_direct() so that this can be
implemented.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1079211
Coverity warns that 'type' can sometimes be used or free after already having
been freed. This can happen when open_recent_dialog is true and we jump back up
to the retry_dialog label. To prevent this, make sure the freed variables are
set to NULL after freeing.
Previous commit accidentally broke gtk2 build by using
gtk_widget_get_preferred_size(). We can't simply use gtk_widget_size_request()
for the gtk2 build since this will generally return 50x50 whenever we're not in
the middle of a resize, so we need to add a compatibility function.
When using the --with-buildid configure paramater, the build id which is
substituted in the MSI wxs file is automatically prepended by a '-', but
the build id which is used in the C files does not get this '-'
automatically.
Currently, the linux and mingw spec files prepend a '-' on their own to the
--with-buildid argument, but this causes the MSI installer to show 2 '-'
during installation: "Please wait while Windows configures VirtViewer
0.6.0--1"
This commit always prepends a '-' to the buildid strings, and removes the
'-' from the spec files. This is to ensure the separator between version
number and buildid is not forgotten, which could give a confusing version
number.
Commit 8fa942 broke enabling of additional displays. We don't want to send down
display re-configurations due to events that happen while setting up windows for
enabled displays that we recieve from the server. However, by ignoring
allocations on unmapped windows, we fail to send display configurations for new
displays that a user is attempting to enable via the window menu. To
discriminate between these two cases, we check whether the display is in the
'ready' state or not.
- Unmapped displays with the 'ready' hint set can be assumed to be displays
that are enabled on the server that we are attempting to create windows for on
the client. In this case, we should *not* send a display configuration to the
server
- Unmapped displays with the 'ready' hint cleared can be assumed to be displays
that are not yet enabled on the server that we are trying to enable in the
client. In this case, we *should* send a display configuration to the server
Due to spice-gtk-0.23 missing SPICE_GTK_CHECK_VERSION macro, the
condition:
causes the following error:
virt-viewer-session-spice.c: In function 'virt_viewer_session_spice_main_channel_event':
virt-viewer-session-spice.c:525:64: error: missing binary operator before token "("
#if defined(SPICE_GTK_CHECK_VERSION) && SPICE_GTK_CHECK_VERSION(0, 23, 21)
^
Also one more warning is fixed in this patch:
virt-viewer-session-spice.c:476:19: warning: unused variable 'error'
[-Wunused-variable] const GError *error;
^
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
In some situation, (for example, guest without vdagent running), it's
possible to pass key combinations to virt-viewer. When using alt+f4,
this can cause the 'do you want to quit?' dialog to show while it's
non-functional.
This commit moves the check for kiosk mode to before we show this dialog.
When the --hotkeys option is given, all hotkeys that are not explicitly
specified are disabled. The method used to disable hotkeys is to change the
accel map entry to key=0, mods=0. However, when we decide whether to set a grab
sequence on the spice dispay widget, we simply use the return value for
gtk_accel_map_lookup_entry and assume that a TRUE value returned from this
function means that the hotkey is enabled. In reality, this function will
return TRUE for disabled hotkeys, but the 'key' variable will be set to key=0,
mods=0. The result is that if I start virt-viewer like this:
virt-viewer --hotkeys secure-attention=ctrl+alt+end ...
and the guest that I'm attached to uses server mouse mode, it will be impossible
to release the grab on the spice widget. Because we will explicitly disable the
grab keys in the spice widget and handle the 'release-cursor' hotkey in
virt-viewer, but the hotkey is an empty accel key.
Instead of simply checking the return value of gtk_accel_map_lookup_entry, we
have to inspect the return value for 'key' and check whether any keys are
actually assigned.
virt_viewer_app_set_kiosk creates a new window at startup for each client
monitor (regardless of whether the guest supports more than one display). This
seems unnecessary. Only do this if kiosk mode is actually enabled.
virt_viewer_app_get_nth_window() will return the proper window when passed 0 for
the 'nth' argument, so there's no need to avoid calling it in this case. It
just complicates the code logic.
When the zoom level is changed, the virt-viewer window gets resized. But we
don't want this to trigger a resize of the guest display. But occasionally
rounding errors cause the guest display to be reconfigured when zooming out. To
fix this, we first check whether the current size is the preferred size. If it
is, we don't send down a resize command to the guest.
In addition to preventing guest resizes in response to zooming, it also improves
the behavior when the guest display resolution is changed from within the guest.
Before this change, we'd have the following behavior:
A. guest changes display to WxH
B. client gets notified of change and resizes the window to WxH
C. client responds to window resize by sending a new monitor config command to the guest
With this change, the extra step C will be avoided because we're already at the
preferred size.
Resolves: rhbz#1004051
The code to determine scaling of windows was incorrectly
using the original desktop size instead of the host screen
size. The 128 pixel fudge factor was also causing windows
to be scaled when there was no need for them to be.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
When the zoom level is changed, the virt-viewer window gets resized. But we
don't want this to trigger a resize of the guest display. But occasionally
rounding errors cause the guest display to be reconfigured when zooming out. To
fix this, we first check whether the current size is the preferred size. If it
is, we don't send down a resize command to the guest.
In addition to preventing guest resizes in response to zooming, it also improves
the behavior when the guest display resolution is changed from within the guest.
Before this change, we'd have the following behavior:
A. guest changes display to WxH
B. client gets notified of change and resizes the window to WxH
C. client responds to window resize by sending a new monitor config command to the guest
With this change, the extra step C will be avoided because we're already at the
preferred size.
Resolves: rhbz#1004051
People seem to have a hard time understanding the --attach flag.
Rewrite the docs in the hope that people figure it out this time.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
deactivate() is called in response to a failed authentication attempt. If the
session is cleared here, when a user attempts to re-authenticate, it will issue
a warning and will not actually work. So only clear the session here if we're
not going to re-try authentication.
We were setting the show_hint to READY as soon as we got the vnc-connected
signal. But there may be an authentication step between vnc-connected and
vnc-initialized. In this case, we switch to an empty black display during the
authentication step instead of showing the 'waiting for display N' status.
