On 05/09/2016 07:30 AM, Pavel Hrdina wrote: > On Sun, May 08, 2016 at 01:49:06PM -0400, Cole Robinson wrote: >> Reports a tristate enum value for acceptable graphics type=spice >> <gl enable=XXX/>. >> >> Wire it up for qemu too. 'no' is always a valid value, so we >> unconditionally report it. >> --- > > [...] > >> diff --git a/tests/domaincapsschemadata/domaincaps-full.xml b/tests/domaincapsschemadata/domaincaps-full.xml >> index 2f529ff..4eb5637 100644 >> --- a/tests/domaincapsschemadata/domaincaps-full.xml >> +++ b/tests/domaincapsschemadata/domaincaps-full.xml >> @@ -47,6 +47,11 @@ >> <value>desktop</value> >> <value>spice</value> >> </enum> >> + <enum name='spiceGL'> >> + <value>default</value> >> + <value>yes</value> >> + <value>no</value> >> + </enum> > > Ewww, this doesn't look good and I agree with Michal that what if we add > support for another graphics device and what if one graphics device will have > more than one capability? > > I would suggest something like this: > > <graphics supported='yes'> > <enum name='type'> > <value>spice</value> > <value>vnc</value> > <value>sdl</value> > </enum> > <type name='spice'> > <gl supported='yes'/> > </type> > </graphics> > > or even do something like this: > > <graphics supported='yes'> > <type name='spice'> > <gl supported='yes'/> > </type> > <type name='vnc'/> > <type name='sdl'/> > </graphics> > Really wish someone would have chimed in with this to my (unresponded) RFC email about these things... http://www.redhat.com/archives/libvir-list/2016-April/msg01839.html That pattern is fine in this case, but what about the case of ports= element that is only supported with a controller type=usb model=nec-xhci ? Do we have new XML like: <controller supported='yes'> <type name='usb'> <model name='nec-xhci'/> <param name='ports' supported='yes'/> </model> </type> </controller> It seems like these types of relationships could grow deeply nested, so I opted for following the limited existing convention of adding unique enum names to represent the relationship. I'm not really opposed to the nesting, but I'd like others on the list to state their preference before I rework this Thanks, Cole -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list