I follow what you are saying. I misunderstood what a "display" was in the
domain of QEMU. Yes, this makes more sense now.
> the user should give names for every output at startup
I see DEFINE_PROP_ARRAY exists. I can use that to define the new "outputs"
property. Any reason that each "output" would ever need to be an object
(rather than just a string)? Nothing comes to mind, I'm just taking a second
to think about API forwards compatibility.
> upto whatever they said for "max_outputs"
Where is the best place to perform this validation? I would imagine we would
want to fast-fail if the user provided more "outputs" than "max_outputs". I
can
perform the validation in virtio_gpu_base_get_features but that seems late.
Thanks for your help.
On Mon, Nov 25, 2024 at 7:04 AM Daniel P. Berrangé <berra...@redhat.com>
wrote:
> On Thu, Oct 17, 2024 at 09:53:04PM +0000, Roque Arcudia Hernandez wrote:
> > From: Andrew Keesler <ankees...@google.com>
> >
> > Thanks to 72d277a7, 1ed2cb32, and others, EDID (Extended Display
> Identification
> > Data) is propagated by QEMU such that a virtual display presents
> legitimate
> > metadata (e.g., name, serial number, preferred resolutions, etc.) to its
> > connected guest.
> >
> > This change adds the ability to specify the EDID name for a particular
> > virtio-vga display. Previously, every virtual display would have the
> same name:
> > "QEMU Monitor". Now, we can inject names of displays in order to test
> guest
> > behavior that is specific to display names. We provide the ability to
> inject the
> > display name from the display configuration as that most closely
> resembles how
> > real displays work (hardware displays contain static EDID information
> that is
> > provided to every connected host).
> >
> > This new behavior must be enabled by setting the edid_name boolean
> property on
> > the display device (it is disabled by default).
> >
> > It should be noted that EDID names longer than 12 bytes will be
> truncated per
> > spec (I think?).
> >
> > Testing: verified that when I specified 2 outputs for a virtio-gpu with
> > edid_name set, the names matched those that I configured with my vnc
> display.
> >
> > -display vnc=localhost:0,id=aaa,display=vga,head=0,name=AAA \
> > -display vnc=localhost:1,id=bbb,display=vga,head=1,name=BBB \
> > -device virtio-vga,max_outputs=2,id=vga,edid_name=true
>
> Looking at this again, I'm thinking that it modelling this the wrong
> way around.
>
> On the QEMU side, we have a many<->many relationship between guest
> display devices and host / remote display outputs.
>
> If we assume every host / remote display output corresponds to a
> separate "window" though, then we can reduce that down to a
> many:one relationship between host outputs and guest devices.
>
> Consider this valid config:
>
> $ qemu-system-x86_64 \
> -vnc :1 \
> -spice port=5902,disable-ticketing \
> -display gtk \
> -device virtio-vga,max_outputs=2,id=vga
>
> All three display outputs show the same guest display, so which
> of VNC, SPICE & GTK would the virtio-vga EDID data take its names
> from ?
>
> IMHO, the name is a property of the virtio-vga "output" and the
> various display backends should be honouring what that tells them
> ie your configuration above should instead be:
>
> -display vnc=localhost:0,id=aaa,display=vga,head=0 \
> -display vnc=localhost:1,id=bbb,display=vga,head=1 \
> -device '{"driver":"virtio-vga",
> "max_outputs":2,
> "id":"vga",
> "outputs":[
> {
> "name":"AAA",
> },
> {
> "name":"BBB",
> },
> ]}'
>
> ..whereupon we have to feed the EDID name from the device back to VNC,
> so VNC can tell the client of the head name.
>
> Note, I'm intentionally using JSON syntax for -device here, to illustrate
> handling of non-scalar properties.
>
> The set of active outputs can be turned on/off at runtime. We can declare
> that the user should give names for every output at startup, upto whatever
> they said for "max_outputs". That way a name is available even when non-
> primary outputs are later turned on at runtime.
>
> The secondary reason why I think names ought to be handled with -device
> is that this is guest visible data, and as a general rule we aim for all
> guest visible data to be controlled via properties on the frontend, and
> not have the backend directly change what the guest sees.
>
> With regards,
> Daniel
> --
> |: https://berrange.com -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org -o-
> https://www.instagram.com/dberrange :|
>
>
