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:

> On 7/9/2023 11:05 PM, Markus Armbruster wrote:
>> "Kim, Dongwon" <dongwon.kim@intel.com> writes:
>>
>>> On 7/7/2023 7:07 AM, Markus Armbruster wrote:

[...]

>>>> 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".

Thanks!

>> 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.

Output of xrandr is identical on different virtual desktops for me.

> 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.

After searching around a bit...  Virtual desktops, a.k.a. workspaces,
are a window manager thing.  Completely different from X displays and
monitors.  Programs can mess with placement (wmctrl does).  No idea
whether GDK provides an interface for it.  No need to discuss this
further at this time.

[...]

>>>> 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.

If sparse mappings make sense, we should provide for them, I think.

An array like '*connectors': ['str'] maps from integers 0, 1, ...  It
can't do sparse (you can't omit integers in the middle).

Instead of omitting them, we could map them to null: '*connectors':
['StrOrNull'].  JSON input looks like [null, "HDMI-A-0"].  Since dotted
key syntax does not support null at this time, you'd have to use JSON.

Only an object can do sparse.  However, the QAPI schema language can't
express "object where the keys are integers and the values are strings".
We'd have to use 'any', and check everything manually.

Hmm.  Thoughts?

>>>> [...]