mirror of
https://gitlab.com/virt-viewer/virt-viewer.git
synced 2024-12-23 17:34:01 +03:00
428c3e3fdb
These two files describe some of the behavior and requirements for virt-viewer in fullscreen multimonitor mode
99 lines
5.2 KiB
Plaintext
99 lines
5.2 KiB
Plaintext
Fullscreen Startup Mode
|
|
-----------------------
|
|
A. Default fullscreen behavior
|
|
Assume:
|
|
NG = number of displays supported by the guest
|
|
NC = number of monitors on the client
|
|
N = the lesser of NG and NC
|
|
A1. at startup, enable N displays on the guest
|
|
A2. if N == NC, map guest display X to physical monitor X
|
|
A3. if N < NC, map guest display X to physical monitor X+1 (the primary
|
|
monitor likely has an application menu, etc, so keep that free for local use)
|
|
A4. Arrange guest displays in the same geometry as the physical monitors
|
|
|
|
B. Custom monitor mapping configuration
|
|
B1. configuration file is specific to a particular user on a particular client
|
|
machine. Different users on same machine can use different
|
|
configurations.
|
|
B2. configuration only applies to fullscreen startup mode
|
|
B3. configuration should be simple to edit by hand
|
|
B4. It must be possible to specify a custom configuration for a specific
|
|
guest vm
|
|
B5. guest-specific configuration is identified by GUID
|
|
B6. It must be possible to specify a fallback configuration that will be used
|
|
for all guests without an explicit configuration
|
|
B7. It must be possible to specify how many guest displays to enable
|
|
B8. It must be possible to specify which guest display to map to which to
|
|
client monitor
|
|
B9. configuration format must be flexible and support a wide range of guest
|
|
and client configurations
|
|
B10. if the guest-specific configuration is invalid, we will attempt to use
|
|
the default/fallback configuration
|
|
B11. if the fallback configuration is invalid, we will revert to default
|
|
behavior (see A)
|
|
B12. Configuration must be considered invalid if it is not unambiguous
|
|
B13. A configuration that doesn't specify any displays will be considered
|
|
invalid
|
|
B14. if multiple configurations are given for the same guest, the last one
|
|
will be used.
|
|
|
|
- non-requirements (these are features that were considered but I propose that
|
|
they are explicitly not supported)
|
|
- no need to have separate configurations depending on how many guest
|
|
displays are currently enabled
|
|
- complicates startup (have to wait to receive display config before
|
|
setting up anything)
|
|
- complicates config file format
|
|
- the number of guest displays may have been set by another user since you
|
|
last logged in, so it's not clear to me that we want to make
|
|
configuration decisions based on something you can't control
|
|
- no need to specify the geometry arrangement of displays
|
|
- just match the arrangement of the physical monitors that the display
|
|
will be mapped to
|
|
- no need to specify different guest configurations based on client
|
|
configuration (e.g. separate guest configurations for when the client
|
|
machine has 4 monitors vs when it has 2 monitors)
|
|
- complicates config file format
|
|
- possibly unnecessary if we satisfy B9
|
|
|
|
- Implications of high-level requirements
|
|
1. per-guest display mapping will always work with virt-viewer because
|
|
virt-viewer can get the GUID from libvirt <B5>
|
|
2. per-guest display mapping may not work with *remote-viewer* in many cases.
|
|
If you're connecting to a vm on a host that is running an older version
|
|
of spice-server (e.g. RHEL6), the GUID is not sent over the spice
|
|
protocol, so remote-viewer doesn't have any way of determining a guest's
|
|
GUID <B5>
|
|
|
|
- Derived requirements
|
|
C1. Use GKeyFile <B3>
|
|
C2. need to add a 'Guest Details' dialog to virt-viewer so that the user can
|
|
determine the GUID of the guest. <B3><B5>
|
|
C3. if config file specifies more guest displays than can be enabled on the
|
|
guest, simply ignore (disable) the extra displays <B9>
|
|
C4. if config file specifies that a display should be mapped to a client
|
|
monitor that doesn't exist, that display will not be enabled <B9>
|
|
C5. if config file specifies that a given guest display will map to multiple
|
|
client monitors, it will be considered invalid <B12>
|
|
C6. if the config file specifies that multiple guest displays will map to the
|
|
same client monitor, it will be considered invalid <B12>
|
|
|
|
|
|
Normal (non-fullscreen) Startup Mode
|
|
------------------------------------
|
|
D1. Client must not change Guest configuration at startup
|
|
D2. Client must open a window for every display that is enabled on the guest
|
|
D3. Client should allow the native window manager to place the display windows
|
|
at appropriate positions
|
|
D4. Client will not prevent displays from being larger than client monitors,
|
|
but the window manager may impose some size restrictions.
|
|
D5. Toggling fullscreen mode after startup should only affect the window that
|
|
was acted upon
|
|
- currently if client is started in fullscreen mode, exiting fullscreen
|
|
mode for one window will also exit fullscreen mode for all other windows
|
|
-- that will need to be changed.
|
|
- (If fullscreen toggle worked at the application level rather than the
|
|
window level, it's much more difficult to decide what to do if there are
|
|
more windows open than client monitors. It's easier to leave those sorts
|
|
of policy decisions to the user.)
|