On 05/09/2016 05:26 AM, Michal Privoznik wrote:
On 08.05.2016 19:49, Cole Robinson wrote:
> Reports a tristate enum value for acceptable graphics type=spice
> <gl enable=XXX/>.
This ^^ is part of graphics element as follows:
<graphics>
<gl enable='yes'/>
</graphics> ..
>
> Wire it up for qemu too. 'no' is always a valid value, so we
> unconditionally report it.
> ---
> docs/formatdomaincaps.html.in | 8 ++++++++
> src/conf/domain_capabilities.c | 1 +
> src/conf/domain_capabilities.h | 1 +
> src/qemu/qemu_capabilities.c | 4 ++++
> tests/domaincapsschemadata/domaincaps-full.xml | 5 +++++
> tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml | 3 +++
> tests/domaincapsschemadata/domaincaps-qemu_2.6.0-1.xml | 4 ++++
> tests/domaincapsschemadata/domaincaps-qemu_2.6.0-2.xml | 3 +++
> tests/domaincapsschemadata/domaincaps-qemu_2.6.0-3.xml | 3 +++
> tests/domaincapsschemadata/domaincaps-qemu_2.6.0-4.xml | 3 +++
> tests/domaincapsschemadata/domaincaps-qemu_2.6.0-5.xml | 3 +++
> tests/domaincapstest.c | 1 +
> 12 files changed, 39 insertions(+)
>
> diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in
> index d5a8414..c424107 100644
> --- a/docs/formatdomaincaps.html.in
> +++ b/docs/formatdomaincaps.html.in
> @@ -231,6 +231,10 @@
> <value>vnc</value>
> <value>spice</value>
> </enum>
> + <enum name='spiceGL'>
> + <value>yes</value>
> + <value>no</value>
> + </enum>
> </graphics>
.. and while it's true that just Spice supports OpenGL currently, I'd
vote for a less specific naming. BTW: wasn't virgl implemented for SDL
initially? I know we don't support it, but my point is, what if XYZ
graphics type gains support for something equivalent to virgl? Would we
end up having yet another 'xyzGL' enum? Well, on the other hand, we
already have pciBackend enum to hostdev elem where we report VFIO/KVM
caps for hostdev[@type='pci']/driver/@name.
So I guess it's your call whether to change this or not. The only name I
can suggest right now (if you're out of ideas) is just 'gl'.
I think just reporting <enum name='gl'/> gives insufficient info to apps.
What
if hypothetically VNC starts support 3D... then apps have no way of
distinguishing which libvirt+qemu combos support spice + 3D vs the new VNC +
3D, and they are stuck in the current position of trying to guess what is
supported by checking libvirt version numbers.
So IMO the domcaps need to report this fine grained value some how. Either
this way or the XML suggested by Pavel, please give your thoughts there as well
Thanks,
Cole