1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
|
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.)
|
