On Wed, Jun 24, 2015 at 06:34:50AM -0400, Frediano Ziglio wrote:
On Fri, Jun 12, 2015 at 11:57:31AM +0100, Frediano Ziglio wrote: >Allows to specify maximum number of head to QXL driver. > >Signed-off-by: Frediano Ziglio <fzig...@redhat.com> > >The patch to support the "max_outputs" in Qemu is still not merged but >I got agreement on the name of the argument. > >Actually can be a compatiblity problem as heads in the XML configuration >was set by default to '1'. Could we avoid that by passing the value to QEMU only if it's greater than 1?And what about if I just want one monitor ? Specify a "one" value ?
Well, it probably depends on what the default is and how QEMU handles it. I guess we could just leave it as is. This controls only the maximum anyway, right? I think the client itself is supposed to control the actual number of displays, isn't it?
>--- > src/qemu/qemu_capabilities.c | 3 +++ > src/qemu/qemu_capabilities.h | 1 + > src/qemu/qemu_command.c | 5 +++++ > tests/qemucapabilitiesdata/caps_1.2.2-1.caps | 1 + > tests/qemucapabilitiesdata/caps_1.2.2-1.replies | 8 ++++++++ > tests/qemucapabilitiesdata/caps_1.3.1-1.caps | 1 + > tests/qemucapabilitiesdata/caps_1.3.1-1.replies | 8 ++++++++ > tests/qemucapabilitiesdata/caps_1.4.2-1.caps | 1 + > tests/qemucapabilitiesdata/caps_1.4.2-1.replies | 8 ++++++++ > tests/qemucapabilitiesdata/caps_1.5.3-1.caps | 1 + > tests/qemucapabilitiesdata/caps_1.5.3-1.replies | 8 ++++++++ > tests/qemucapabilitiesdata/caps_1.6.0-1.caps | 1 + > tests/qemucapabilitiesdata/caps_1.6.0-1.replies | 8 ++++++++ > tests/qemucapabilitiesdata/caps_1.6.50-1.caps | 1 + > tests/qemucapabilitiesdata/caps_1.6.50-1.replies | 8 ++++++++ > tests/qemucapabilitiesdata/caps_2.1.1-1.caps | 1 + > tests/qemucapabilitiesdata/caps_2.1.1-1.replies | 8 ++++++++ Why do you put it in outputs of all QEMU versions if it's not merged yet?To pass the checks
That doesn't make sense. Each file is for each specific QEMU version. The .caps and .replies must match, but they don't all need to be the same. What would be the benefit then?
Frediano -- libvir-list mailing list libvir-l...@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
