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