On Wed, Aug 27, 2025 at 11:48:34AM -0400, Andrew Keesler wrote: > Sending again (replying all this time). > > > IIUC from the current code, xres/yres are only set against the > > first head. The 2nd and later heads are left undefined by the > > virtio-gpu-base code at least - I'm unclear if something else > > in QEMU will fill in defaults later, or if they set to 0x0. > > That is correct - xres/yres are only set against the first head in the > current code. The wording in my commit message (and cover letter) was > misleading. I will fix that to say that "If no > virtio_gpu_base_conf.outputs are provided, > virtio_gpu_base_conf.xres/virtio_gpu_base_conf.yres will still be > respected _for the first head_ for backwards compatibility". > > The only way I could get QEMU to fill in xres/yres for a 2nd and later > head was to trigger virtio_gpu_ops.ui_info via a VNC client. > > > Is it relevant to set xres/yres on outputs, even when they are > > not (yet) enabled ? Perhaps we should have an explicit 'enabled: bool' > > property in the 'outputs' struct ? > > Maybe you might want to set xres/yres on an output, but not enable it > yet? I don't have any concrete examples of when you might want to do > that, maybe you have some examples?
No, I don't have an example. > I feel like I could see a user setting xres/yres on an output, > forgetting to set enabled on that output, and then being confused why > their head is blank. Because of this, my vote would be to default to > enabling an output when it has configuration. I am easily swayed by > your guidance, though. Ok, lets just document that setting xres/yres will cause the output to be automatically enabled. We can always retrofit an 'enabled' property at a later date if someone arrives with a use case for setting res without enabling the output. 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 :|
