[vbox-dev] 3d pass-through and gnome-shell ?

[Hans de Goede]

Hi,

On 26-06-17 11:24, Michael Thayer wrote:
> Hello Hans,
> 
> 23.06.2017 11:52, Hans de Goede wrote:
>> Hi,
>>
>> On 23-06-17 10:44, Michael Thayer wrote:
>>> Hello Hans,
>>>
>>> 22.06.2017 11:49, Hans de Goede wrote:
>>> [...]
>>>> I've been testing vbox 3d pass-through, and if I use metacity as a
>>>> window
>>>> manger then running glxgears -info shows:
>>>>
>>>> GL_RENDERER   = Chromium
>>>> GL_VERSION    = 2.1 Chromium 1.9
>>>> GL_VENDOR     = Humper
>>>>
>>>> So things seem to be working, but gnome3 / gnome-shell does not work ?
>>> [...]
>>>
>>> Sorry, another slow response, and sorry too that it will not be a very
>>> satisfactory response.  What you are pointing out is a known problem
>>> with our 3D.  It only works for X11 clients, not for Wayland.
>>
>> I was sort off expecting that already and tried with X11 (which gnome3
>> still supports just fine), but that does not work either.
> 
> I am currently in the middle of a long rebuild, I will update when it is
> finished and I can investigate.  I would expect Gnome3/X11 to work.

Ok.

>>> This is
>>> fixable in theory, but has been so far down the priority list for so
>>> long that we have officially declared it as user contribution only[1].
>>> In fact, as soon as I get round to it I will disable 3D support for
>>> Fedora guests altogether, as it is not reliable.
>>
>> With this I assume you mean removing the 3d accel checkbox in device
>> settings, because it already is off by default, right ?
> 
> This would be detecting at boot time that we are running in Fedora and
> not doing the ld.so.conf trickery at all, just leaving unaccelerated
> Mesa in place.  We only do that trickery when 3D is ticked.

Ah I see, I think we can do better, see below.

>>> Our 3D detection
>>> mechanism at start-up is too slow as compared to the Fedora log-in
>>> screen appearing, and often prevents log-in altogether.
>>
>> Hmm can you elaborate a bit on this? This sounds like something which
>> is worthwhile fixing.
> 
> I will take a look at this too after the rebuild and provide an update,
> but what I remember is gdm loading before the ld.so.conf trickery is
> installed and using Mesa, and getting confused because by the time
> log-in happened libGL.so.1 resolved to our OpenGL library.  Killing gdm
> and letting it restart solved the problem, for some definition of solving.

Ok, I understand, this is easy to fix:

1) Split out the bits which do the ld.so.conf trickery from the rest of
the guest service, so that we've a binary or script which will run, do
the ld.so.conf stuff if necessary and then exit. The idea here is that
the exit of the process indicates the ld.so.conf stuff is done.

2) Give this its own systemd .service file with:

[Unit]
Before=display-manager.service

[Service]
Type=oneshot
RemainAfterExit=yes

And then systemd will not start gdm until the ld.so.conf stuff has
finished

3) profit :)

Note we would still need to figure out a way to make gdm use X11 if
Wayland will not work with the 3d pass-through, but that is easy too,
simplest way is to edit:

/etc/gdm/custom.conf

And in the [daemon] Section set:
WaylandEnable=false

>> Note I've also tried booting into runlevel 3 and then doing "startx"
>> this also does not work, maybe I first need to start a none gnome-3
>> session, run glxgears there and then try startx  with a gnome3-session,
>> or does the slow detection get redone every time ?
> [...]
> It only gets done once at machine boot.  The logic is that 3D support
> may get enabled or disabled between boots, or the same image could be
> started again on a different hypervisor or even on physical hardware.

Ok, I understand.

Regards,

Hans