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
_______________________________________________
vbox-dev mailing list
[email protected]
https://www.virtualbox.org/mailman/listinfo/vbox-dev
