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.
The main window (display #1) is treated a bit differently from other windows,
since it is opened at app start and displays status messages while we attempt to
connect to the remote guest. As such, it should really stay open as long as the
app is running.
The impetus for this change is the following:
- user attempts to connect to a remote VNC display with a password
- user types the wrong password
- A dialog pops up indicating that authentication failed and asking if the user
would like to try to re-connect.
- User clicks 'Yes'
- Because the connection was disconnected, all windows are closed
- remote-viewer tries to reconnect again, at which point a new display window is
opened, and the window gets placed by the window manager (possibly on another
monitor altogether).
As a user, I expect the program to simply re-use the existing window when trying
to re-authenticate, instead of having the window disappear and then re-appear at
a different location. This patch accomplishes that.
Recent spice servers send the guest vm name and uuid to the client. We can use
these values to display the proper vm name in the window title if a title is not
specified on the commandline. We can also be smarter about the title in
virt-viewer as well.
If a title is specified on the comamndline (-t/--title=foo), we use that. If not,
we fall back to the vm name. If that is empty, we fall back to the uri of the
connection.
Comparison between old behavior and new behavior
Using new spice-server
Command Old title New title
------- --------- ---------
remote-viewer -t xyz spice://host:port xyz xyz
remote-viewer spice://host:port spice://host:port <vmname>
virt-viewer <vmname> <vmname> <vmname>
virt-viewer <uuid> <uuid> <vmname>
Using old spice-server
Command Old title New title
------- --------- ---------
remote-viewer -t xyz spice://host:port xyz xyz
remote-viewer spice://host:port spice://host:port spice://host:port
virt-viewer <vmname> <vmname> <vmname>
virt-viewer <uuid> <uuid> <vmname>
When trying to load ui files, we try to find the file in several directories.
If a file is not found in one directory, try to load it from the next directory.
However, if a file is found in a directory but we are not able to load it (e.g.
due to unsupported versions of glade used to generate it, etc), we should print
a warning to the terminal to help the developer debug the issue.
This is an unexpected failure (whereas not finding the file in that directory at
all is an 'expected' failure).
Libvirt uses gnulib for making winsock look like POSIX
sockets. This means that in the libvirt event handle
callbacks the application will be given a file descriptor
rather than a winsock HANDLE object. The g_io_channel_unix_new
method will detect that it is an FD and delegate to the
g_io_channel_win32_new_fd method. Unfortunately the glib Win32
event loop impl is not very good at dealing with FD objects,
simulating poll() by doing a read() on the FD :-(
The API docs for g_io_channel_win32_new_fd say
"All reads from the file descriptor should be done by
this internal GLib thread. Your code should call only
g_io_channel_read()."
This isn't going to fly for libvirt, since it has zero
knowledge of glib at all, so is just doing normal read().
Fortunately we can work around this problem by turning
the FD we get from libvirt back into a HANDLE using the
_get_osfhandle() method.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
virt_viewer_util_load_ui() looks first in the current directory, and then looks
in the system data dirs for a ui file to load, but if you install virt-viewer in
a different prefix, it will load the system UI file rather than the one from the
install prefix. Try to load the ui file from pkgdatadir first.
It's not enough to set the property to notify of its change. Add a
virt_viewer_app_set_enable_accel() helper, and call it after the changes
to accelerators are made when loading from file.
I verified the menu is correctly built when connection from controller
or command line too.
Updating the mime database creates files in the install directory, and
these files are not cleaned up on make uninstall, so this causes a make
distcheck failure.
d1c2bc1 updated configure.ac spice-gtk requirement to 0.22, but did not
update the various places which duplicated this requirement, namely the
.spec.in files and the README file.
remomte-viewer installs a file to $datadir/share/mime to register a
mime-type for its .vv files. However, after installing this file,
update-mime-database must be run in order to update the shared mime
database. This commit (inspired by what Nautilus/planner are doing) adds
what is needed for that.
If the mime type is not correctly registered, gvfs-info console.vv will not
return the correct mime type, and xdg-open console.vv will fail to start
remote-viewer, and will fall back to running gedit as the .vv file is a
text file.
https://bugzilla.redhat.com/show_bug.cgi?id=1044209
This ensures that the display is enabled when it gets its first Allocate event
(which causes a display reconfiguration). If the display is not enabled at this
point, it won't send down a new monitors_config message until the second
allocation, which may result in the display being disabled until a window is
resized.
The govirt package in f19 is an older one, and does not have some of the
functions used since the switch to govirt 0.3.0. As 0.3.0 broke ABI, it's
not convenient to backport it to f19.
Update the spec file to reflect the fact that oVirt support in git is no
longer buildable on f19.
It's possible to have only display N enabled without having all of the displays
before it. I experienced this a couple times with a windows guest where display
1 would show up before display 0 and we'd hit a warning that nth is not less
than nmonitors. So find the highest display ID and then create an array of that
size, leaving missing displays initialized to 0
This caused secondary displays on a windows guest to flicker under some
circumstances. The old code didn't re-configure displays in this case either, so
it shouldn't have been included in the display alignment refactor.
Don't rely on spice-gtk to do any alignment of displays. This patch sets the
disable-display-align property on the SpiceMainChannel, and makes the
VirtViewerSession in charge of doing all alignment. This means that every
display has to tell the VirtViewerSession when its "virtual monitor" has changed
configuration (and wants to reconfigure its display on the guest), rather than
sending it directly to the Main Channel. The session will then align the
displays (if necessary), and the spice session will send down new configuration
for all displays at once. This solves a couple of problems:
1. It allows the session to send down absolute coordinates only in the case
where *all* windows are fullscreen (so that we can still support
vertically-stacked displays, etc). But it auto-aligns displays if only a
subset of the displays are in fullscreen mode. This solves the problem of
overlapping regions on different displays when one monitor is in fullscreen
because only one monitor's configuration was updated and the others were not
aligned.
2. Allows us to always align based on the current position of each display. This
contrasts with the earlier behavior where the position used for alignment was
the window's position at the time when it was last resized. This caused
displays to be arranged in a seemingly non-deterministic manner if one window
was moved and then another window was resized (causing a display
re-configuration).
Solves rhbz#1002156
There are cases where multiple VirtViewerWindow objects are created before the
VirtViewerApp constructor has a chance to run. Since the constructor has not yet
run, priv->main_window will still be NULL, the test in
virt_viewer_app_window_new() will fail, and they will not get their initial zoom
level set. When the constructor finally runs, it set the zoom level of the main
window to the value set on the command line, but all other windows that had
already been created retained the default 100% zoom level.
By creating the main_window in the instance init function, we ensure that the
main window is created before we get any 'session-display-added' signals and all
displays will start out with consistent zoom levels.
VIRT_VIEWER_HIDE could be set as an environment variable to (theoretically) hide
displays whenever they were not ready. Unfortunately, this bit of functionality
appears bitrotten and doesn't work anymore (it prevents windows from opening
when you click 'view > displays > display 2', for instance).
Auto-conf should only happen at startup. It is triggered from several places due
to the somewhat unreliable ordering of events, but that doesn't mean we want to
run it several times. This patch ensures that we only do it once.
Fullscreen mode generally just assigns display 1 to monitor 1, display 2 to
monitor 2, etc. For custom setups, you can define a monitor mapping in the
settings keyfile per-vm. This requires a vm uuid (so only works in virt-viewer
or on versions of spice-server that send the uuid over the wire). The format is
pretty basic:
[6485b20f-e9da-614c-72b0-60a7857e7886]
monitor-mapping=2;3
The group name ("6485b20f-e9da-614c-72b0-60a7857e7886") is the uuid id of the
vm. This group has a single key: monitor-mapping. This key is an array of
integers describing the order in which to assign the monitors to a guest
display. Any monitors that are not listed in this array will not be configured
at startup. For instance:
monitor-mapping=2;1
will attempt to configure 2 displays on the guest and assign the first display
to monitor 2 and the second display to monitor 1.
monitor-mapping=2
will only configure a single display on the guest and place it on the second
monitor. Any monitor numbers listed in the keyfile are greater than the number
of monitors that are physically present, they will be ignored.
The VirtViewerApp::windows hash table owns the memory for both the keys
and values it stores. virt_viewer_app_remove_nth_window() uses
g_hash_table_steal() which does not call the 'free' function neither for
the key nor for the value. This method takes care of releasing the
reference for the value it extracted from the hash table, but not for the
key.
This commit fixes by explicitly taking a reference on the value rather than
stealing the one held by the hash table. We can then replace the use of
g_hash_table_steal() with g_hash_table_remove() which will take care of
freeing the removed key.
VirtViewerSessionSpice creates a reference-holding VirtViewerDisplay
array and associates it with the display SpiceChannel with
g_object_set_data(channel, "virt-viewer-displays").
When virt_viewer_session_spice_channel_destroy() is called and the display
channel is being destroyed, we should ensure these VirtViewerDisplay
references are dropped or the displays could outlive the session.
In my testing (start qemu with a f20 live cd, connect to it, when the
kernel has started booting and qxl is initialized (4 displays listed in the
display submenu), kill qemu), I was getting "invalid unclassed pointer in
cast to 'VirtViewerSessionSpice'" warnings through
#0 0x00000035bac504e9 in g_logv (log_domain=0x35bb039aa4 "GLib-GObject",
log_level=G_LOG_LEVEL_WARNING, format=<optimized out>,
args=args@entry=0x7fffffffc7c0) at gmessages.c:989
#1 0x00000035bac5063f in g_log (
log_domain=log_domain@entry=0x35bb039aa4 "GLib-GObject",
log_level=log_level@entry=G_LOG_LEVEL_WARNING,
format=format@entry=0x35bb041010 "invalid unclassed pointer in cast to '%s'")
at gmessages.c:1025
#2 0x00000035bb032e09 in g_type_check_instance_cast (type_instance=0x665580,
iface_type=<optimized out>) at gtype.c:4025
#3 0x0000000000426e9f in get_main (self=0x894190) at virt-viewer-display-spice.c:92
#4 0x0000000000426ece in show_hint_changed (self=0x894190)
at virt-viewer-display-spice.c:100
#5 0x00000035bb010298 in g_closure_invoke (closure=0x9f47c0,
return_value=return_value@entry=0x0, n_param_values=2,
param_values=param_values@entry=0x7fffffffcad0,
invocation_hint=invocation_hint@entry=0x7fffffffca70) at gclosure.c:777
#6 0x00000035bb02235d in signal_emit_unlocked_R (node=node@entry=0x651f60,
detail=detail@entry=1782, instance=instance@entry=0x894190,
emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fffffffcad0) at gsignal.c:3586
#7 0x00000035bb02a0f2 in g_signal_emit_valist (instance=<optimized out>,
signal_id=<optimized out>, detail=<optimized out>,
var_args=var_args@entry=0x7fffffffcc60) at gsignal.c:3330
#8 0x00000035bb02a3af in g_signal_emit (instance=<optimized out>,
signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3386
#9 0x00000035bb014945 in g_object_dispatch_properties_changed (object=0x894190,
n_pspecs=92, pspecs=0x0) at gobject.c:1047
#10 0x00000035bb017019 in g_object_notify_by_spec_internal (pspec=<optimized out>,
object=0x894190) at gobject.c:1141
#11 g_object_notify (object=0x894190, property_name=<optimized out>) at gobject.c:1183
#12 0x000000000041b617 in virt_viewer_display_set_show_hint (self=0x894190, mask=1,
enable=0) at virt-viewer-display.c:659
#13 0x000000000042712c in update_display_ready (self=0x894190)
at virt-viewer-display-spice.c:156
#14 0x00000035bb010298 in g_closure_invoke (closure=0x6ba480,
return_value=return_value@entry=0x0, n_param_values=2,
param_values=param_values@entry=0x7fffffffcfb0,
invocation_hint=invocation_hint@entry=0x7fffffffcf50) at gclosure.c:777
#15 0x00000035bb02235d in signal_emit_unlocked_R (node=node@entry=0x651f60,
detail=detail@entry=1798, instance=instance@entry=0xa2c250,
emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fffffffcfb0) at gsignal.c:3586
#16 0x00000035bb02a0f2 in g_signal_emit_valist (instance=<optimized out>,
signal_id=<optimized out>, detail=<optimized out>,
var_args=var_args@entry=0x7fffffffd140) at gsignal.c:3330
#17 0x00000035bb02a3af in g_signal_emit (instance=<optimized out>,
signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3386
#18 0x00000035bb014945 in g_object_dispatch_properties_changed (object=0xa2c250,
n_pspecs=92, pspecs=0x0) at gobject.c:1047
#19 0x00000035bb017019 in g_object_notify_by_spec_internal (pspec=<optimized out>,
object=0xa2c250) at gobject.c:1141
#20 g_object_notify (object=0xa2c250, property_name=<optimized out>) at gobject.c:1183
#21 0x00007ffff7044d9a in update_ready (display=0xa2c250) at spice-widget.c:257
#22 0x00007ffff7044df0 in set_monitor_ready (self=0xa2c250, ready=0)
at spice-widget.c:265
#23 0x00007ffff7049bb3 in primary_destroy (channel=0x9f40b0, data=0xa2c250)
at spice-widget.c:2131
#24 0x00007ffff704afd5 in channel_destroy (s=0x892880, channel=0x9f40b0, data=0xa2c250)
at spice-widget.c:2444
#25 0x00000035bb010298 in g_closure_invoke (closure=0xa27850,
return_value=return_value@entry=0x0, n_param_values=2,
param_values=param_values@entry=0x7fffffffd570,
invocation_hint=invocation_hint@entry=0x7fffffffd510) at gclosure.c:777
#26 0x00000035bb02235d in signal_emit_unlocked_R (node=node@entry=0x7cf600,
detail=detail@entry=0, instance=instance@entry=0x892880,
emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fffffffd570) at gsignal.c:3586
#27 0x00000035bb02a0f2 in g_signal_emit_valist (instance=<optimized out>,
signal_id=<optimized out>, detail=<optimized out>,
var_args=var_args@entry=0x7fffffffd700) at gsignal.c:3330
#28 0x00000035bb02a3af in g_signal_emit (instance=<optimized out>,
signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3386
#29 0x00007ffff6ceba87 in spice_session_channel_destroy (session=0x892880,
channel=0x9f40b0) at spice-session.c:1923
#30 0x00007ffff6cecf05 in spice_channel_dispose (gobject=0x9f40b0)
at spice-channel.c:149
#31 0x00007ffff6cf912c in spice_display_channel_dispose (object=0x9f40b0)
at channel-display.c:136
#32 0x00000035bb014ee8 in g_object_unref (_object=0x9f40b0) at gobject.c:3160
#33 0x00007ffff6cf300c in spice_channel_delayed_unref (data=0x9f40b0)
at spice-channel.c:2135
#34 0x00000035bac492a6 in g_main_dispatch (context=0x67a6b0) at gmain.c:3066
#35 g_main_context_dispatch (context=context@entry=0x67a6b0) at gmain.c:3642
#36 0x00000035bac49628 in g_main_context_iterate (context=0x67a6b0,
block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
at gmain.c:3713
#37 0x00000035bac49a3a in g_main_loop_run (loop=0x7baf60) at gmain.c:3907
#38 0x00000035bfdaa2d5 in gtk_main () at gtkmain.c:1158
#39 0x000000000042caf1 in main (argc=1, argv=0x7fffffffdc78) at remote-viewer-main.c:179
In that backtrace, the last ref to the VirtViewerDisplay instances is held by the
SpiceChannel:virt-viewer-displays object data which will only be released after
completion of spice_display_channel_dispose()
