summaryrefslogtreecommitdiffstats
path: root/src/virt-viewer-display-spice.c
Commit message (Collapse)AuthorAgeFilesLines
* Drop support to gtk2Fabiano Fidêncio2016-02-151-1/+1
| | | | | | | | The 3.0 release was the last one that still supports GTK2. For the Windows builds the support to GTK2 was dropped in the previous release. Let's do the same for the entire project now. Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
* Add new functions to enable/disable a displayJonathon Jongsma2015-09-101-4/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Don't emit 'monitor-geometry-changed' for disabled displaysJonathon Jongsma2015-09-081-20/+19
| | | | | | | | | 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.
* display-spice: Do not ignore change of positionPavel Grunt2015-04-091-0/+27
| | | | | | | | 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
* Don't unref 'display' in VirtViewerDisplaySpice::finalizeChristophe Fergeau2014-09-231-13/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove extra ref on SpiceDisplayJonathon Jongsma2014-09-111-1/+1
| | | | | There's no need to ref the SpiceDisplay widget when adding it to a container. The container will take its own ref.
* Fix gtk2 buildJonathon Jongsma2014-04-081-1/+1
| | | | | | | Previous commit accidentally broke gtk2 build by using gtk_widget_get_preferred_size(). We can't simply use gtk_widget_size_request() for the gtk2 build since this will generally return 50x50 whenever we're not in the middle of a resize, so we need to add a compatibility function.
* Fix regression with enabling additional displaysJonathon Jongsma2014-03-271-16/+20
| | | | | | | | | | | | | | | | | Commit 8fa942 broke enabling of additional displays. We don't want to send down display re-configurations due to events that happen while setting up windows for enabled displays that we recieve from the server. However, by ignoring allocations on unmapped windows, we fail to send display configurations for new displays that a user is attempting to enable via the window menu. To discriminate between these two cases, we check whether the display is in the 'ready' state or not. - Unmapped displays with the 'ready' hint set can be assumed to be displays that are enabled on the server that we are attempting to create windows for on the client. In this case, we should *not* send a display configuration to the server - Unmapped displays with the 'ready' hint cleared can be assumed to be displays that are not yet enabled on the server that we are trying to enable in the client. In this case, we *should* send a display configuration to the server
* Fix broken 'release-cursor' accel when not specified in --hotkeysJonathon Jongsma2014-03-131-2/+5
| | | | | | | | | | | | | | | | | | | | | | 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.
* Don't resize guest display on zoom changeJonathon Jongsma2014-03-131-1/+20
| | | | | | | | | | | | | | | | | | | | 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
* Remove "Automatically resize" menuMarc-André Lureau2014-03-131-5/+0
| | | | | | | Remove "Automatically resize" menu item (always enabled for Spice display now) https://bugzilla.redhat.com/show_bug.cgi?id=1007649
* Revert "Don't resize guest display on zoom change"Jonathon Jongsma2014-03-061-14/+1
| | | | This reverts commit 895ef8029e794e7b74a45f27c7c741d1332bc02b.
* Don't resize guest display on zoom changeJonathon Jongsma2014-02-261-1/+14
| | | | | | | | | | | | | | | | | | | | 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
* Don't re-configure displays when show-hint changesJonathon Jongsma2013-11-271-2/+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.
* Do all display alignment in virt-viewerJonathon Jongsma2013-11-271-71/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Drop basic fullscreen modeJonathon Jongsma2013-11-131-1/+1
| | | | | | Remove the distinction between --full-screen and --full-screen=auto-conf. Just make --full-screen behave like auto-conf did. There's really no advantage to having two slightly different fullscreen startup modes.
* VirtViewerDisplaySpice: use enum type for auto_resizeJonathon Jongsma2013-10-181-7/+8
| | | | | Instead of storing the auto_resize member as an integer, use the enum, it makes it slightly easier for debugging. Also, explicitly initialize the value.
* spice: if zoom-level is changed, resize guest, even in fullscreenMarc-André Lureau2013-07-301-0/+16
|
* spice: factor out spice resize code from gtk signal handlerMarc-André Lureau2013-07-301-4/+14
| | | | | This will allow that part of the code to be called with a different resize-guest setting.
* Use display fullscreen state instead of app stateMarc-André Lureau2013-07-051-6/+6
| | | | | | | | This is a recent regression introduced by independant fullscreen windows support, which reopened the bug "Resolution higher than native could not be set in fullscreen" https://bugzilla.redhat.com/show_bug.cgi?id=864929
* spice: make sure display ready hint is sync after creationMarc-André Lureau2013-05-131-7/+7
| | | | | The ready state can be set during construction time and not notified immediately.
* Do not enable extra monitors until they are explicitely enabledMarc-André Lureau2013-03-281-2/+3
|
* virt-viewer-display-spice: Skip monitor info in fullscreen-auto-conf modeHans de Goede2013-03-231-2/+9
| | | | | | | | | When we are in fullscreen-auto-conf virt-viewer-session-spice sends a monitor-info message to the agent with the exact client monitor info, and virt-viewer-display-spice should not override that. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
* virt-viewer-display-spice: Use display monitor property for fullscreen sizeHans de Goede2013-03-201-1/+3
| | | | | | | | | | | | | | | | When a display is pinned to a certain monitor for fullscreen, it will be moved there when going fullscreen. Currently we use gdk_screen_get_monitor_at_window to determine which monitor we are on and get the size from that monitor. But this is racy, sometimes the size_allocate function runs before the move has finished and we get the size from the wrong monitor: https://bugzilla.redhat.com/show_bug.cgi?id=918570 Since if the display is pinned to a certain monitor, the display will always end up on that monitor we can avoid the race by simply using that monitors size. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* spice: update fullscreen state on display creationMarc-André Lureau2013-03-131-0/+1
| | | | | | | This ensure self->priv->auto_resize has correct value. And allow changing guest resolution when started in fullscreen. https://bugzilla.redhat.com/show_bug.cgi?id=873298
* virt-viewer-display-spice: Pass proper x and y coordinates in windowed modeHans de Goede2013-02-061-0/+7
| | | | | | | | | | | This stops monitor order from the guest from being re-arranged in multi- monitor setups when switching between fullscreen and windowed mode. Note this relies on spice-gtk's auto monitor alignment code, which currently does not properly handle setups where there is more then 1 row of monitors, ie 2x1 - 5x1 will work fine, but 2x2 will not. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* virt-viewer-display-spice: Use real monitor coordinates in fullscreenHans de Goede2013-02-061-1/+8
| | | | | | | | | Now that we pass the real monitor coordinates, tell spice-gtk to use them, rather then to use the passed coordinates as input for its automatic monitor alignment. This fixes ie monitors in a 2x2 grid, showing up as a 4x1 configuration in the guest. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* virt-viewer-display-spice: Pass real monitor coordinates in fullscreenHans de Goede2013-02-061-1/+4
| | | | | | Rather then always passing +0+0 Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* Remove unused variableChristophe Fergeau2013-01-241-1/+0
| | | | 'window' is no longer used after 412bcf6f.
* virt-viewer-display-spice: Get monitor under our windowHans de Goede2013-01-221-1/+2
| | | | | | | | | | | When getting monitor info for going fullscreen, Get the monitor under *our* window rather then under the root-window. Noticed this not working properly when testing the monitor coordinates stuff, but this should also help people seeing problems when using non equally sized monitors. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* Improve check for overridden grab key combinationChristophe Fergeau2012-12-201-1/+2
| | | | | | | | | remote-viewer can either use the default grab/ungrab handled by spice-gtk, or override it and use the standard gtk+ accelerator mechanism. However, the code currently assumes that if any accelerator is set in remote-viewer, then the grab key has been overridden. This commit makes sure the grab key is actually overridden before assuming so.
* Don't leak SpiceGrabSequence in enable_accel_changedChristophe Fergeau2012-12-201-2/+3
|
* Use monitor geometry, not screen sizeMarc-André Lureau2012-12-071-2/+6
| | | | | | | | | | | | | In a recent commit, 3bb6f5ec805ecfe78eba6d4d98e3ffcab195273a, I introduced a regression: going fullscreen would no longer match client and guest resolution correctly. A GdkScreen is not necessarily the physical screen monitor size. Lookup the physical monitor size using gdk_screen_get_monitor_geometry(). Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=881020
* spice: only autoresize once with screen size in fullscreenMarc-André Lureau2012-10-181-2/+29
| | | | | | | | | | | | It's currently not possible to configure guest with higher resolution than native, as it will switch back to native, since the gtk widget allocation will always end up being the size of the screen. We special-case fullscreen mode, and only resize when entering fullscreen. Furthermore, it avoids sending extra unnecessary resize events to the guest whenever gtk+ call size allocate in various stages, with different values. https://bugzilla.redhat.com/show_bug.cgi?id=864929
* spice: avoid rounding issues when scaling up displayMarc-André Lureau2012-10-171-2/+3
| | | | | | | | | | | | Fix some unwanted guest resize due to rounding issues (at least when scaling up) We may want to save the original remote desktop size, instead of always checking widget requisition. That way zooming shouldn't resize guest at all, but it seems tricky to handle that special case vs user window resize that should trigger guest resize. https://bugzilla.redhat.com/show_bug.cgi?id=856678
* Simplify display flag handlingMarc-André Lureau2012-07-231-8/+1
|
* spice: factor out main channel lookup codeMarc-André Lureau2012-07-231-5/+17
|
* Add VirtViewerDisplay::selectable propertyMarc-André Lureau2012-07-231-0/+16
| | | | | | | This property will be set when the display can be selected to be "enabled" and shown (this can involve creating/connecting an additional guest monitor, and may need guest agent cooperation for example).
* Hook up handling of MonitorsMarc-André Lureau2012-07-231-8/+12
| | | | | | Rely on spice-gtk display channel monitors property to manage displays. The same display channel may now provide several monitors, the SpiceDisplay widget must be told which monitor to display
* Use SpiceDisplay:ready property instead of channel markMarc-André Lureau2012-07-231-23/+15
| | | | | | The display can now check several conditions before the display can be shown, use that instead of display mark, which was not high-level enough.
* Add a DISABLED display hintMarc-André Lureau2012-07-231-0/+20
| | | | | | | | This flag will help to track whether the display has been removed/closed and whether it really has a valid display. Ready in contrast, is used to "hide" temporarily the display (when starting or redrawing the display, to avoid artifacts)
* spice: disconnect signal handlers when either object is destroyedMarc-André Lureau2012-07-231-14/+12
| | | | | | | | | | | Use virt_viewer_signal_connect_object(), a copy of telepathy utility function tp_g_signal_connect_object(). This function will take care of removing signal handler if any of emitter or attached object are destroyed. The following patches will have this condition met, since there is no longer 1-1 relation between channel and display. The channels can continue to be around when some of the display are removed.
* spice: use weak references to display channelMarc-André Lureau2012-05-171-8/+9
| | | | | | | | | | | | Fix switch-host migration with Spice. spice-gtk doesn't like channels staying around when they should be destroyed/finalized, ie removed from session. spice-gtk should probably learned to handle better the case of non cooperating clients, and be able to dissociate a channel from a session without waiting for it to be disposed, but for now, the relation is quite tight.
* Ensure windows are destroyed when display closesDaniel P. Berrange2012-05-041-1/+1
| | | | | | | | | | | When running virt-viewer with the --reconnect argument, when the session closes, the VirtViewerWindow instances were being freed, but not the GtkWindow itself. So the orphaned window stayed around doing nothing. The GtkBuilder instance was also leaked. Fix these two leaks & also add some debugging to help future troubleshooting
* Fix close of VNC displaysDaniel P. Berrange2012-04-041-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When clicking the close button on a virt-viewer window with a VNC session open, while the VNC session terminates, the window does not go away. The problem is that the virt_viewer_session_vnc_disconnected method never gets invoked. The close button triggers a call to virt_viewer_session_clear_displays which unrefs the VirtViewerDisplayVnc instance. This in turn triggers a call to gtk_container_destroy, which destroys all widgets it contains, ie the VncDisplay * object. With the VncDisplay object in its dispose phase, no signals will ever be emitted, thus the 'vnc-disconnected' signal never gets seen. The design issue is that VirtViewerDisplayVnc is assuming it owns the VncDisplay, whereas in fact the real owner is the VirtViewerSessionVnc object. The solution is to introduce a new virt_viewer_display_close method which can be used to de-parent the widget before VirtViewerDisplay is unref'd. The VirtViewerSessionVnc object also needs to hold a full ref on the VncDisplay object, not merely a floating reference * virt-viewer-display-spice.c, virt-viewer-display.c, virt-viewer-display.h: Add virt_viewer_display_close * virt-viewer-display-vnc.c: Deparent VNC widget in virt_viewer_display_close impl * virt-viewer-session-vnc.c: Improve logging * virt-viewer-session.c: Call virt_viewer_display_close before unrefing display * virt-viewer-window.c: Improve logging Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* Display correct key bindings to release cursorMarc-André Lureau2012-03-211-0/+18
| | | | | If the accels are enabled (with Spice controller custom bindings), show the configured keybinding in the title bar.
* spice: implement smartcard-{insert,remove} virtual methodsMarc-André Lureau2012-02-221-0/+11
|
* Do not resize guest desktop if !auto-resizeMarc-André Lureau2012-02-081-0/+3
| | | | | | | | | If auto-resize is enabled, the guest desktop size will be resized to match current window*zoom size. This can be a problem if the user explicitely set the desktop size to a different resolution and want to keep it. Disabling auto-resize sounds like a simple way to allow that.
* Resize Spice guest display to the container sizeMarc-André Lureau2012-02-081-3/+3
| | | | | | | | | The SpiceDisplay doesn't receive the full allocation, because VirtViewerDisplay maintains current aspect ratio. However, the guest display can be resize up to its container size. This fixes going full-screen and not getting native resolution for instance.
* Implement SPICE desktop resizing that takes account of zoom levelDaniel P. Berrange2012-02-081-1/+33
| | | | | | | | | | | | | The standard SPICE widget guest resize implementation does not take into account the zoom level settings in virt-viewer, because it has no knowledge of this functionality. The guest resize can, however, be done by calling spice_main_set_display() directly. This allows virt-viewer to resize the guest taking into account zoom levels. ie, if virt-viewer is run with --zoom 50 and the window is resized to 400x300, then the guest agent should be told to set its resolution to 800x600
generated by cgit (git 2.34.1) at 2024-05-08 09:46:47 +0000