Hi,
> > Second for the long term there will be 3d support in a number of UIs:
> > I expect sdl2, gtk, egl (using render nodes, for headless) and spice.
> > Having a global switch for them all looks easier.
>
> In libvirt we model the ability to turn on 3d support for guests against
> the video device, rather than the backend device, since it is a guest
> visible feature. So should we do this against the virtual virtio-vga
> device and have the backends just tie their behaviour to that ?
There will be a switch for the video device anyway, probably something
along the lines of '-device virtio-vga,opengl={on,off,auto}'.
'off' behavior is obvious ;)
'on' must fail in case the ui has no 3d support, but the video doesn't
know that at initialization time.
'auto' should enable 3d in case ui supports it, but again we have the
problem here is that the device doesn't know at init time.
With a global switch we can tell the video device 'we want run
with/without 3d support' and have it initialize accordingly. Likewise
ui initialization can check the flag and figure whenever it should take
the 3d or non-3d code paths. Finally after ui init is done we can look
whenever we actually have 3d support when it was requested and error out
in case we havn't.
Also note that opengl in the ui is useful even in case the video device
doesn't support opengl: scaling the display with opengl is faster than
doing it in software, so letting virtio-vga flip the global 3d switch
isn't a good idea too.
cheers,
Gerd
