Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#41078 - [nvidia-libgl] [mesa-libgl] must not conflict

Attached to Project: Arch Linux
Opened by Evert Vorster (evorster) - Thursday, 03 July 2014, 21:38 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Saturday, 28 February 2015, 14:15 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Andreas Radke (AndyRTR)
Ionut Biru (wonder)
Sven-Hendrik Haase (Svenstaro)
Laurent Carlier (lordheavy)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
I am running Arch on a laptop with Optimus technology.

I would like to use the nVidia drivers for the nVidia GPU.
The nVidia GPU is not physically connected to the monitor of the laptop, the Intel GPU is.
Therefore the laptop needs have to have intel drivers installed at the same time as the nVidia drivers in order to give the nVidia GPU a buffer to render to.

I can get the nVidia card to work ( mostly ) but gl offloading does not work, as nvidia-libgl is not installed, and it can't be, as that conflicts with mesa-libgl, which is a hard requirement of the intel drivers needed to drive the GPU which is actually attached to a monitor.

Nice catch-22 situation there.

I did, however manage to get this working with Sorcerer Linux, which was my previous distro, by installing the nvidia-libgl stuff alongside the mesa-libgl stuff, just in diffirent directories, and then specifying which to load in the xorf.conf. So it is possible, from my own experience.

So, why are xorg-libgl and nvidia-libgl in conflict? Can I force Arch to install both at the same time?
This task depends upon

Closed by  Sven-Hendrik Haase (Svenstaro)
Saturday, 28 February 2015, 14:15 GMT
Reason for closing:  Won't implement
Comment by Doug Newgard (Scimmia) - Thursday, 03 July 2014, 23:43 GMT Comment by Evert Vorster (evorster) - Thursday, 03 July 2014, 23:55 GMT
Of course I have read the two wiki's, and quite a bit more material on the subject.

That's how I got it working in the beginning on Sorcerer Linux in the first place, and after a fashion here.
However, I am not interested in running bumblebee.

As stated in my bugreport, I want to run the nVidia GPU full-time, to have access to VDPAU and the stable nVidia drivers.
For this to work, both nvidia-libgl and mesa-libgl needs to be installed at the same time.

I am testing a custom nvidia-libgl package now, to see if I can make it not interfere with mesa-libgl. If I manage to get it working, it might end up as a package in AUR.



Comment by Evert Vorster (evorster) - Thursday, 03 July 2014, 23:59 GMT
Of course, it might also be possible for me to get my set-up working if I was able to install the intel drivers without having meas-libgl installed.
That would require mesa-libgl to become an optdepend on xf86-video-intel

Comment by Evert Vorster (evorster) - Friday, 04 July 2014, 00:29 GMT
Maybe I can be a little more clear.

My laptop, a HP ENVY dv7 is equipped with nVidia's Optimus technology.
In this specific laptop, the screen is hard-wired to the intel GPU.
The nVidia GPU can only render to a buffer on the Intel GPU.

In order to get any graphical display, I need to have xf86-video-intel installed.

I do a bit of gaming and video editing, and would really like to have the nVidia GPU run all the time, power savings be damned.
Following https://wiki.archlinux.org/index.php/Optimus I am able to run a setup like that.

Unfortunately, the driver xf86-video-intel depends on glamour-egl and intel-dri, which in turn depends on mesa-libgl

Because mesa-libgl and nvidia-libgl are in conflict, I am unable to install nvidia-libgl, which I need to unlock the full potential of my nVidia GPU.

I suppose nvidia-libgl installs files with the same name and location as mesa-libgl, in order for X to automatically find them.

I have been able, in the past, to install the libgl files from nvidia into a different directory, and then am able to access them with a custom xorg.conf, which has the ModulePath for the nvidia modules ahead of the ModulePath for the mesa modules.

If I am able to install xf86-video-intel without installing the mesa-libgl, I might be able to get this setup to work the way I want.

I had a peek at the nvidia-utils PKGBUILD. It looks like the nvidia installer wants to install the libgl files into /usr/lib/nvidia, and the package maintainer moved the location of those files to /usr/lib, which is the location that mesa-libgl is using. I suppose this is to make the X server automatically detect the nVidia GL files?

Kind regards,
Evert Vorster
Comment by Evert Vorster (evorster) - Friday, 04 July 2014, 02:12 GMT
I managed to get it to work by just manually extracting nvidia-libgl into my filesystem.

It feels a bit unclean, and I know it will break with the next system update.

It would be best if there was a way to specify to pacman that I want nvidia-libgl installed instead of mesa-libgl.

Kind regards,
Evert Vorster
Comment by Evert Vorster (evorster) - Friday, 04 July 2014, 12:10 GMT
If anyone is reading this...

Please close this bug. The point is moot, the nvidia vdpau drivers are no more stable than the open source ones, and my CPU is faster than either GPU at decoding video.

One thing is for certain, I don't want another laptop with this hybrid GPU technology.

Comment by _kronak (weox.os) - Friday, 27 February 2015, 11:55 GMT
  • Field changed: Percent Complete (100% → 0%)
this is very important for most laptop users . closing it without actually solving it is not good idea .
Comment by Sven-Hendrik Haase (Svenstaro) - Saturday, 28 February 2015, 14:15 GMT
The issue has no pretty fix. There is bumblebee which you can install as a workaround to load the files from a different location and fix the dependencies for you. I don't think we can support any other solution without making it harder for everybody else. I'm going to close this for now. If you come up with a good solution, post it here and ask for a re-open.

Loading...