summaryrefslogtreecommitdiffstats
path: root/src/virt-viewer-session-spice.c
Commit message (Collapse)AuthorAgeFilesLines
* cleanup: Don't use GtkStockFabiano Fidêncio2016-02-241-1/+1
| | | | | | | | | | | | It has been deprecated since Gtk 3.10. New strings have been added as the GTK_STOCK_* defines had their translations done inside Gtk itself, but now the translations of the new added labels must be done by virt-viewer translators. Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com> Acked-by: Jonathon Jongsma <jjongsma@redhat.com> Acked-by: Pavel Grunt <pgrunt@redhat.com>
* cleanup: Drop old compatibilty codeFabiano Fidêncio2016-02-241-4/+0
| | | | | | | | A few more pieces of old compatibility code can be dropped, as we already depend on GLib 2.38. Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com> Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
* Drop old compatibility codeEduardo Lima (Etrunko)2016-02-181-1/+0
| | | | | | With glib requirements now being 2.38, these functions do not make sense anymore. Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
* spice: vv-file: do not ignore usb-filterUri Lublin2016-02-181-0/+10
| | | | | | | Fixes rhbz#1309634 Signed-off-by: Uri Lublin <uril@redhat.com> Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
* session-spice: Disable extra displays in fullscreen modePavel Grunt2015-11-041-0/+22
| | | | | | | | | | | | 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
* Use the display ID to configure fullscreen monitorsJonathon Jongsma2015-10-091-18/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* SessionSpice: make main-window a propertyJonathon Jongsma2015-10-091-45/+77
| | | | | | | 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.
* Set enabled status of all displays when we get a monitor updateJonathon Jongsma2015-09-081-2/+4
| | | | | | | | | | 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.
* session-spice: Use display id instead of monitor id in debug logPavel Grunt2015-07-291-1/+2
| | | | | Windows guests have monitor id = 0, so the debug log is always the same: "creating spice display (#:0)" for all the displays.
* Fix inconsistencies in session auth failuresJonathon Jongsma2015-06-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The spice session implementation can retry authentication on its own, whereas the vnc session needs to tear down the session and re-connect in order to retry a failed authentication. This results in the following inconsistent behavior: VNC session: - emits a 'session-auth-failed' signal when the client does not support a particular authentication type (i.e.: a non-recoverable error) Spice session: - emits a 'session-auth-failed' signal when user enters an incorrect password, and immediately retries auth internally VNC session: - emits a 'session-auth-refused' error when user enters an invalid password (i.e.: a recoverable error) Spice Session: - never emits a 'session-auth-refused' signal Because of these differences, the VirtViewerApp code to handle authentication failures is a bit confusing and difficult to maintain. To fix this issue, make both the spice and VNC sessions emit the same signal when similar errors occur. We use the new session API added in the last commit to determine whether the session supports automatic retries so we know how to handle the signal.
* Session: add vfunc to check auth retry capabilityJonathon Jongsma2015-06-191-0/+7
| | | | | | | The spice session implementation can retry authentication on its own, whereas the vnc session needs to tear down the session and re-connect in order to retry a failed authentication. Add API to determine this so that we can clean up some code related to authentication failures.
* Move SpiceSession setup to create_spice_session()Jonathon Jongsma2015-06-191-58/+60
| | | | | | | | | | | | | Most of the setup (connecting to signals, etc) for the SpiceSession was done in create_spice_session(), but some was done afterwards in virt_viewer_session_spice_new(). Consolidate all session configuration in one place. In addition to making it easier to maintain, create_spice_session() is also called in virt_viewer_session_spice_close(). which results in a spice session that is configured slightly differently than the first session created in _new(). Consolidating everything in create_spice_session() avoids that inconsistency.
* session-spice: Only update displays geometry if the agent is connectedFabiano Fidêncio2015-06-021-3/+8
|
* cosmetic: move the "break" to inside the {} blockFabiano Fidêncio2015-04-221-1/+1
|
* spice-session: use the error message, when available, on _channel_destroy()Fabiano Fidêncio2015-04-221-1/+4
|
* session-spice: Destroy the channel instead of emit a "session-disconnect" signalFabiano Fidêncio2015-04-221-2/+2
| | | | | | | | Whenever we reach these branches, we will abort or have to create a new spice session (from the dialog showed to the user). So, destroying the channel on these situations seems sane enough. It also avoids an error dialog to be popped out twice with (basically) the same information.
* session-spice: Do not use _UNUSED for used attributesFabiano Fidêncio2015-04-221-1/+1
| | | | channel attribute is actually used for error treatment
* SessionSpice: Protect against unreffing window twiceJonathon Jongsma2015-04-151-2/+1
| | | | | | In theory, the dispose method can be called multiple times, so any member variables that are unreffed should be set to NULL so that we don't accidentally unref them multiple times.
* Cleanup: only add display when it's createdJonathon Jongsma2015-04-091-3/+2
| | | | | | | | This wasn't causing any problems because the _add_display() function has an early return for the case that the display has already been added to the session, but it's quite confusing when reading the code to see this _add_display() function being called for every display every time we get a monitor configuration update.
* display-spice: Do not ignore change of positionPavel Grunt2015-04-091-2/+3
| | | | | | | | Positions of displays can be changed by guest, it is important to react to this change by rearranging client's windows otherwise mouse actions can be assigned to a wrong window. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1206216
* Fix leak in virt_viewer_session_spice_clear_displays()Christophe Fergeau2015-04-071-0/+1
| | | | | The GList returned by spice_session_get_channels() must be freed after use.
* session-spice: Remove spice-gtk version checksPavel Grunt2015-04-021-11/+0
| | | | | Since 77ac0d8892837a117f9ca10020c1ac7f1944fca7 virt-viewer requires spice-gtk v0.28
* Fix virt-viewer --reconnect crash with SPICE VMsChristophe Fergeau2015-04-011-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using virt-viewer --reconnect, virt-viewer currently crashes when a SPICE VM is destroyed with "virsh destroy" What happens is that when the guest is destroyed, virt-viewer receives a SPICE_CHANNEL_ERROR_IO notification in virt_viewer_session_spice_main_channel_event(). This triggers the emission of the "session-disconnected" signal, which will end up calling spice_session_disconnect() (indirectly through virt_viewer_app_disconnected/virt_viewer_app_deactivate). Since spice-gtk commit ff25f3e, the actual session disconnection is done from an idle. When the "session-disconnected" emission stops, the VirtViewerSession instance is destroyed. However, the associated VirtViewerDisplaySpice are still alive as the various SpiceChannels instances hold a reference through the "virt-viewer-displays" GObject data. These channels are destroyed when the idle queued by spice_session_disconnect() run. The associated VirtViewerDisplay are in turn destroyed too, but this causes attempts to use the VirtViewerSession associated with the displays, which has already been destroyed. This causes a crash. This commit adds a virt_viewer_session_spice_clear_displays() which is similar to virt_viewer_session_clear_displays(), but makes sure the "virt-viewer-displays" references are dropped too. This ensures the VirtViewerDisplay instances don't outlive the VirtViewerSession they are associated with. Backtrace for the crash: #0 0x0000000000413f0f in display_show_hint (display=0x85ab50 [VirtViewerDisplaySpice], pspec=0x939bd0 [GParamFlags], user_data=0x0) at virt-viewer-app.c:949 #4 0x00000031ff22a29f in <emit signal notify:show-hint on instance 0x85ab50 [VirtViewerDisplaySpice]> (instance=instance@entry=0x85ab50, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3361 #1 0x00000031ff20fc45 in g_closure_invoke (closure=0xa98f50, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7fffffffc700, invocation_hint=invocation_hint@entry=0x7fffffffc680) at gclosure.c:768 #2 0x00000031ff2214c9 in signal_emit_unlocked_R (node=node@entry=0x674f80, detail=detail@entry=1678, instance=instance@entry=0x85ab50, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffc700) at gsignal.c:3549 #3 0x00000031ff229ed0 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffc8d0) at gsignal.c:3305 #5 0x00000031ff214175 in g_object_dispatch_properties_changed (object=0x85ab50 [VirtViewerDisplaySpice], n_pspecs=<optimized out>, pspecs=<optimized out>) at gobject.c:1056 #6 0x00000031ff216661 in g_object_notify (pspec=0x939bd0 [GParamFlags], object=0x85ab50 [VirtViewerDisplaySpice]) at gobject.c:1149 #7 0x00000031ff216661 in g_object_notify (object=0x85ab50 [VirtViewerDisplaySpice], property_name=<optimized out>) at gobject.c:1197 #8 0x000000000041e5ab in virt_viewer_display_set_show_hint (self=0x85ab50 [VirtViewerDisplaySpice], mask=1, enable=0) at virt-viewer-display.c:691 #9 0x000000000042b62d in update_display_ready (self=0x85ab50 [VirtViewerDisplaySpice]) at virt-viewer-display-spice.c:145 #13 0x00000031ff22a29f in <emit signal notify:ready on instance 0x898590 [SpiceDisplay]> (instance=instance@entry=0x898590, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3361 #10 0x00000031ff20fc45 in g_closure_invoke (closure=0x99b280, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7fffffffcc50, invocation_hint=invocation_hint@entry=0x7fffffffcbd0) at gclosure.c:768 #11 0x00000031ff2214c9 in signal_emit_unlocked_R (node=node@entry=0x674f80, detail=detail@entry=1696, instance=instance@entry=0x898590, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffcc50) at gsignal.c:3549 #12 0x00000031ff229ed0 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffce20) at gsignal.c:3305 #14 0x00000031ff214175 in g_object_dispatch_properties_changed (object=0x898590 [SpiceDisplay], n_pspecs=<optimized out>, pspecs=<optimized out>) at gobject.c:1056 #15 0x00000031ff216661 in g_object_notify (pspec=0xa83370 [GParamBoolean], object=0x898590 [SpiceDisplay]) at gobject.c:1149 #16 0x00000031ff216661 in g_object_notify (object=0x898590 [SpiceDisplay], property_name=<optimized out>) at gobject.c:1197 #17 0x00007ffff7522525 in update_ready (display=0x898590 [SpiceDisplay]) at spice-widget.c:236 #18 0x00007ffff752257e in set_monitor_ready (self=0x898590 [SpiceDisplay], ready=0) at spice-widget.c:244 #19 0x00007ffff75274e6 in primary_destroy (channel=0x89f5c0 [SpiceDisplayChannel], data=0x898590) at spice-widget.c:2169 #20 0x00007ffff7528918 in channel_destroy (s=0x909fa0 [SpiceSession], channel=0x89f5c0 [SpiceDisplayChannel], data=0x898590) at spice-widget.c:2484 #24 0x00000031ff22a29f in <emit signal ??? on instance 0x909fa0 [SpiceSession]> (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3361 #21 0x00000031ff20fc45 in g_closure_invoke (closure=0xa9bda0, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7fffffffd280, invocation_hint=invocation_hint@entry=0x7fffffffd200) at gclosure.c:768 #22 0x00000031ff2214c9 in signal_emit_unlocked_R (node=node@entry=0x9c17d0, detail=detail@entry=0, instance=instance@entry=0x909fa0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffd280) at gsignal.c:3549 #23 0x00000031ff229ed0 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffd450) at gsignal.c:3305 #25 0x00007ffff71c3248 in spice_session_channel_destroy (session=0x909fa0 [SpiceSession], channel=0x89f5c0 [SpiceDisplayChannel]) at spice-session.c:2217 #26 0x00007ffff71bd8b2 in session_disconnect (self=0x909fa0 [SpiceSession], keep_main=0) at spice-session.c:281 #27 0x00007ffff71c1b27 in session_disconnect_idle (self=0x909fa0 [SpiceSession]) at spice-session.c:1853 #28 0x00000031fee4a0ba in g_main_context_dispatch (context=0x6a4400) at gmain.c:3122 #29 0x00000031fee4a0ba in g_main_context_dispatch (context=context@entry=0x6a4400) at gmain.c:3737 #30 0x00000031fee4a450 in g_main_context_iterate (context=0x6a4400, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3808 #31 0x00000031fee4a772 in g_main_loop_run (loop=0x9890f0) at gmain.c:4002 #32 0x0000003babc05f75 in gtk_main () at gtkmain.c:1219 #33 0x000000000043143b in main (argc=1, argv=0x7fffffffda48) at virt-viewer-main.c:12
* Monitor config at sometimes leaves additional monitors enabledJonathon Jongsma2015-03-231-5/+8
| | | | | | | | | | | | | | | | | | | | | | | When using the configuration file to specify which remote monitors should be enabled when using the --full-screen option, it sometimes left additional displays enabled, or didn't place the displays on the right monitor, or didn't fullscreen them. This was especially true when not enabling the first display on the remote host. For example: monitor-mapping=2:2;3:3 (note that configuration file uses 1-based indexes, rather than 0-based indexes, so the numbers used below will be 1 less than those above) Previously, when performing fullscreen auto-conf, we were configuring displays starting at #0 and ending at ndisplays. So for the previous configuration, we looped from i = 0 to i < 2 (i.e. display #0 and #1) even though we should have configured display #1 and #2. After this fix, we configure the exact displays that were specified in the monitor-mapping configuration. Resolves: rhbz#1200750
* Add virt_viewer_session_can_share_folder()Marc-André Lureau2015-03-051-0/+9
| | | | | Functions name says it all, it is only implement for Spice, checking for webdav channel presence.
* spice: enable/disable share folderMarc-André Lureau2015-03-051-0/+28
| | | | Connect/disconnect webdav channel to enable or disable sharing folder
* spice: sync share folder preferences with sessionMarc-André Lureau2015-03-041-0/+7
|
* misc: add a missing "static" for functionMarc-André Lureau2015-03-041-1/+1
|
* spice: calling VirtViewerSession:close() can destroy selfMarc-André Lureau2014-12-011-0/+7
| | | | | | | | | | | | | | | | | 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)
* spice: use virt_viewer_signal_connect_objectMarc-André Lureau2014-11-251-25/+30
| | | | | | 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.
* Check for spice-gtk 0.26 instead of a git snapshot of 0.25Daniel P. Berrange2014-11-041-1/+1
| | | | | | 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.
* Shift top-left display to originJonathon Jongsma2014-10-271-5/+15
| | | | | | | | | | | | | | 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.
* Check for the right spice version in session-spice.cFabiano Fidêncio2014-10-161-1/+1
| | | | | | 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.
* Prefill the username in the authentication dialogFabiano Fidêncio2014-10-101-6/+10
| | | | | Lets prefill the username entry using the user name of the current user.
* Use 'username' property from .vv file for spice-sessionFabiano Fidêncio2014-10-101-0/+7
|
* Ask for username when connecting with SASLFabiano Fidêncio2014-10-101-3/+26
| | | | | When connecting with SASL for authentication, some authentication mechanisms need a username (the plain text and md5 ones, for example).
* Let the user cancel the SPICE auth dialogFabiano Fidêncio2014-09-261-3/+3
| | | | | | | 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.
* Don't show extra screens in fullscreen modeJonathon Jongsma2014-09-241-0/+3
| | | | | | | | | | | | | | 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
* Force displays to update geometry when agent connectsFabiano Fidêncio2014-08-191-0/+4
| | | | | | | | We have to force displays to update geometry when the agent connects to ensure the client will have the guest with the right resolution when the guest has rebooted or the agent has crashed. https://bugzilla.redhat.com/sho_bug.cgi?id=1021841
* Don't use fallback ca-file when launching vv-fileJonathon Jongsma2014-08-151-1/+4
| | | | | | | | | When launching from a vv-file, we want to use the ca specified in the vv file and not load additional certs from the fallback ca-file. This ensures that the ca-file property of the spice session is unset when loading a ca from a vv-file. Resolves: rhbz#1127762
* Change per-guest fullscreen config formatJonathon Jongsma2014-08-071-1/+1
| | | | | | | | | | | use <display>:<monitor>;<display>:<monitor> instead of simply implying the display from the array index (e.g. <monitor>;<monitor>). This allows you to set up sparse guest displays (e.g. display 1 + 3). For example, to configure display 1 to be fullscreen on monitor 2 and display 2 to be fullscreen on monitor 3: monitor-mapping=1:2;2:3
* Add a dialog showing details of the current guestJonathon Jongsma2014-08-071-2/+17
| | | | | | This allows the user to obtain the GUID and vm name of the currently-connected guest. Obviously, this only works with spice. In the future, it will allow them to set guest-specific configuration options (using a GUID as a key)
* spice: avoid crash if connection failed without errorMarc-André Lureau2014-07-211-1/+1
| | | | spice_channel_get_error() is not guarantee to return a GError.
* app: report disconnection error detailsMarc-André Lureau2014-07-081-4/+4
| | | | | | It may be useful to provide more detailed reason for disconnection. https://bugzilla.redhat.com/show_bug.cgi?id=1115986
* Fix a floating display warningMarc-André Lureau2014-06-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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=
* Replace DEBUG_LOG with g_debugMarc-André Lureau2014-06-101-24/+24
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1107518
* Fix building with older spice-gtkMartin Kletzander2014-03-141-4/+9
| | | | | | | | | | | | | | | | | | | 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>
* spice: ask credentials for proxyMarc-André Lureau2014-02-241-5/+35
| | | | | If Spice proxy requires authentication, ask credentials and try connecting again.
* Fix a gcc warning when compiling with mingw32Marc-André Lureau2014-02-241-1/+1
|
* Do all display alignment in virt-viewerJonathon Jongsma2013-11-271-5/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
generated by cgit (git 2.34.1) at 2025-09-26 18:37:54 +0000