On Mon, Nov 25, 2024 at 03:54:40PM -0500, Andrew Keesler wrote: > 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.
Currently we have 'xres' and 'yres' properties set against the device for virtio-gpu. If we're going to extend it to allow the name of each "output" head to be configured, it makes sense to allow for a data structure that will let us also cnofigure xres & yres per output. Hence, I thought it would make more sense to have an array of structs, rather than the simpler array of strings, which will let us set any amount of per-output config data we might want in future. NB, I'm not asking you to wire up support for xres/yres per output, just that we anticipate it as a possibility. > > 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. I'd suggest putting it in virtio_gpu_base_device_realize, as we already have code there to validate 'max_outputs" is within limits. 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 :|
