Setting the zoom-level using the command line option '--zoom' is not
working for vnc guests. This problem can be solved by emitting
the "display-desktop-resize" signal when vnc is initialized.
https://bugzilla.redhat.com/show_bug.cgi?id=1170071
SpiceSession in spice-gtk v0.27 will remove channels from session during
disconnect (and not when they are actually disposed). When no channels
are left, session-disconnected is emitted, and the VirtViewerSession
will be unref from the application. Use a weak reference to self to
avoid crashing after calling spice_session_disconnect()
As a workaround for existing clients, spice-gtk v0.27 will defer the
disconnection to idle time. But the fix still makes sense and would
prevent potentially future issues if spice-gtk changes back to sync
disconnection.
(the alternative of calling ref/unref would needlessly recreate a
SpiceSession with a call to create_spice_session(), which is something
we can avoid when leaving the application)
- do not overwrite err if ->initial_connect() sets it
- remove need for waitvm if the display server isn't yet started (note:
this function might be untested, I am not sure relying on libvirt events
is enough)
- remove need for waitvm if the display server isn't yet started (note:
this function might be untested, I am not sure relying on libvirt events
is enough)
Some refactoring to make the code easier to read, mostly code
movement/reindenting and introduction of a "wait" label which has the
same purpose as "done".
This also adds a "goto wait" within an if block, but this does not
change the initial code flow, just makes it more explicit.
This error type isn't really an error, it is used to skip error report
code. The functions can simply return FALSE on failure, without GError
set, to indicate that program should quit normally.
This isn't required, but makes it easier to track reference issues, as
you have guarantee that callbacks won't be executed if the objects are
disposed.
It's currently possible to destroy any virt-viewer window, including the
main window. However, some part of the code expects that the main window
is always present, for example to present status messages.
In particular, stopping the guest (or running virsh destroy) will close
all windows: virt_viewer_session_clear_displays will get called, which
will call into virt_viewer_app_remove_display_removed, and finally into
virt_viewer_app_remove_nth_window, which will destroy the window being
removed if it holds the last reference to it.
So going through virt_viewer_session_clear_displays, all
VirtViewerWindow instances and their corresponding GtkWindow have been
destroyed. This is already an issue as VirtViewerApp::main_window will
be pointing to freed memory.
When using virt-viewer --reconnect, this will cause a crash when
restarting the guest in virt_viewer_app_create_session as it tries to
get a valid GtkWindow through:
GtkWindow *window = virt_viewer_window_get_window(priv->main_window);
This commit avoids this issue by special casing the main window in
virt_viewer_app_remove_nth_window to ensure it never gets removed.
This is similar to what is done in virt_viewer_app_hide_all_windows.
Commit 13f493200 changed virt_viewer_app_initial_connect to return a
gboolean rather than an int, but one call site was not updated to the
new convention, and was still checking for a negative value rather than
for FALSE in order to detect failures.
As spice-gtk macro for checking the version numbers was broken, let's
check for 0.26 and avoid to have virt-viewer broken on a few distros
for a good long time.
This causes warnings with older compilers
virt-viewer-vm-connection.c:52: warning: declaration of 'select' shadows
a global declaration
/usr/include/sys/select.h:109: warning: shadowed declaration is here
The G_N_ELEMENTS() type is size_t but this was being passed to
a format string with '%lu' which is of a different size on many
platforms. Just delete this part of the warning message since
it was not hugely useful.
virt_viewer_session_on_monitor_geometry_changed() gets called
immediately upon agent connection, but sometimes this is before any
displays have been received. Simply return early when this is the case.
When using a custom fullscreen display configuration, it's possible to
specify that e.g. a single screen should be fullscreen on client
monitor #4. Since we send down absolute positions and disable alignment
when all windows are in fullscreen, we can send configurations with a
very large offset to the top-left corner. This could result in the guest
trying to create a screen that was much larger than necessary. For
example when sending a configuration of 1280x1024+4240+0, the guest
would need to allocate a screen of size 5520x1024, which might fail if
video memory was too low. To avoid this issue, we shift all displays
so that the minimum X coordinate for all screens is at x=0, and the
minimum y coordinate is at y=0.
We have to check for the spice version where the
SPICE_CLIENT_ERROR_AUTH_NEEDS_PASSWORD_AND_USERNAME was introduced and
not for the one where spice_channel_get_error() was introduced.
The function app_window_try_fullscreen() will lookup the initial monitor
for the nth monitor internally, so we should pass in the display ID to the function
rather than the mapped monitor ID. This was causing 2 monitors on the
same monitor with a configuration like this:
monitor-mapping=1:2;2:1
Since a window is not created at startup for each display, the first
display(s) set when the application is opened will never receive and
treat the "notify::show-hint" signal on VirtViewerWindow, once the
callback is only set when the display is set to the specific window.
It causes problems like the "Send Key" menu not activated till an extra
display is added. To avoid this problem, let's force a call to
display_show_hint() everytime a display is set.
Resolves: rhbz#1152468
https://bugzilla.redhat.com/show_bug.cgi?id=1152468
It turns out that nc does not leave on server disconnect, and there
doesn't seem to be any option to do that, leaving client open, and
a bunch of idle processes.
Replacing nc with socat solves that, client is disconnected when
the VM is shut down, when the sever connection is closed.
https://bugzilla.redhat.com/show_bug.cgi?id=1030487
When user starts virt-viewer without specifying VM domain name
or with a wrong name a list of running machines is shown
and user may choose one of them.
When a user tries to connect to ovirt without specifying
VM name (remote-viewer ovirt://ovirt.example.com) or with
wrong VM name a list of available virtual machines is shown,
and the user may pick a machine he wants to connect to.
It turns out this is supposed to be done through update requests with a
CD image with an empty name, which is what the current code tries to do.
The only reason it's not working is because of server-side bugs with
oVirt < 3.5
The requirement on libgovirt is raised to 0.3.2 as
a small change is needed as well in libgovirt to allow empty filenames:
https://git.gnome.org/browse/libgovirt/commit/?id=bdb788fcc
Without this change, nothing too bad will happen, but the CD won't be
removed and warnings will be logged in the console.
The virDomainOpenGraphics API cannot label the socket
we pass to it. Prefer virDomainOpenGraphicsFD (if building
with libvirt 1.2.8 or later) which creates the socket for us
and works with SELinux too.
Fall back to the old API if the new one is unsupported
(i.e. the libvirtd on the host is older than the libvirt version
virt-viewer was compiled against).
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1141228
Signed-off-by: Ján Tomko <jtomko@redhat.com>
virt_viewer_auth_collect_credentials() was recently changed to return
a boolean instead of an integer (2561c171). This change introduced a
regression in the authentication dialog behavior, making it impossible
for the user to cancel.
As the function should return < 0 in error cases, let's explicitly
return/set the return value to -1 in error cases. Otherwise, the
function will return 0.
This patch also fixes a regression introduced by (a5ce2ed3).
https://bugzilla.redhat.com/show_bug.cgi?id=1142742
If uuid was never set, we never checked the 'fallback' monitor map.
Initializing the monitor map to the fallback value at startup solves
this issue. This allows fallback mode to work with older servers that
don't send the UUID.
Previously, the fullscreen floating toolbar and the "toggle-fullscreen"
hotkey (which maps to the menu item action) had slightly different
methods of exiting fullscreen. The floating toolbar method unset the
'fullscreen' property on the application (which causes all windows to
simultaneously exit fullscreen), whereas the hotkey did not. This had a
side-effect of preventing the display from auto re-sizing if it was
fullscreened again. After this change, both the hotkey and the toolbar
button will unset the application-level 'fullscreen' property when
exiting fullscreen mode.
Resolves: rhbz#1022608
Set the display's session property in the constructor. If the session is
not set, then virt_viewer_display_get_session() doesn't return anything
useful.
Currently, windows have a default size of 400x400 pixels. This is a
strange aspect ratio for a display, and it is also too small to be
useful for much. Since the default window size determines the initial
size of newly-enabled displays, it would be nice if we used a slightly
better size.
When setting the 'display' for a VirtViewerWindow, the initial size for
that window should be the size of the remote display. So we synthesize a
desktop resize event when setting a new display for a window. This is
only done for enabled displays. Disabled displays generally have a size
of 0x0, which would result in the window being at it's minimum size, so
just allow the window to use its default size.
