IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Any copyright line must use 'Copyright (C) <year> Red Hat'
per the syntax-check rule.
Use of -a / -o args to "test" is non-portable and should
instead be done with 'test ... || test ...'
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Makefile.am: Use helper variables from git.mk
man/Makefile.am: This should be $(dist_man_MANS) instead of $(man_MANS)
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
After removing m4/.gitignore file in previous patch, I started getting
the following error when running autogen.sh.
ln: failed to create symbolic link ‘m4/intltool.m4’: No such file or directory
cp: cannot create regular file ‘m4/intltool.m4’: No such file or directory
intltoolize: cannot copy '/usr/share/aclocal/intltool.m4' to 'm4/intltool.m4'
The problem is that intltoolize requires te m4/ directory to be present,
and this directory is actually created by running autoreconf, so it
should be called before intltoolize.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
When running in fullscreen it is possible to end up in a situation
where we have more displays enabled than monitors. This can happen
if displays that were enabled in the previous connection to the guest
doesn't match displays requested when entering the fullscreen mode.
This commit solves the problem by disabling displays that should not be
enabled in the fullscreen mode.
Resolves: rhbz#1212802
As sorted_displays is a vector containing all displays' order, its
allocation size must be the maximum display id + 1 instead of the
maximum display id. Also, fix the size used for sorting and iterating
the sorted_displays vector.
Valgrind log:
==15946== Invalid write of size 4
==15946== at 0x4169C0: virt_viewer_align_monitors_linear (virt-viewer-util.c:581)
==15946== by 0x42248B: virt_viewer_session_on_monitor_geometry_changed (virt-viewer-session.c:438)
==15946== by 0xBB41F03: _g_closure_invoke_va (gclosure.c:831)
==15946== by 0xBB5BC7C: g_signal_emit_valist (gsignal.c:3214)
==15946== by 0xBB5C764: g_signal_emit_by_name (gsignal.c:3401)
==15946== by 0x4328F3: virt_viewer_display_spice_monitor_geometry_changed (virt-viewer-display-spice.c:93)
==15946== by 0x432D60: virt_viewer_display_spice_size_allocate (virt-viewer-display-spice.c:224)
==15946== by 0xBB41CD4: g_closure_invoke (gclosure.c:768)
==15946== by 0xBB53538: signal_emit_unlocked_R (gsignal.c:3549)
==15946== by 0xBB5BEEF: g_signal_emit_valist (gsignal.c:3305)
==15946== by 0xBB5C29E: g_signal_emit (gsignal.c:3361)
==15946== by 0x637D6F6: gtk_widget_size_allocate_with_baseline (gtkwidget.c:6093)
==15946== Address 0x18c79d4c is 0 bytes after a block of size 12 alloc'd
==15946== at 0x4C2A9C7: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==15946== by 0xBDD36D1: g_malloc0 (gmem.c:127)
==15946== by 0x41698D: virt_viewer_align_monitors_linear (virt-viewer-util.c:577)
==15946== by 0x42248B: virt_viewer_session_on_monitor_geometry_changed (virt-viewer-session.c:438)
==15946== by 0xBB41F03: _g_closure_invoke_va (gclosure.c:831)
==15946== by 0xBB5BC7C: g_signal_emit_valist (gsignal.c:3214)
==15946== by 0xBB5C764: g_signal_emit_by_name (gsignal.c:3401)
==15946== by 0x4328F3: virt_viewer_display_spice_monitor_geometry_changed (virt-viewer-display-spice.c:93)
==15946== by 0x432D60: virt_viewer_display_spice_size_allocate (virt-viewer-display-spice.c:224)
==15946== by 0xBB41CD4: g_closure_invoke (gclosure.c:768)
==15946== by 0xBB53538: signal_emit_unlocked_R (gsignal.c:3549)
==15946== by 0xBB5BEEF: g_signal_emit_valist (gsignal.c:3305)
Resolves: rhbz#1272650
Related: rhbz#1267184
Creating the monitors hashtable only after checking for the existence of
apply_monitor_geometry vfunc avoids leaking the hashtable in the case
where the vfunc doesn't exist.
Related: rhbz#1267184
When the connection to libvirtd is lost, virt-viewer starts polling for
libvirtd to come back. The polling mechanism is also used when
connecting to very old libvirtd which don't support
virConnectDomainEventDeregisterAny().
Currently, once we could reconnect to libvirtd, virt-viewer will keep
polling, thus behaving as if the libvirtd connection does not support
virConnectDomainEventDeregisterAny(). This commit makes sure we stop
polling once the new libvirtd connection is established.
This has the side-effect of preventing
https://bugzilla.redhat.com/show_bug.cgi?id=1271519 from occurring with
recent libvirt as it's caused by some race occurring when using the
polling code.
When starting virt-viewer in fullscreen mode, we generally try to
arrange guest displays exactly the same as client monitors. So if a
client machine has two monitors, we'll try to enable display 0 and 1 on
the guest (in that order). However, when using the configuration file to
map fullscreen displays to different monitors, the guest displays may
not be sequential, or there may be displays missing. For example,
consider the following configuration:
monitor-mapping=1:2;2:1
In virt_viewer_session_spice_fullscreen_auto_conf(), we were building an
array of GdkRectangles for the initial monitors that we want to enable
on the guest. We then configured the guest displays using the index of
the array for the as the id of the guest display. But when displays
are sparse or are out-of-sequence, the array index will not match the
>ntended display ID. This created problems where displays were arranged
incorrectly. By changing the simple array into a GHashTable, we can keep
the display ID together with the GdkRectangle until we need to use it,
and things will be configured correctly.
This regression was introduced by c586dc8c.
Fixes: rhbz#1267184
Make "main-window" a construct-only property of VirtViewerSessionSpice.
This allows us to set it in the constructor and encapsulate all of the
setup within the gobject constructor rather than doing extra work in the
_new() function.
As, in theory, file ids are stables, seems that we have been using the
wrong id for remote-viewer.exe (not sure if since forever or if the path
changed).
That's what msidump shows:
ffidenci@cat ~/src/upstream/virt-viewer/dump $ grep "fil808B4A5BAB4ACD727D3823632E798743" File.idt
ffidenci@cat ~/src/upstream/virt-viewer/dump $ grep "fil808B4A5BAB4ACD727D3823632E798743" Registry.idt
reg29E29C5608128A0192FB9DC3C18562A6 0
VirtViewer.vvfile\shell\open\command
"[#fil808B4A5BAB4ACD727D3823632E798743]" "%1" CProgIds
ffidenci@cat ~/src/upstream/virt-viewer/dump $ grep "remote-viewer.exe" File.idt
fil610DF9E49759B1DEC646290195F96F8A cmp7677A8696936707272DCA43B1BF26760
remote-viewer.exe 855735 512 837
So, let's use the correct id (fil610DF9E49759B1DEC646290195F96F8A) from
now on.
Related: rhbz#1146016
Currently libxml2 is pulled as an indirect dependency when virt-viewer
is built with support to ovirt or libvirt (pulled by rest or libvirt,
respectively). However, {virt,remote}-viewer itself depends on libxml2
and not having it as an explicit dependency will cause errors on opening
remote-viewer when it is built without support to ovirt/libvirt.
Previously, there was a single function for controlling the enabled
state of a display: virt_viewer_display_set_enabled(). Unfortunately,
this function is used for two slightly different things:
A. It informs the local display widget that the display has become
disabled or enabled on the server. In other words, it tries to
synchronize the 'enabled' state of the local widget with the actual
state of the remote display.
OR
B. It tries to actively enable a currently-disabled display (or vice
versa) due to some action by the user in the client application.
This causes the client to send a new configuration down to the
server. In other words, it tries to change the state of the remote
display.
There is some conflict between these two scenarios. If the change is due
to a notification from the server, there is no need to send a new
configuration back down to the server, so this results in unnecessary
monitor configuration messages and can in fact cause issues that are a
little bit hard to track down. Because of this, I decided that it was
really necessary to have two separate functions for these two different
scenarios. so the existing _set_enabled() function will be used for
scenario A mentioned above. I added two new
functions (_enable() and _disable()) that are used to send new
configurations down to the server.
Previously, when we received a new monitors update from the server, we
only called virt_viewer_display_set_enabled() for the displays that were
enabled. We simply assumed that those that were not enabled were already
set to disabled. This assumption is currently valid, but I have some
changes in the pipeline where this is not true. This change ensures that
we update the enabled state of all monitors when we get an updated
monitors conifguration.
When a display widget receives a new size allocation, we generally emit
a monitor-geometry-changed signal so that we can reconfigure the
displays. But if the widget for a *disabled* display is allocated,
there's no reason to send down a new configuration. We don't need to
emit this signal. This doesn't currently cause any problems, but I ran
into issues while testing some other uncommitted changes.
Coverity says:
Result is not floating-point (UNINTENDED_INTEGER_DIVISION)
interger_division: Dividing integer expressions "preferred->width * 100"
and "zoom", and then converting the integer quotient to type double. Any
remainder, or fractional part of the quotient, is ignored.
Coverity says:
You might overrun the 108 byte fixed-size string "addr.sun_path" by
copying "unixsock" without checking the lenght.
Note: This detect has an elevated risk because the source argument is a
paramenter of the current function.
To make clear why configure failed - e.g.:
Package requirements (spice-client-gtk-2.0 >= 0.28) were not met
Requested 'spice-client-gtk-2.0 >= 0.28' but version of spice-client-gtk-2.0 is 0.25
instead of
spice-gtk requested but not found
Related:
https://bugzilla.redhat.com/show_bug.cgi?id=1214577
When neither --with-spice-gtk=yes nor --with-spice-gtk=no is used,
spice-gtk is supposed to be automatically enabled/disabled depending
on its availability. However, this is not perfectly working as once
spice-gtk has been detected as available, configure will fail if
spice-protocol or spice-controller are too old. In this case, spice-gtk
support should just be disabled rather than configure failing
The zoom can be changed by resizing the window (VNC / Spice without
the agent). It is necessary to recalculate the zoom level before
changing it, otherwise zoom operations will not work correctly.
Resolves:
https://bugs.freedesktop.org/show_bug.cgi?id=90582
Under some circumstances (Xfce desktop environment, gtk3 client, RHEL6
guest having two monitors running locally) it is possible to create
a loop of resizing windows. It is caused by size request like 1x1 sent
to the guest. These request are created because _window_queue_resize()
is called when the window is being shown.
To avoid the problem, call gtk_widget_show() after its preferred and
default sizes are set.
Resolves:
https://bugs.freedesktop.org/show_bug.cgi?id=91405
virt_viewer_events_add_handle() creates a GIOChannel in order to watch the
fd it was given for changes.
virt_viewer_events_remove_handle() is freeing all the resources allocated by
virt_viewer_events_add_handle() except for this GIOChannel. This commit adds
the needed g_io_channel_unref() call to virt_viewer_events_remove_handle()
Based on commit 8e95b8d25a3eee6316aff2f83b0c449aaf10984a from
libvirt-glib.
Original author: Christophe Fergeau <cfergeau@redhat.com>
Related to: rhbz#1243228
Trying to remove a disabled timer or handle will cause
virt_viewer_events_remove_{handle,timeout}() to return an error
rather than removing it.
Based on commit 79699d73e6e1b7218e3bd8349d176752f86128b9 from
libvirt-glib.
Original author: Christophe Fergeau <cfergeau@redhat.com>
Related to: rhbz#1243228
It's possible to create a handle to watch for file events which do not
watch for any file event. Such a handle can be enabled later with
virt_viewer_events_update_handle() by setting some conditions to watch for.
When a handle is disabled after it has been created,
virt_viewer_events_update_handle() makes sure it removes the corresponding
virt_viewer_events_handle::source IO watch if any was set.
virt_viewer_events_add_handle() will always create a
virt_viewer_events_handle::source IO watch even if the handle is not
watching for any events.
This commit makes consistent by only creating a watch with g_io_add_watch()
when the caller asked to watch for some events.
Based on commit d71c143936a35cd6c3f23ae0cbf7f3215d944051 from
libvirt-glib.
Original author: Christophe Fergeau <cfergeau@redhat.com>
Related to: rhbz#1243228
The _event_timeout_remove and _event_handle_remove methods
were holding onto the global lock when invoking the free
callback. This is a violation of the libvirt events API
contract which requires free callbacks to be invoked in
a re-entrant safe context.
Based on commit dd17c3cc587c73a8c915238f9d9a3e200e89c93f from
libvirt-glib.
Original author: Daniel P. Berrange <berrange@redhat.com>
Related to: rhbz#1243228
The deletion of libvirt timeouts/watches is done in 2 steps:
- the first step is synchronous and unregisters the timeout/watch
from glib mainloop
- the second step is asynchronous and triggered from the first step.
It releases the memory used for bookkeeping for the timeout/watch
being deleted
This is done this way to avoid some possible deadlocks when
reentering the sync callback while freeing the memory associated
with the timeout/watch.
However, it's possible to call gvir_event_update_handle after
gvir_event_remove_handle but before _event_handle_remove does
the final cleanup. When this happen, _update_handle will reregister
the handle with glib mainloop, and bad things will happen when
a glib callback is triggered for this event after _event_handle_remove
has freed the memory associated with this handle watch.
This commit marks the timeouts and watches as removed in the
synchronous _remove callback and makes sure removed timeouts/watches
are ignored in _update callbacks.
Based on commit 3e73e0cee977fb20dd29db3ccfe85b00cc386c43 from
libvirt-glib.
Original author: Christophe Fergeau <cfergeau@redhat.com>
Related to: rhbz#1243228
Timeout and watch deletion is done from an idle callback. However,
we cannot assume that all libvirt event calls (the callbacks passed
to virEventRegisterImpl) will be done from the mainloop thread. It's
thus possible that a libvirt event call will run a thread while
one of the idle deletion callbacks runs.
Given that the 'handles' and 'timeouts' arrays are shared among all
threads, we need to make sure we hold the 'eventlock' mutex before
modifying them.
Based on commit 924178f6b35735458b37d30303fe7bc753dde0b1 from
libvirt-glib.
Original author: Christophe Fergeau <cfergeau@redhat.com>
Related to: rhbz#1243228
Based on commit 1fb34633ef3b318ea678b775d5e47debc98d2184 from
libvirt-glib.
Original author: Christophe Fergeau <cfergeau@redhat.com>
Related to: rhbz#1243228
In libvirt, it's perfectly possible and widely used to have disabled
timers (timeout=-1) and fire them up 'randomly' with timeout=0.
However, with current mapping into glib mainloop it's not possible
and causing troubles.
Based on commit a40a1732e0d53fcc44b8d348cec97152dafd2b88 from
libvirt-glib.
Original author: Michal Privoznik <mprivozn@redhat.com>
Related to: rhbz#1243228
Since 2.31, g_mutex_new() is deprecated.
Based on commit 2dc7476d32a9e158e688486e8f184c719c53bb4c from
libvirt-glib.
Original author: Daniel P. Berrange <berrange@redhat.com>
Related to: rhbz#1243228
Otherwise, it will crash next time it goes find()
Backtrace:
(gdb) where
#0 0x00007efcae715095 in g_io_create_watch () from
/lib64/libglib-2.0.so.0
#1 0x00007efcae7150ef in g_io_add_watch_full () from
/lib64/libglib-2.0.so.0
#2 0x00000000004275ba in virt_viewer_events_update_handle
(watch=<optimized out>, events=1) at
virt-viewer-events.c:158
#3 0x00007efcb1a62dce in virNetSocketUpdateIOCallback (sock=0x1e75c00,
events=1) at rpc/virnetsocket.c:1981
#4 0x00007efcb1a50113 in virNetClientIOUpdateCallback
(client=<optimized out>, enableCallback=<optimized out>) at
rpc/virnetclient.c:1639
#5 0x00007efcb1a50f82 in virNetClientIO (thiscall=0x20e0170,
client=0x1f2e060) at rpc/virnetclient.c:1793
#6 virNetClientSendInternal (client=client@entry=0x1f2e060,
msg=msg@entry=0x20e0100,
expectReply=expectReply@entry=false, nonBlock=nonBlock@entry=true) at
rpc/virnetclient.c:1962
#7 0x00007efcb1a52413 in virNetClientSendNonBlock (client=0x1f2e060,
msg=msg@entry=0x20e0100) at
rpc/virnetclient.c:2036
#8 0x00007efcb1a5243d in virNetClientKeepAliveSendCB (opaque=<optimized
out>, msg=0x20e0100) at
rpc/virnetclient.c:293
#9 0x00007efcb1a5ba02 in virKeepAliveTimer (timer=<optimized out>,
opaque=0x20d3d00) at rpc/virkeepalive.c:176
#10 0x00000000004272e9 in virt_viewer_events_dispatch_timeout
(opaque=0x1e6cd30) at virt-viewer-events.c:233
#11 0x00007efcae7231b3 in g_timeout_dispatch () from
/lib64/libglib-2.0.so.0
#12 0x00007efcae72279a in g_main_context_dispatch () from
/lib64/libglib-2.0.so.0
#13 0x00007efcae722ae8 in g_main_context_iterate.isra.24 () from
/lib64/libglib-2.0.so.0
#14 0x00007efcae722dba in g_main_loop_run () from
/lib64/libglib-2.0.so.0
#15 0x00007efcb054a045 in gtk_main () from /lib64/libgtk-3.so.0
#16 0x0000000000410a9c in main (argc=1, argv=0x7ffde58a7978) at
virt-viewer-main.c:124
Based on commit cff5f1c46f4b9661e112b85159fb58ae473a9a89 from
libvirt-glib.
Original author: Marc-André Lureau <marcandre.lureau@redhat.com>
Related to: rhbz#1243228
Based on commit 8f8d9ce5238dbcbce40aa04ba55b8c55f97c79c0 from
libvirt-glib.
Original author: Marc-André Lureau <marcandre.lureau@redhat.com>
Related to: rhbz#1243228
Take a global lock whenever changing any event callbacks to ensure
thread safety.
Based on commit f1fe67da2dac6a249f796535b8dbd155d5741ad7 from
libvirt-glib.
Original author: Daniel P. Berrange <berrange@redhat.com>
Related to: rhbz#1243228
The function virt_viewer_window_resize restricts window to be bigger
than a client's screen. It avoids extending the window to more client's
screens, it causes changes of the zoom level if the guest does not fit
into a screen.
Lets remove virt_viewer_window_resize (its behaviour was introduced
by the commit 6acb3856b6). It will let
the window managers to handle resizing of the window.
Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=1221501https://bugzilla.redhat.com/show_bug.cgi?id=1205804
Instead of building every single source file twice (once for
virt-viewer, and once for remote-viewer), just build them into a
temporary library and link the final executables against that.
The one possible drawback to this approach is that we now use the same
log domain for both executables: 'virt-viewer'. Previously, the
remote-viewer executable used 'remote-viewer' for its log domain.
As virt-viewer builds for Windows are using GTK3 nowadays, we can easily
drop GTK2 support and avoid maintenance effort in something that is not
used/tested anymore.
As virt-viewer builds for Windows are using GTK3 nowadays, we can easily
drop GTK2 support and avoid maintenance effort in something that is not
used/tested anymore.
