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.
Previously, a window was created at startup for each display, even if
the display was not enabled. This resulted in a fixed 1:1 association
between windows and remote displays. Since there was always one window
created at startup to display status messages (the "main window"), this
was always associated with remote display #1. But if the first remote
display was not enabled, we ended up with a extra black window with a
message saying ("Waiting for display 1...").
By creating windows on demand, we can re-use the "main window" for any
arbitrary display, even if it's not display #1.
Resolves: rhbz#1032939
When using the fullscreen display mapping configuration file, extra
monitors could end up enabled by mistake. This was because
virt_viewer_app_get_initial_monitor_for_display would end up returning
Nmonitor = Ndisplay when the display map hash lookup failed. In
reality, when a display map is specified, but the hash lookup fails,
the display should not be enabled. This function now returns -1 to
distinguish this case, and the display is not enabled when this value is
returned.
Resolves issue described at
https://bugzilla.redhat.com/show_bug.cgi?id=1129477#c9
Rather than requiring all callers to calculate the initial monitor
mapping before calling app_window_try_fullscreen, move the
responsibility for calculating the correct monitor into this function.
This makes it less likely that somebody will forget and a display will
get placed on the wrong monitor.
Right after being created, the SpiceDisplay 'display' private member is
added to the VirtViewerDisplaySpice GTK+ container with
gtk_container_add. This call will take ownership of the floating
reference that SpiceDisplay got upon creation.
This means VirtViewerDisplaySpice::display is a pointer to SpiceDisplay,
but it must not be unref'ed when the object is destroyed as we don't own
that reference.
As the container which owns the reference is the
VirtViewerDisplaySpice instance itself, we don't need to take an
additional reference here.
This fixes a crash when exiting remote-viewer after connecting to a
SPICE VM:
#0 0x00007ffff3f33a81 in g_type_check_instance_is_fundamentally_a (type_instance=0x874500, fundamental_type=80) at gtype.c:3981
#1 0x00007ffff3f19f96 in g_object_unref (_object=0x874500) at gobject.c:3067
#2 0x000000000042a1ea in virt_viewer_display_spice_finalize (obj=0x6ebc30) at virt-viewer-display-spice.c:65
#3 0x00007ffff3f1a257 in g_object_unref (_object=0x6ebc30) at gobject.c:3170
#4 0x0000000000428de7 in destroy_display (data=0x6ebc30) at virt-viewer-session-spice.c:649
#5 0x00007ffff3bbb51b in g_ptr_array_foreach (array=0x7e12a0, func=0x428d71 <destroy_display>, user_data=0x0) at garray.c:1502
#6 0x00007ffff3bbaadf in ptr_array_free (array=0x7e12a0, flags=FREE_SEGMENT) at garray.c:1088
#7 0x00007ffff3bbaa10 in g_ptr_array_unref (array=0x7e12a0) at garray.c:1036
#8 0x00007ffff3bcf9bd in g_data_set_internal (datalist=0xa0adb0, key_id=1622, new_data=0x0, new_destroy_func=0x0, dataset=0x0) at gdataset.c:407
#9 0x00007ffff3bcfe74 in g_datalist_id_set_data_full (datalist=0xa0adb0, key_id=1622, data=0x0, destroy_func=0x0) at gdataset.c:670
#10 0x00007ffff3f1a771 in g_object_set_data (object=0xa0ada0, key=0x437252 "virt-viewer-displays", data=0x0) at gobject.c:3461
#11 0x0000000000429b56 in virt_viewer_session_spice_channel_destroy (s=0x6eb910, channel=0xa0ada0, session=0x8cb3a0) at virt-viewer-session-spice.c:854
#12 0x00007ffff3f12d81 in g_cclosure_marshal_VOID__OBJECT (closure=0x8e8fd0, return_value=0x0, n_param_values=2, param_values=0x7fffffffcd80, invocation_hint=0x7fffffffccc0, marshal_data=0x0) at gmarshal.c:1272
#13 0x00007ffff3f0e143 in g_closure_invoke (closure=0x8e8fd0, return_value=0x0, n_param_values=2, param_values=0x7fffffffcd80, invocation_hint=0x7fffffffccc0) at gclosure.c:768
#14 0x00007ffff3f2aef0 in signal_emit_unlocked_R (node=0x7c1f20, detail=0, instance=0x6eb910, emission_return=0x0, instance_and_params=0x7fffffffcd80) at gsignal.c:3553
#15 0x00007ffff3f2a1f3 in g_signal_emit_valist (instance=0x6eb910, signal_id=219, detail=0, var_args=0x7fffffffd058) at gsignal.c:3309
#16 0x00007ffff3f2a746 in g_signal_emit (instance=0x6eb910, signal_id=219, detail=0) at gsignal.c:3365
#17 0x00007ffff529d784 in spice_session_channel_destroy (session=0x6eb910, channel=0xa0ada0) at spice-session.c:1990
#18 0x00007ffff529ed25 in spice_channel_dispose (gobject=0xa0ada0) at spice-channel.c:153
#19 0x00007ffff52acd26 in spice_display_channel_dispose (object=0xa0ada0) at channel-display.c:136
#20 0x00007ffff3f1a132 in g_object_unref (_object=0xa0ada0) at gobject.c:3133
#21 0x00007ffff52a4afb in spice_channel_delayed_unref (data=0xa0ada0) at spice-channel.c:2156
#22 0x00007ffff3bf21d1 in g_idle_dispatch (source=0xa35a00, callback=0x7ffff52a49f3 <spice_channel_delayed_unref>, user_data=0xa0ada0) at gmain.c:5320
#23 0x00007ffff3bef8eb in g_main_dispatch (context=0x68a920) at gmain.c:3064
#24 0x00007ffff3bf0661 in g_main_context_dispatch (context=0x68a920) at gmain.c:3663
#25 0x00007ffff3bf0853 in g_main_context_iterate (context=0x68a920, block=1, dispatch=1, self=0x6c8c60) at gmain.c:3734
#26 0x00007ffff3bf0c7c in g_main_loop_run (loop=0x889b20) at gmain.c:3928
#27 0x00007ffff69be44f in gtk_main () at gtkmain.c:1207
#28 0x0000000000431896 in main (argc=1, argv=0x7fffffffd648) at remote-viewer-main.c:183
Due to a GTK+ limitation and bad testing from my side, I've pushed
two patches trying to add support to use Ctrl + {+, -, 0} from numpad
to control zoom-in, zoom-out and zoom-reset.
Unfortunately, with the first patch (3a168815) I've duplicated the menu
items related to the zoom functions. With the second one (55cdb986),
provided to not show the duplicated menu items, we came back to the
initial state, where the numpad accelerators don't work.
So, in resume, multiple accelerators in a GTK+ widget are only supported
on applications using GApplication, what is not our case and won't be
till we drop the GTK+2 support.
Revert "Do not show duplicated menu items" and
Revert "Add support to use numpad accelarators for zoom-{in.out,reset}"
This reverts commits 55cdb9867d and
3a168815b7.
When the support to use numpad accelerators for zoom-{in,out,reset}
was added (3a168815), by mistake, we have added duplicated buttons
in View -> Zoom.
The oVirt foreign menu support reused some existing bits from the older
SPICE controller foreign menu code. However, this controller code is
only built when spice-gtk support is built, while the oVirt foreign menu
code could be used with VNC as well. Trying to build the ovirt foreign
menu code without spice-gtk causes build issues due to missing
functions, or missing declarations, ...
The libgovirt/spice-gtk code which is entangled is the code to update
the foreign menu when its content changes, or when a new window is
opened. Making the oVirt-specific code independant from the
spice-gtk-specific code is not too complicated, but this comes at the
expense of a bit of code duplication, but this is only simple code
iterating over the GHashTable storing the opened windows.
Resolves: rhbz#1127156
