| View previous topic :: View next topic |
| Author |
Message |
szczerb
Veteran
Joined: 24 Feb 2007
Posts: 1709
Location: Poland => Lodz
|
 Posted: Wed Dec 02, 2015 3:18 pm Post subject: Xorg 1.16 → 1.17 updated with file collisions |
 |
|
Hi,
I just did an update after maybe 2-3 weeks or so. New mesa and X was pulled in.
Got the following messages at the end. Any ideas as to the cause? Should I maybe file a bug?
It's a Dell E6540 with i7-4810MQ and a Radeon HD 8790M. I'm only using the integrated graphics. No drivers for the Radeon.
| Code: | * Messages for package x11-proto/glproto-1.4.17-r1:
* This package will overwrite one or more files that may belong to other
* packages (see list below). You can use a command such as `portageq
* owners / <filename>` to identify the installed package that owns a
* file. If portageq reports that only one package owns a file then do
* NOT file a bug report. A bug report is only useful if it identifies at
* least two or more packages that are known to install the same file(s).
* If a collision occurs and you can not explain where the file came from
* then you should simply ignore the collision since there is not enough
* information to determine if a real problem exists. Please do NOT file
* a bug report at http://bugs.gentoo.org unless you report exactly which
* two packages install the same file(s). See
* http://wiki.gentoo.org/wiki/Knowledge_Base:Blockers for tips on how to
* solve the problem. And once again, please do NOT file a bug report
* unless you have completely understood the above message.
*
* Detected file collision(s):
*
* /usr/include/GL/glxtokens.h
* /usr/include/GL/glxproto.h
* /usr/include/GL/glxmd.h
*
* Searching all installed packages for file collisions...
*
* Press Ctrl-C to Stop
*
* None of the installed packages claim the file(s).
*
* Package 'x11-proto/glproto-1.4.17-r1' merged despite file collisions.
* If necessary, refer to your elog messages for the whole content of the
* above message.
|
| Code: | * Messages for package media-libs/mesa-11.0.6:
* This package will overwrite one or more files that may belong to other
* packages (see list below). You can use a command such as `portageq
* owners / <filename>` to identify the installed package that owns a
* file. If portageq reports that only one package owns a file then do
* NOT file a bug report. A bug report is only useful if it identifies at
* least two or more packages that are known to install the same file(s).
* If a collision occurs and you can not explain where the file came from
* then you should simply ignore the collision since there is not enough
* information to determine if a real problem exists. Please do NOT file
* a bug report at http://bugs.gentoo.org unless you report exactly which
* two packages install the same file(s). See
* http://wiki.gentoo.org/wiki/Knowledge_Base:Blockers for tips on how to
* solve the problem. And once again, please do NOT file a bug report
* unless you have completely understood the above message.
*
* Detected file collision(s):
*
* /usr/include/GL/gl.h
* /usr/include/GL/glx.h
* /usr/include/GL/glxext.h
* /usr/include/GL/glext.h
* /usr/include/EGL/egl.h
* /usr/include/EGL/eglmesaext.h
* /usr/include/EGL/eglextchromium.h
* /usr/include/EGL/eglext.h
* /usr/include/EGL/eglplatform.h
* /usr/include/KHR/khrplatform.h
* /usr/include/GLES2/gl2.h
* /usr/include/GLES2/gl2ext.h
* /usr/include/GLES2/gl2platform.h
* /usr/include/GLES3/gl3.h
* /usr/include/GLES3/gl3platform.h
* /usr/include/GLES3/gl31.h
* /usr/include/GLES3/gl3ext.h
* /usr/lib32/libGL.so.1
* /usr/lib32/libGLESv2.so
* /usr/lib32/libEGL.so
* /usr/lib32/libEGL.so.1
* /usr/lib32/libGL.so
* /usr/lib32/libGLESv2.so.2
* /usr/lib64/libGL.so.1
* /usr/lib64/libGLESv2.so
* /usr/lib64/libEGL.so
* /usr/lib64/libEGL.so.1
* /usr/lib64/libGL.so
* /usr/lib64/libGLESv2.so.2
*
* Searching all installed packages for file collisions...
*
* Press Ctrl-C to Stop
*
* None of the installed packages claim the file(s).
*
* Package 'media-libs/mesa-11.0.6' merged despite file collisions. If
* necessary, refer to your elog messages for the whole content of the
* above message.
* USE="bindist" was not set. Potentially patent encumbered code was
* enabled. Please see patents.txt for an explanation.
* Note that in order to have full S3TC support, it is necessary to install
* media-libs/libtxc_dxtn as well. This may be necessary to get nice
* textures in some apps, and some others even require this to run.
|
| Code: | * Messages for package x11-base/xorg-server-1.17.4:
* This package will overwrite one or more files that may belong to other
* packages (see list below). You can use a command such as `portageq
* owners / <filename>` to identify the installed package that owns a
* file. If portageq reports that only one package owns a file then do
* NOT file a bug report. A bug report is only useful if it identifies at
* least two or more packages that are known to install the same file(s).
* If a collision occurs and you can not explain where the file came from
* then you should simply ignore the collision since there is not enough
* information to determine if a real problem exists. Please do NOT file
* a bug report at http://bugs.gentoo.org unless you report exactly which
* two packages install the same file(s). See
* http://wiki.gentoo.org/wiki/Knowledge_Base:Blockers for tips on how to
* solve the problem. And once again, please do NOT file a bug report
* unless you have completely understood the above message.
*
* Detected file collision(s):
*
* /usr/lib64/xorg/modules/extensions/libglx.so
*
* Searching all installed packages for file collisions...
*
* Press Ctrl-C to Stop
*
* None of the installed packages claim the file(s).
*
* Package 'x11-base/xorg-server-1.17.4' merged despite file collisions.
* If necessary, refer to your elog messages for the whole content of the
* above message.
|
|
|
| Back to top |
|
 |
kklatt
n00b
Joined: 25 Oct 2004
Posts: 20
|
| Posted: Wed Dec 02, 2015 4:51 pm Post subject: Xorg 1.16 → 1.17 updated with file collisions |
|
|
I saw the same file collisions, but software seems OK. Setting DISPLAY to another host no longer works, no configuration changes I could find. I think the mode of setting the DISPLAY environment is no longer supported, that is just a guess. With some tweaking of sshd and ssh client configurations, the following ssh command works fine with the graphics display. You get a term session, and an application invoked uses the secured ssh session to display graphics.
ssh -Y -C <account@host> |
|
| Back to top |
|
|
szczerb
Veteran
Joined: 24 Feb 2007
Posts: 1709
Location: Poland => Lodz
|
| Posted: Fri Dec 04, 2015 9:38 am Post subject: |
|
|
Seems to work fine for me as well.
(don't know about remote connections - haven't used that in 2 years)
But doesn't it mean that there is a problem with those ebuilds tracking their own files? |
|
| Back to top |
|
|
orionbelt
Apprentice
Joined: 05 Apr 2006
Posts: 178
|
| Posted: Fri Dec 04, 2015 1:27 pm Post subject: |
|
|
I wasn't so lucky:
| Code: | >>> Installing (1 of 32) media-libs/mesa-11.0.6::gentoo
* checking 88 files for package collisions
* This package will overwrite one or more files that may belong to other
* packages (see list below). You can use a command such as `portageq
* owners / <filename>` to identify the installed package that owns a
* file. If portageq reports that only one package owns a file then do
* NOT file a bug report. A bug report is only useful if it identifies at
* least two or more packages that are known to install the same file(s).
* If a collision occurs and you can not explain where the file came from
* then you should simply ignore the collision since there is not enough
* information to determine if a real problem exists. Please do NOT file
* a bug report at http://bugs.gentoo.org unless you report exactly which
* two packages install the same file(s). See
* http://wiki.gentoo.org/wiki/Knowledge_Base:Blockers for tips on how to
* solve the problem. And once again, please do NOT file a bug report
* unless you have completely understood the above message.
*
* package media-libs/mesa-11.0.6 NOT merged
*
* Detected file collision(s):
*
* /usr/include/KHR/khrplatform.h
* /usr/include/EGL/eglext.h
* /usr/include/EGL/eglplatform.h
* /usr/include/EGL/eglextchromium.h
* /usr/include/EGL/eglmesaext.h
* /usr/include/EGL/egl.h
* /usr/include/GL/glxext.h
* /usr/include/GL/gl.h
* /usr/include/GL/glx.h
* /usr/include/GL/glext.h
* /usr/lib64/libEGL.so.1
* /usr/lib64/libGL.so
* /usr/lib64/libEGL.so
* /usr/lib64/libGL.so.1
* /usr/lib32/libEGL.so.1
* /usr/lib32/libGL.so
* /usr/lib32/libEGL.so
* /usr/lib32/libGL.so.1
*
* Searching all installed packages for file collisions...
*
* Press Ctrl-C to Stop
*
* None of the installed packages claim the file(s).
*
* Package 'media-libs/mesa-11.0.6' NOT merged due to file collisions. If
* necessary, refer to your elog messages for the whole content of the
* above message.
|
I do not understand why it refused to install the package once it found out that "None of the installed packages claim the file(s)".
But in reality it's a little more complicated than that. Although the files mentioned under /usr/include/ are indeed only claimed by
media-libs/mesa, the files under /usr/lib* seem to belong to x11-drivers/nvidia-drivers, but this becomes obvious only when checking with equery, not with portageq that is mentioned in the error message!
| Code: | % equery b /usr/lib64/libEGL.so.1
* Searching for /usr/lib64/libEGL.so.1 ...
x11-drivers/nvidia-drivers-340.93-r1 (/usr/lib64/opengl/nvidia/lib/libEGL.so.340.93)
% portageq owners / /usr/lib64/libEGL.so.1
None of the installed packages claim these files:
/usr/lib64/libEGL.so.1
|
The files themselves are all symbolic links but they do seem to point to nvidia files:
| Code: | % ls -l /usr/lib64/libEGL.so.1
lrwxrwxrwx 1 root root 34 Nov 2 19:20 /usr/lib64/libEGL.so.1 -> opengl/nvidia/lib/libEGL.so.340.93 |
So my question is: Is it OK to manually delete the /usr/lib* files mentioned in the error message above? Will mesa create new symbolic links pointing to its own .so's instead of nvidia's? Is this expected behavior? |
|
| Back to top |
|
|
szczerb
Veteran
Joined: 24 Feb 2007
Posts: 1709
Location: Poland => Lodz
|
| Posted: Fri Dec 04, 2015 3:06 pm Post subject: |
|
|
| The case with binary nvidia was always a bit more complicated because they have own GL implementation overwriting Mesa :/ |
|
| Back to top |
|
|
orionbelt
Apprentice
Joined: 05 Apr 2006
Posts: 178
|
| Posted: Fri Dec 04, 2015 4:20 pm Post subject: |
|
|
If that is the case, then why did media-libs/mesa never complain to me before now?
And, in any case, what is the proper course of action at this point? Should i manually delete the offending symbolic links, and update media-libs/mesa? Should i then re-emerge nvidia-drivers so that they may change back (?) the symbolic links once again or should i let mesa handle GL from now on? |
|
| Back to top |
|
|
F_
Tux's lil' helper
Joined: 31 Dec 2006
Posts: 142
|
| Posted: Sat Dec 05, 2015 5:25 am Post subject: |
|
|
Just wanted to say that I got this same issue today while running 'emerge -avuDN @world'.
Somehow it all worked out, too. Here's what I currently have installed:
| Code: |
% eix mesa
[I] app-eselect/eselect-mesa
Available versions: 0.0.10
Installed versions: 0.0.10(20:07:53 08/18/14)
Homepage: https://www.gentoo.org/
Description: Utility to change the Mesa OpenGL driver being used
[?] media-libs/mesa
Available versions: [M]7.10.3 10.2.8^d 10.3.7-r1^d ~10.3.7-r2^d ~10.4.6^d ~10.5.8^d ~10.6.9^d ~11.0.3^d ~11.0.4^d **9999^d {bindist +classic d3d9 debug +dri3 +egl +gallium +gbm gles gles1 gles2 hardened (+)llvm motif +nptl opencl openmax openvg osmesa pax_kernel pic selinux +udev vaapi vdpau wayland xa xvmc ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32" KERNEL="FreeBSD linux" VIDEO_CARDS="freedreno i915 i965 ilo intel mach64 mga nouveau r100 r128 r200 r300 r600 radeon radeonsi savage sis tdfx via vmware"}
Installed versions: 11.0.6(21:11:20 12/04/15)(bindist classic dri3 egl gallium gbm gles2 llvm nptl udev -d3d9 -debug -gles1 -opencl -openmax -osmesa -pax_kernel -pic -selinux -vaapi -vdpau -wayland -xa -xvmc ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="32 64 -x32" KERNEL="-FreeBSD" VIDEO_CARDS="i965 intel -freedreno -i915 -ilo -nouveau -r100 -r200 -r300 -r600 -radeon -radeonsi -vmware")
Homepage: http://mesa3d.sourceforge.net/
Description: OpenGL-like graphic library for Linux
% eix xorg-server
[?] x11-base/xorg-server
Available versions: 1.12.4-r5(0/1.12.4) ~1.12.4-r7(0/1.12.4) 1.15.2-r2(0/1.15.2) ~1.15.2-r4(0/1.15.2) 1.16.4(0/1.16.1) ~1.16.4-r5(0/1.16.1) ~1.17.4(0/1.17.4) {dmx doc glamor ipv6 kdrive libressl minimal nptl selinux static-libs +suid systemd tslib +udev unwind wayland xephyr xnest xorg xvfb}
Installed versions: 1.17.4(21:13:42 12/04/15)(ipv6 nptl suid udev xorg -dmx -doc -glamor -kdrive -libressl -minimal -selinux -static-libs -systemd -tslib -unwind -wayland -xephyr -xnest -xvfb)
Homepage: http://xorg.freedesktop.org/
Description: X.Org X servers
% eix xf86-video-intel
[?] x11-drivers/xf86-video-intel
Available versions: ~*2.9.1 2.19.0 2.20.13 2.21.15 ~2.99.903 ~2.99.905-r1 ~2.99.906 ~2.99.907-r1 ~2.99.909 ~2.99.910 ~2.99.914 ~2.99.916 2.99.917 ~2.99.917-r1 ~2.99.917-r2 {debug dri glamor (+)sna +udev uxa xvmc}
Installed versions: 2.99.917-r2(21:15:41 12/04/15)(dri sna udev -debug -uxa -xvmc)
Homepage: http://xorg.freedesktop.org/
Description: X.Org driver for Intel cards
|
My machine is a regular old Lenovo Thinkpad X201. |
|
| Back to top |
|
|
HerbMillerJW
n00b
Joined: 16 Feb 2012
Posts: 37
|
| Posted: Sat Dec 05, 2015 4:01 pm Post subject: |
|
|
| This broke my kwin effects. I had to rebuild nvidia-drivers to get them back, and now only when I start kwin with KWIN_COMPOSE=O2, so something is still broken. Or, something changed with how OpenGL availability is detected. I'm still looking into it. |
|
| Back to top |
|
|
orionbelt
Apprentice
Joined: 05 Apr 2006
Posts: 178
|
| Posted: Sat Dec 05, 2015 11:42 pm Post subject: |
|
|
| F_ wrote: | Just wanted to say that I got this same issue today while running 'emerge -avuDN @world'.
Somehow it all worked out, too. |
When you say "it all worked out", do you mean that you got the file collision warning by media-libs/mesa but emerge went ahead and installed the mesa update nonetheless?
Does your laptop have an nvidia card, and do you use x11-drivers/nvidia-drivers ?
| HerbMillerJW wrote: | | This broke my kwin effects. I had to rebuild nvidia-drivers to get them back, and now only when I start kwin with KWIN_COMPOSE=O2, so something is still broken. |
I guess it's not surprising that you had to re-emerge nvidia-drivers to get 3D acceleration back, it probably overwrote the symbolic links that mesa created. But i am not sure i understand what you mean by "now only when I start kwin with KWIN_COMPOSE=O2", KWIN_COMPOSE=O2 looks like a compile-time option, where do you define it? Anyway, thanks for letting us know what you find.
I hope some Gentoo dev looks into this soon. My X system is only half updated (up to the mesa failure), so if i need to reboot for any reason i'll probably have a broken X... |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sun Dec 06, 2015 12:46 am Post subject: |
|
|
For what it's worth, I updated two nouveau systems yesterday with no problem.
If it was me, I would emerge -C nvidia-drivers, then emerge -uvDN world, then emerge nvidia-drivers again. |
|
| Back to top |
|
|
orionbelt
Apprentice
Joined: 05 Apr 2006
Posts: 178
|
| Posted: Sun Dec 06, 2015 2:17 am Post subject: |
|
|
| Tony0945 wrote: | For what it's worth, I updated two nouveau systems yesterday with no problem.
If it was me, I would emerge -C nvidia-drivers, then emerge -uvDN world, then emerge nvidia-drivers again. |
Thanks, i tried it but it still does not work. In fact, the second emerging of nvidia-drivers that you suggest is not necessary because "emerge world" wants anyway to re-install nvidia-drivers *after* mesa. But mesa fails to install because of the file collision issue, and the process stops there.
By the way, i would be happy to try nouveau again, but IIRC it would not support 3D acceleration last time i tried it some years ago, and there were some fonts issues, too. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sun Dec 06, 2015 2:24 am Post subject: |
|
|
| orionbelt wrote: | | By the way, i would be happy to try nouveau again, but IIRC it would not support 3D acceleration last time i tried it some years ago, and there were some fonts issues, too. |
I changed because my cards are so old they are no longer supported. |
|
| Back to top |
|
|
orionbelt
Apprentice
Joined: 05 Apr 2006
Posts: 178
|
| Posted: Sun Dec 06, 2015 2:29 am Post subject: |
|
|
| My card is also old, which is why i followed the Gentoo/Nvidia directive and masked >=x11-drivers/nvidia-drivers-341.0.0 |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sun Dec 06, 2015 2:31 am Post subject: |
|
|
| orionbelt wrote: | | My card is also old, which is why i followed the Gentoo/Nvidia directive and masked >=x11-drivers/nvidia-drivers-341.0.0 |
That gave me problems with some package that required newer. |
|
| Back to top |
|
|
orionbelt
Apprentice
Joined: 05 Apr 2006
Posts: 178
|
| Posted: Sun Dec 06, 2015 2:32 am Post subject: |
|
|
| I am wondering whether bug 567200 is related to this discussion. |
|
| Back to top |
|
|
mgorny
Developer
Joined: 27 Apr 2007
Posts: 83
|
| Posted: Sun Dec 06, 2015 6:49 am Post subject: |
|
|
File collisions occur from time to time when packages are fixed not to create files outside of ebuilds, and the files need to be 'reowned' by ebuilds. Now you have two options:
1. If you are using FEATURES=collision-protect, emerge will refuse to replace any files. In this case, once you verified that you're fine with the replacement, you should do | Code: | | FEATURES=-collision-protect emerge -1v mesa |
to force the replacement with disable collision-protect for this one install.
2. If you are using FEATURES=protect-owned, emerge will figure out no other package owns the files and let you proceed.
These days, only protect-owned is on by default, so most users just see the big warning and then get the package installed. However, if you enabled collision-protect explicitly, see 1. Alternatively, you may decide to disable collision-protect and use protect-owned instead if you're not worried about Portage overwriting files you created. |
|
| Back to top |
|
|
orionbelt
Apprentice
Joined: 05 Apr 2006
Posts: 178
|
| Posted: Sun Dec 06, 2015 11:46 pm Post subject: |
|
|
Thanks for the informative reply, Michał. Indeed, i am using FEATURES=collision-protect, and your instructions explain what to do once i decide whether i am fine with the replacements.
However, my problem is that i cannot decide whether i am fine with the replacements, i.e., whether or not i should allow mesa to replace the symbolic links to nvidia-drivers files! HerbMillerJW above has had problems (broken kwin effects).
Ideally, i should set FEATURES=-collision-protect as you suggest, and let mesa replace the symbolic links. Then, when nvidia-drivers gets re-emerged, hopefully it will reinstate the symbolic links. I am just not sure that this will happen, hence my asking. |
|
| Back to top |
|
|
HerbMillerJW
n00b
Joined: 16 Feb 2012
Posts: 37
|
| Posted: Mon Dec 07, 2015 4:10 am Post subject: |
|
|
| orionbelt wrote: | | But i am not sure i understand what you mean by "now only when I start kwin with KWIN_COMPOSE=O2", KWIN_COMPOSE=O2 looks like a compile-time option, where do you define it? Anyway, thanks for letting us know what you find. |
It's an environment variable that overrides OpenGL detection. I had to kill kwin and restart it with that environment variable set. I realize now that it had fallen back to XRender in System Settings after the file collisions. Once I went in there and changed that back to OpenGL 2, I had my treasured wobbly windows back.  And you can only set it back on OpenGL in System Settings after re-emerging nvidia-drivers. Everything is working okay now on both of my systems. Those file collisions don't cause any permanent damage but they do cause quite a shake up.
This is definitely related to bug 567200. It'll be interesting to see how they decide to handle it. |
|
| Back to top |
|
|
mgorny
Developer
Joined: 27 Apr 2007
Posts: 83
|
| Posted: Mon Dec 07, 2015 5:06 am Post subject: |
|
|
| orionbelt wrote: | Thanks for the informative reply, Michał. Indeed, i am using FEATURES=collision-protect, and your instructions explain what to do once i decide whether i am fine with the replacements.
However, my problem is that i cannot decide whether i am fine with the replacements, i.e., whether or not i should allow mesa to replace the symbolic links to nvidia-drivers files! HerbMillerJW above has had problems (broken kwin effects).
Ideally, i should set FEATURES=-collision-protect as you suggest, and let mesa replace the symbolic links. Then, when nvidia-drivers gets re-emerged, hopefully it will reinstate the symbolic links. I am just not sure that this will happen, hence my asking. |
No, it won't. We don't do symlinks anymore, and set ld.so.conf properly instead. This fixes some past issues, and so far only Steam was reported broken due to upstream's hackery. However, if you install Steam from gamerlay or steam overlay, it should contain a fix. |
|
| Back to top |
|
|
orionbelt
Apprentice
Joined: 05 Apr 2006
Posts: 178
|
| Posted: Mon Dec 07, 2015 8:01 pm Post subject: |
|
|
mgorny: OK, so i did as you suggested. I have not yet restarted X, let's hope it will all work out when i do...
Another question: Is there any reason (besides perhaps extreme paranoia) to set FEATURES=collision-protect ? |
|
| Back to top |
|
|
mgorny
Developer
Joined: 27 Apr 2007
Posts: 83
|
| Posted: Mon Dec 07, 2015 8:26 pm Post subject: |
|
|
| The alternative to paranoia is development/bug hunting and possibly some custom hackery that could collide with ebuilds. |
|
| Back to top |
|
|
orionbelt
Apprentice
Joined: 05 Apr 2006
Posts: 178
|
| Posted: Mon Dec 07, 2015 8:28 pm Post subject: |
|
|
| Thanks once again, Michał. |
|
| Back to top |
|
|
orionbelt
Apprentice
Joined: 05 Apr 2006
Posts: 178
|
| Posted: Wed Dec 09, 2015 12:16 am Post subject: |
|
|
Well, i finally rebooted, and... OK, the good thing is that X "works". The bad thing is that i have similar problems to HerbMillerJW's: My KDE Desktop Effects are very slow (compositing: OpenGL 3.1 but i also tried 2.0 and 1.2; for Qt graphics system i tried both Native and Raster). In fact, kwin eats up 56% of CPU when i do nothing! Moving window focus is slow, even typing is slow. System almost unusable, so i had to disable desktop effects.
When i use KWIN_COMPOSE=O2, as HerbMillerJW recommended, i gain that kwin no longer crashes when i change compositing type and the screen gets redrawn. Other than that, the system remains slow. I note that i did not have to use KWIN_COMPOSE before the recent xorg update.
I got wondering if my nVidia's OpenGL is not used, but the following excerpt of the startx output seems to suggest that OpenGL is active:
| Code: | OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.5, 128 bits)
OpenGL version string: 3.3 (Core Profile) Mesa 11.0.6
OpenGL shading language version string: 3.30
Driver: LLVMpipe
GPU class: Unknown
OpenGL version: 3.3
GLSL version: 3.30
Mesa version: 11.0.6
X server version: 1.17.4
Linux kernel version: 4.0.9
Direct rendering: yes
Requires strict binding: yes
GLSL shaders: yes
Texture NPOT support: yes
Virtual Machine: no
NO VSYNC! neither glSwapInterval nor glXWaitVideoSync are supported
|
Also:
| Code: | % eselect opengl list
Available OpenGL implementations:
[1] nvidia *
[2] xorg-x11
|
What i find bizarre is that my libGL* libraries, many of which used to link to nvidia opengl directories, now do not:
| Code: | % ls -l /usr/lib64/libGL*
lrwxrwxrwx 1 root root 40 Nov 2 19:20 /usr/lib64/libGLESv1_CM.so -> opengl/nvidia/lib/libGLESv1_CM.so.340.93
lrwxrwxrwx 1 root root 37 Nov 2 19:20 /usr/lib64/libGLESv2.so -> opengl/nvidia/lib/libGLESv2.so.340.93
lrwxrwxrwx 1 root root 19 Feb 15 2015 /usr/lib64/libGLEWmx.so -> libGLEWmx.so.1.10.0
lrwxrwxrwx 1 root root 19 Feb 15 2015 /usr/lib64/libGLEWmx.so.1.10 -> libGLEWmx.so.1.10.0
-rwxr-xr-x 1 root root 493496 Feb 15 2015 /usr/lib64/libGLEWmx.so.1.10.0
lrwxrwxrwx 1 root root 17 Feb 15 2015 /usr/lib64/libGLEW.so -> libGLEW.so.1.10.0
lrwxrwxrwx 1 root root 17 Feb 15 2015 /usr/lib64/libGLEW.so.1.10 -> libGLEW.so.1.10.0
-rwxr-xr-x 1 root root 550848 Feb 15 2015 /usr/lib64/libGLEW.so.1.10.0
lrwxrwxrwx 1 root root 14 Dec 7 12:29 /usr/lib64/libGL.so -> libGL.so.1.2.0
lrwxrwxrwx 1 root root 14 Dec 7 12:29 /usr/lib64/libGL.so.1 -> libGL.so.1.2.0
-rwxr-xr-x 1 root root 618920 Dec 7 12:28 /usr/lib64/libGL.so.1.2.0
lrwxrwxrwx 1 root root 15 Apr 1 2015 /usr/lib64/libGLU.so -> libGLU.so.1.3.1
lrwxrwxrwx 1 root root 15 Apr 1 2015 /usr/lib64/libGLU.so.1 -> libGLU.so.1.3.1
-rwxr-xr-x 1 root root 522888 Apr 1 2015 /usr/lib64/libGLU.so.1.3.1
|
The first two point to opengl/* but they are actually dead links (flashing red): the files /usr/lib64/opengl/nvidia/lib/libGLESv1_CM.so.340.93 and /usr/lib64/opengl/nvidia/lib/libGLESv2.so.340.93 no longer exist, they apparently got replaced by new files with 96 at the end instead of 93:
| Code: | % ls -l /usr/lib64/opengl/nvidia/lib/libGLESv*
lrwxrwxrwx 1 root root 17 Dec 8 23:00 /usr/lib64/opengl/nvidia/lib/libGLESv1_CM.so -> libGLESv1_CM.so.1
lrwxrwxrwx 1 root root 22 Dec 8 23:00 /usr/lib64/opengl/nvidia/lib/libGLESv1_CM.so.1 -> libGLESv1_CM.so.340.96
-rwxr-xr-x 1 root root 48024 Dec 8 23:00 /usr/lib64/opengl/nvidia/lib/libGLESv1_CM.so.340.96
lrwxrwxrwx 1 root root 14 Dec 8 23:00 /usr/lib64/opengl/nvidia/lib/libGLESv2.so -> libGLESv2.so.2
lrwxrwxrwx 1 root root 19 Dec 8 23:00 /usr/lib64/opengl/nvidia/lib/libGLESv2.so.2 -> libGLESv2.so.340.96
-rwxr-xr-x 1 root root 62160 Dec 8 23:00 /usr/lib64/opengl/nvidia/lib/libGLESv2.so.340.96
|
Before the recent saga with mesa (and perhaps the reinstallation of nvidia-drivers?), i believe there were more than two libGL* (and perhaps libEGL* ?) files pointing to nvidia's opengl directories.
I also tried to to switch to nouveau. I have it activated in the kernel, and in my make.conf VIDEO_CARDS="nvidia nouveau vesa". However, when i unmerged nvidia-drivers, startx (i.e., startkde) could not see nouveau and X would fail to start. I am not sure what i missed.
Any help is much appreciated!  |
|
| Back to top |
|
|
HerbMillerJW
n00b
Joined: 16 Feb 2012
Posts: 37
|
| Posted: Wed Dec 09, 2015 1:03 am Post subject: |
|
|
Yeeaaaah, this is turning into a mess. You're experiencing exactly what my laptop running kwin under XFCE was doing. I could turn OpenGL on but it ran like garbage. And I'm pretty sure Gallium in the renderer string is not from the nvidia drivers. You're now the second person I've seen on these forums who re-emerging nvidia-drivers did not help (have you rebooted since re-emerging nvidia-drivers?).
I can confirm that downloading the proprietary nvidia-drivers and building them outside of portage does work and I'm back to normal, so if you want to go that route I can definitely help you through any build errors. |
|
| Back to top |
|
|
orionbelt
Apprentice
Joined: 05 Apr 2006
Posts: 178
|
| Posted: Wed Dec 09, 2015 1:13 am Post subject: |
|
|
| HerbMillerJW wrote: | | You're now the second person I've seen on these forums where re-emerging nvidia-drivers did not help (have you rebooted since re-emerging nvidia-drivers?). |
Yes, i have rebooted.
| Quote: | | I can confirm that downloading the proprietary nvidia-drivers and building them outside of portage does work and I'm back to normal, so if you want to go that route I can definitely help you through any build errors. |
Interesting!
Thanks for your offer, but i am going through a rather busy period right now, and i cannot afford the time to try it... In fact, tomorrow i will probably have to post yet another question about kernel compilation problems, which have a higher priority for me. I am happy enough with turning off the fancy desktop effects and getting my work done at lightning speed (if less sensation ) until the devs figure out how to make this work in portage, if this is where the problem is...
Either way, thanks a lot for your help! |
|
| Back to top |
|
|
|
Desktop Environments
