On 7/10/2023 11:36 PM, Markus Armbruster wrote:
"Kim, Dongwon" <dongwon....@intel.com> writes:
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:
[...]
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).
Yeah, I understand this now. Despite of my initial intention was
different, I am wondering if we don't allow the sparse mapping in this
implementation. Any thought on that? The V2 patch is with that change in
the description. Another thing I think is to change QAPI design little
bit to make it fill the element with null (0) if it's not given. Would
this be a feasible option?
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?
[...]
