[...]
>>> + /* Next we need to figure out how to properly configure the OpenGL
>>> + * if that is enabled and the 'native' attribute is missing.
>>> + * The cases are:
>>> + * 1) Listen type is either 'socket' or 'none' - SPICE native
>>> + * OpenGL support (,gl=on) should be used because we're
>>> + * rendering on a local display.
>>> + *
>>> + * 2) Listen is either network or address - SPICE can't use
>>> + * the native OpenGL support remotely yet, so we use
>>> + * native='no' and format '-display egl-headless' onto the
>>> + * cmdline.
>>> + */
>>> + if (graphics->gl &&
>>> + graphics->gl->enable == VIR_TRISTATE_BOOL_YES &&
>>> + graphics->gl->native == VIR_TRISTATE_BOOL_ABSENT) {
>>> + gl->native = VIR_TRISTATE_BOOL_NO;
>>> +
>>> + if (glisten->type == VIR_DOMAIN_GRAPHICS_LISTEN_TYPE_NONE ||
>>> + glisten->type == VIR_DOMAIN_GRAPHICS_LISTEN_TYPE_SOCKET)
>>> + gl->native = VIR_TRISTATE_BOOL_YES;
>>> + }
>>
>> So the upside/downside to setting something in the XML that wasn't
>> previously set by the consumer is that "we're stuck with it" going
>> forward, right? Additionally, we cannot ascertain whether we set native
>> to NO or YES or if the consumer did.
>
> Does it matter? If libvirt set it, then we set it in a way that is safe for us,
> IOW we can ensure the vm will start using that setting. If the consumer set it,
> then we evaluate the setting and either fail or proceed with starting up the
> vm.
>
To me in particular, no it doesn't matter, but I note it because setting
a value however reasonable is something "of note". Does the domain
"work" without us setting that or does it fail to start? IOW: Are things
failing today/now without this being set?
>>
>> So the "other" side of this is this is being done in a domain_conf
>> function instead of some qemu device post parse function since if I'm
>> reading the RFC comments right, the desire is not to somehow
>> automagically add it, but rather force some usage.
>
> Correct, although, it's not that our "automagic" was wrong (in fact it was
> safe), but it wasn't very flexible and 'egl-headless' can find use cases even
> without mdevs, that was the main driver to expose it.
>
The relationship to mdev/hostdev is what I assumed in the long run this
was primarily geared towards. Having it without mdev would seem to be
sub-optimal especially w/ the required network component. It's taking
me a bit to figure this stuff out - you've been working with it, so I'm
trying to catch up.
>>
>> Still, I wonder if what's been done follows the spirit of Gerd's comment:
>>
>> "Hmm, I think it would be better to have egl-headless explicitly
>> configured in the domain xml instead of doing it automagically depending
>> on configuration."
>
> As I already explained in the cover letter reply, to me the facts that a
> standalone graphics type='headless' doesn't make sense, is basically just some
> kind of OpenGL switch and can't be combined with some of the other types felt
> like a wrong way of doing things, that's why I merged it with the 'gl' element.
> But okay, I'll give it a try on a separate branch and see how 'making it a
> graphics type' goes. The one thing that won't be necessary and worth doing
> anymore is separating the 'gl' data into a separate element, but I'm curious
> how much code will be saved (if any) if done this way.
>
Is it "fair" or "right" to say there's two ways to do gl support - one
where Spice/VNC is connected locally and one where it's connected
remotely. Then remotely is split into networked connection and
(eventually in subsequent patches) vGPU connection?
So you chose "native" to provide that functionality which gets some
automagic setting because we've determined there to be a need. Whether
that's because a domain fails to start or just is (well) brain dead is
what isn't clear to me.
Since we're not co-located - this is "my way" of talking through things
to "learn" and make sure what you've developed matches what someone
reading it "expected" as functionality. Automagic setting isn't
inherently wrong, but sometimes it needs to be carefully looked at to
make sure the reasons for doing it are "understandable".
[...]
>> Do you think we need ABI checks for this? Could be challenging given the
>> post parse setting of the value.
>
> I don't see an ABI problem here, old libvirt doesn't know what to do with it
> (and VNC will just ignore the gl element) and new enough libvirt would ensure
> that -spice gl=on and -display egl-headless will not appear on the cmdline.
> Everything else is something that's been working for a very long time.
>
I'm thinking about going forward. Once this is "in", if someone changes
the setting, then is that a problem ABI wise. You have a technology with
a network or vGPU connection that could change if the native changes.
Then of course there's the automagic setting. Of course there's no ABI
checking done yet on graphics - so I could be off in the weeds.
John
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
