I'm running the Ubuntu 14.04 final beta, with a Windows 8.1 x64 host with 3D acceleration enabled. Ubuntu reports normal 3D drivers via glxinfo and such, but it doesn't show 3D effects, runs slow, and indicates that 3D rendering failed if I try to actually run any 3D program. I've included the error log from glxinfo below.
Note that this does work fine with Ubuntu 13.10 on the same host. I'm using ZorinOS 8 32bit (Ubuntu derivative) on a win7x64 host. The effects seem to work fine but it's very slow.
I tested VMWARE Player and it ran much faster. Is there a setting I can change to improve performance? Replying to: I can also confirm the above: 1)Windows 7 x64 host 2)Ubuntu 14.04 Release (Although I got the same error with 13.10 as well) 3) 4.3.10 with guest additions and I am getting the 'exact' same errors as above.
Identical circumstances here: I cloned the VM from my 12.04 LTS Ubuntu, which works fine in all the same circumstances. I can get compiz (like wobbly windows) to work alright, but rendering is fairly slow and it is full of artifacts on applications like Google Chrome Browser, and any number of other dialogue based apps. Hi all, I have experienced the same issue / behavior - that of no 3d effects - but I am not running Ubuntu 14.04; I am running Arch Linux x8664. 1) Host: Mac OS X 10.9.2 2) Guest: Arch Linux x8664 3) 4.3.10 with guest additions I have traced the problem down to the upgrade of these packages: a) mesa 10.1.0 (link to latest = ) b) mesa-libgl 10.1.0 (link to latest = ) By downgrading and using the above package versions 3d works fine / as normal / as expected. By upgrading to any updated packages above these versions, 3d is broken. As far as I can tell, Ubuntu 14.04 is currently using the mesa 10.1 branch - but you never can tell at a glance which exact version or what patches Canonical has applied their mesa packages, and there is always that elephant in the room to consider.mir. Later versions of mesa 10.2-devel are currently in testing and are going to be released as LTS updates.
I know that Valve have been sponsoring development efforts towards mesa lately - my suspicion is that some new change has broken how mesa, opengl, and the VBox graphics driver's stack interact. As this bug is not solely Ubuntu 14.04 related, maybe the title should be updated to reflect this. I tried the 4.3.11 version on mac OSX Host. I have Mac OS X 10.9.2 I run a virtual Ubuntu 13.04 os (I have the same problem described on the first post with Ubuntu 14.04) I applied the Extension Pack 4.3.11 but, It does not solve the problem. I tried the -4.3.11-93604 with the extension pack on Windows 7 64bit Host. I have Ubuntu 14.04 Guest. After the update, I reinstalled Guest Additions and rebooted.
The error still presents. For me (Mac OSX host on Ubuntu 13.04 guest ) is when I try to use hardware acceleration to make some graphic visualisation. I currently try to use it with gazebo. When I try to launch it, I have the following error: 'libGL error: failed to load driver: vboxvideo' and crash after that. Note that if I use 'export LIBGLALWAYSSOFTWARE=1'cmd before to launch gazebo (in order to switch to software acceleration) I can run gazebo but it is not really smoothy of course. The issue may come from graphic driver as it doesn't seem to be installed/linked properly by the new Virtualbox guest Addition.
I wanted to try to downgrading the guest additions pack but all the official links seem to be broken. Hope it helps, How can I help you to grasp this issue? What's about the loading of vboxvideo driver?
With the new build I'm still seeing the same thing with a Win 8.1 x64 host. For me, as with kfeng, unitysupporttest suggests all is fine, but when I actually try something (I use glxgears), it's clearly running with software rendering (slow), and it gives the errors libGL error: core dri or dri2 extension not found libGL error: failed to load driver: vboxvideo Another symptom for me is that if I 'Save machine state' instead of shutting down the guest, when I resume, the (guest) desktop is frozen.
The 'solution' is to kill compiz on the guest from the command line, but that's not how it's supposed to work: in Ubuntu 13.10, I saw this same behavior before installing the additions and enabling 3D support, but with those steps it was fixed. So that's what leads me to believe 3D is not working. This bug also occurs in TinyCore. After investigation, the bug was introduced in v4.3.8's guest additions; 3D acceleration works in v4.3.6 and earlier. V4.2.24 = 3D acceleration works. V4.3.0 = 3D acceleration works.
V4.3.2 = 3D acceleration works. V4.3.4 = 3D acceleration works.
V4.3.6 = 3D acceleration works. V4.3.8 = libGL error: core dri or dri2 extension not found v4.3.10 = libGL error: core dri or dri2 extension not found v4.3.12 = libGL error: core dri or dri2 extension not found The above tests were run with Mesa 10.1.3's swrastdri.so and Mesa 9.1.4's libGL.so. EDIT: I see that virtualbox doesn't yet handle Opengl 3. I hope you'll be adding support soon, as it's the default in many of the current distributions.
I'm seeing the same problems with 4.3.12, but with no error messages. And everything is still slow, slow, slow. System:.
Ok, I want to do this, but you see just to make sure I decided to see if I can actually install the Intel driver, and it also now has it's own problem 'when I try to install it, it says 'The.
Host: Win7, 64 bit. Guest: Ubuntu 12.04.: 4.3.12 with GuestAdditions. I'm seeing the same problems with 4.3.12. And everything is still slow, slow, slow.
System:. Host: Win7, 64 bit. Guest: Ubuntu 14.04.: 4.3.12 with GuestAdditions. I observe a similar problem with 4.3.8 and 4.3.12: no 3D acceleration in the guest. Host OS: ROSA Desktop Fresh R3, x8664 Guest OS - same as host.
On the guest: Xorg 1.15.1, Mesa 10.1.3, additions installed. From glxinfo: libGL error: failed to authenticate magic 3 libGL error: failed to load driver: vboxvideo.
Server glx vendor string: SGI server glx version string: 1.4 server glx extensions: GLXARBmultisample, GLXEXTimportcontext, GLXEXTtexturefrompixmap, GLXEXTvisualinfo, GLXEXTvisualrating, GLXMESAcopysubbuffer, GLXOMLswapmethod, GLXSGISmultisample, GLXSGIXfbconfig, GLXSGIXpbuffer, GLXSGImakecurrentread client glx vendor string: Mesa Project and SGI client glx version string: 1.4. OpenGL vendor string: VMware, Inc. OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.3, 128 bits) OpenGL version string: 2.1 Mesa 10.1.3 From Xorg.0.log: 27.628 (II) LoadModule: 'vboxvideo' 27.644 (II) Loading /usr/lib64/xorg/modules/drivers/vboxvideodrv.so 27.662 (II) Module vboxvideo: vendor='Oracle Corporation' 27.662 compiled for 10.15.0, module version = 1.0.1 27.662 Module class: X.Org Video Driver 27.662 ABI class: X.Org Video Driver, version 15.0 27.662 (.) Load address of symbol 'VBOXVIDEO' is 0x7fc133a53ca0. 28.008 (II) Next line is added to allow vboxvideodrv.so to appear as whitelisted driver 28.008 (II) The file referenced, is.NOT. loaded 28.008 (II) Loading /usr/lib/xorg/modules/drivers//atidrv.so 28.008 (EE) AIGLX error: vboxvideo does not export required DRI extension 28.011 (EE) AIGLX: reverting to software rendering 28.929 (II) AIGLX: Loaded and initialized swrast 28.929 (II) GLX: Initialized DRISWRAST GL provider for screen 0 28.930 (II) VBoxVideo(0): Setting screen physical size to 289 x 221 I will attach the full logs below. Tickets 12941 and 12946 may be several different problems, or all may be related to the recent release of mesa / mesa-libgl 10.1.0.
My problem (64-bit Fedora 20 client) is that OpenGL fails to work with the 10.1.0 update. Perhaps 12941 and 12946 should be closed and a new ticket with 'mesa update to 10.1.0' in the title opened to track this particular problem? Anyone on these tickets with problems.not. caused by the mesa update could then open new tickets so their particular problems are not lost in the noise.
Best Rgds, -H. The Mesa problem should be fixed in this build: It was caused by a small change in Mesa authentication against the X server triggering a hidden problem in our driver.
The commit which fixes it is not yet publicly visible in our time line; when it appears (probably on Monday), the commit message will be: 'Additions/x11/vboxvideo: properly report the file descriptor for the kernel driver to allow authentication to work.' Thanks for the helpful work identifying the problem. General note to everyone commenting on this ticket. If 3D is working in your guest then the output of 'glxinfo' should include: OpenGL vendor string: Humper OpenGL renderer string: Chromium The following warnings will always appear, even when 3D is working, due to a problem in the way our driver is implemented which is not simple to fix: libGL error: core dri or dri2 extension not found libGL error: failed to load driver: vboxvideo The second line is misleading, as vboxvideo hooks itself into the Mesa library instead of being loaded in the normal way by Mesa. Appears to be working on ubuntu 14.04 under vbox 4.3.12 with the 4.3.13-93885.iso additions above, under OSX 10.7.5. To clarify, I get these errors that philwalk saw: libGL error: core dri or dri2 extension not found libGL error: failed to load driver: vboxvideo But I do see the 'Humper' and 'Chromium' render strings, and things seem to be working fairly well. I get a little glitchy jigsaw jumble fragmented screen that flashes at initial login, but then things straighten out and from what I can tell, it's performing reasonably.
I'll start using it full time tomorrow and test it some more. Thanks for the fix! I've been using this for a couple days and it seems like things still may not be right. It still suffers from quite a few artifacts - primarily in that apps don't seem to update correctly when you are scrolling - scroll down, then back up, and frequently the display gets corrupt - missing lines etc.
It also seems pretty slow, although I can't quantify that specifically, it just seems like I can see things happening - redrawing etc. Unfortunately I'm new to virtualbox with linux, and this is in comparison to the same guest/host in VMWare fusion 5.03. So it's possible it's just slower in general - but I have run windows guests in Virtualbox in the past, and they seemed to perform about the same as vmware. So I tend to doubt it's that.
As a point of data, I am running this same guest (14.04) natively on another machine and in vmware fusion 5.03 on this same mac, and don't see these issues. I have installed the fix VBoxGuestAdditions4.3.13-93885.iso in my ubuntu 14.04 under vbox 4.3.12 under OSX 10.9.3 and is still not working! I get these errors: libGL error: core dri or dri2 extension not found libGL error: failed to load driver: vboxvideo And I do see the 'Humper' and 'Chromium' render strings. What should I do? Replying to: I've been using this for a couple days and it seems like things still may not be right. It still suffers from quite a few artifacts - primarily in that apps don't seem to update correctly when you are scrolling - scroll down, then back up, and frequently the display gets corrupt - missing lines etc.
It also seems pretty slow, although I can't quantify that specifically, it just seems like I can see things happening - redrawing etc. Unfortunately I'm new to virtualbox with linux, and this is in comparison to the same guest/host in VMWare fusion 5.03. So it's possible it's just slower in general - but I have run windows guests in Virtualbox in the past, and they seemed to perform about the same as vmware. So I tend to doubt it's that. As a point of data, I am running this same guest (14.04) natively on another machine and in vmware fusion 5.03 on this same mac, and don't see these issues.
Interesting, I have been having issues with the screen not being re-drawn/re-rendered properly for ages now. It worked with older versions of the guest additions, but those are not compatible with the newer Ubuntu libraries. Also a sluggish feeling even if the 3D acceleration is supposed to be working.
The most notable artifacts are stuff being 'stuck' on the screen until I move over to force a redraw of sorts, especially noticeable when scrolling in Vim, for instance. I have the same issue, on current SW versions: Windows 8.1 professional 64 bit, 4.3.12, Extensions OracleVMVirtualBoxExtensionPack-4.3.12-93733.vbox-extpack, Ubuntu 14.04. The link for the updated Extension above is indeed dead, so no help from that anymore. I note that the title of this report claims: ¨fixed as of 27 May 2014 in 4.3.x and later releases after 27 May 2014¨, yet my the current Extensionpack from your website are dated May 16: 16-May-2014 06:08 Is this the classic developer trick, where a developer considers something fixed when she changed the source and loudly proclaims so and immediately walks off, yet the new builds have yet to be made available to users? Or do I miss something?:p In other words, do we still have to wait for an updated Extension pack or Virtualbox to actually get the fix? Thanks, Vlijmen.
I can confirm that the latest patched guest addititons has solved the issue for me. Mesa was previosuly overriding the virtualbox video driver, with the latest version this is no longer the case.
Hello, I am running cwm and I had some problems starting chrome from the menu - it starts for the very first time when i click on the menu, then i have to click 2 or 3 times on menu entry to start chrome again. This is not a big deal, maybe a cwm glitch. I went to start chrome from xterm, and I got these errors: $ chrome libGL error: failed to open drm device: Permission denied libGL error: failed to load driver: r600 libGL error: failed to open drm device: Permission denied libGL error: failed to load driver: r600 Is it normal, can it be fixed on my side? OpenBSD 5.8-current (GENERIC.MP) #1739: Fri Dec 11 06:16:43 MST 2015:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = (7657MB) avail mem = (7421MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev.
HelloI am running cwm and I had some problems starting chrome from the menu - it starts for the very first time when i click on the menu, then i have to click 2 or 3 times on menu entry to start chrome again. This is not a big deal, maybe a cwm glitch. I went to start chrome from xterm, and I got these errors: $ chrome libGL error: failed to open drm device: Permission denied libGL error: failed to load driver: r600 libGL error: failed to open drm device: Permission denied libGL error: failed to load driver: r600 Is it normal, can it be fixed on my side? The ownership of /dev/drm0 should be changed according to /etc/fbtab to your user after logging in. Can you include the output of ls -l /dev/drm0 and the contents of /var/log/Xorg.0.log?
How are you starting X, xdm/startx/? On Mon, Dec 28, 2015 at 12:25:25AM +0200, Mihai Popescu wrote: HelloI am running cwm and I had some problems starting chrome from the menu - it starts for the very first time when i click on the menu, then i have to click 2 or 3 times on menu entry to start chrome again. This is not a big deal, maybe a cwm glitch. I went to start chrome from xterm, and I got these errors: $ chrome libGL error: failed to open drm device: Permission denied libGL error: failed to load driver: r600 libGL error: failed to open drm device: Permission denied libGL error: failed to load driver: r600 Is it normal, can it be fixed on my side? The ownership of /dev/drm0 should be changed according to /etc/fbtab to your user after logging in. I have noticed (in the past), switching from X to virtual term (Ctrl+Shift+Fx) will override/revert the ownership of /dev/drm0, resulting in above (or similar) errors when I switch back to X and run something like xlock.
I say 'in the past', as I have avoided above switching since. Hope this sheds some light onto the problem (or possibly as-designed behavior).patrick Can you include the output of ls -l /dev/drm0 and the contents of /var/log/Xorg.0.log? How are you starting X, xdm/startx/? Can you include the output of ls -l /dev/drm0 and the contents of /var/log/Xorg.0.log?
Well, things were sorted out. Looking at that /etc/fbtab file Jonathan Gray pointed out (and yes, this is not a typo of /etc/fstab like I thought before) I can spot the /dev/drm0 in that long list of devices prepared for chown at login. But, that file is filled in for ttyC0 only, the tty that most users are using it for login.
But, giving the fact that I got some annoying kernel messages from my connecting/disconnecting USB mouse with aggresive power management routines, I was using ttyC1 for login. From that things got another way. I think this clarifies the other issue of changing tty / ownership change mentioned in this thread by somebody else. So the error was not really an error, going back to ttyC0 login I got the right permission and the messages are no more. Of course I can edit the /etc/fbtab, too. One question please: is it right that not getting access to /dev/drm0 is like losing hardware acceleration for applications using it? Mon, 28 Dec 2015 19:50:42 +0200 Mihai Popescu But, that file is filled in for ttyC0 only, the tty that most users are using it for login.
But, giving the fact that I got some annoying kernel messages from my connecting/disconnecting USB mouse with aggresive power management routines, I was using ttyC1 for login. Similar here, not using anywhere ttyC0, rather tty00 and ttyC1 to ttyC5. Confirmed the /etc/fbtab lines for these ttys worked as expected in these cases. So the error was not really an error, going back to ttyC0 login I got the right permission and the messages are no more. Of course I can edit the /etc/fbtab, too.
Interesting if you ssh log in to startx, e.g. Ttyp0, does this work in /etc/fbtab and is it expected to in this case? One question please: is it right that not getting access to /dev/drm0 is like losing hardware acceleration for applications using it?
Yes, on a drm(4) supported device. You could confirm this with the demo glxgears(1).