On 7/9/2023 11:05 PM, Markus Armbruster wrote:
"Kim, Dongwon" <dongwon....@intel.com> writes:
On 7/7/2023 7:07 AM, Markus Armbruster wrote:
"Kim, Dongwon" <dongwon....@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".
yeah, I will update it in v2 and send the new patch shortly.
Ignorant questions:
1. How would I plug / unplug display cables?
I am not sure if I understood your question correctly but 1 or more guest
displays (GTK windows) are bound to a certain physical displays like HDMI or DP
monitors. So plug/unplug means we disconnect those physical HDMI or DP cables
manually. Or this manual hot plug in can be emulated by you write something to
sysfs depending on what display driver you use.
Let's see whether I understand.
A VC is placed on a *physical* monitor, i.e. a window appears on that
monitor. That monitor's plug / unplug state is passed through to the
guest, i.e. if I physically unplug / plug the monitor, the guest sees an
unplug / plug of its virtual monitor. Correct?
This is correct. When a display is disconnected, "monitor-changed" GTK
event will be triggered then it will call gd_ui_size(0,0) which makes
the guest display connection status to "disconnected".
Permit me another ignorant question... Say I have a single monitor. I
configured my X windows manager to show four virtual desktops. Can I
use your feature to direct on which virtual desktop each VC is placed?
Would those virtual desktops will be their own connector names like HDMI
or DP? We use the connector name for the actual physical display you see
when running xrandr. I don't know how virtual desktops are created and
managed but if they don't have their own connector names that GTK API
can read, it won't work within our current implementation.
2. If I connect multiple VCs to the same display, what will I see? Are
they multiplexed somehow?
Yeah multiple VCs will be shown on that display. But those could be overlapped
since those are all placed at (0, 0) of display in many cases.. but this all
depends on how the windows manager determines the starting locations.
Got it, thanks!
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?
No, it doesn't have to be dense. In your example, you can just leave the place
for VC1 blank. For example, you could do connectors.0=DP-1,connectors.2=HDMI-1.
But in this case, VC1 won't be activated and stay as disconnected from guest's
perspective. I think this info is also needed in v2.
Have you tried this? I believe it'll fail with something like
"Parameter 'connectors.1' missing".
Just tested it. Yeah you are correct. I think I had a bad assumption.
Let me take a look to see if I can make it work as I assumed.
[...]
