Re: [RFC PATCH 6/9] ui/gtk: Add a new parameter to assign connectors/monitors to GFX VCs

[Markus Armbruster <armbru@redhat.com>]

"Kim, Dongwon" <dongwon.kim@intel.com> writes:

> Hi Markus,
>
> So I've worked on the description of this param. Can you check if this new version looks ok?
>
> # @connectors:  List of physical monitor/connector names where the GTK
> #           windows containing the respective graphics virtual consoles (VCs)
> #           are to be placed. Index of the connector name in the array directly
> #           indicates the id of the VC.
> #           For example, with "-device gtk,connectors.0=DP-1, connectors.1=DP-2",
> #           a physical display connected to DP-1 port will be the target monitor
> #           for VC0 and the one on DP-2 will be the target for VC1. If there is
> #           no connector associated with a VC, then that VC won't be placed anywhere
> #           before the QEMU is relaunched with a proper connector name set for it.
> #           If a connector name exists for a VC but the display cable is not plugged
> #           in when guest is launched, the VC will be just hidden but will show up
> #           as soon as the cable is plugged in. If a display is connected in the beginning
> #           but later disconnected, VC will immediately be hidden and guest will detect
> #           it as a disconnected display. This option does not force 1 to 1 mapping
> #           between the connector and the VC, which means multiple VCs can be placed
> #           on the same display but vice versa is not possible (a single VC duplicated
> #           on a multiple displays)
> #           (Since 8.1)

Better!

Suggest to replace "that VC won't be placed anywhere" by "that VC won't
be displayed".

Ignorant questions:

1. How would I plug / unplug display cables?

2. If I connect multiple VCs to the same display, what will I see?  Are
they multiplexed somehow?

Old question not yet answered: Using a list for the mapping means the
mapping must be dense, e.g. I can't map #0 and #2 but not #1.  Is this
what we want?

[...]