# Patch nvidia-drivers-331.38 for gentoo-sources-3.13.0-r1

## Chopstix

The problem:

```
 * Gentoo supports kernels which are supported by NVIDIA

 * which are limited to the following kernels:

 * <sys-kernel/gentoo-sources-3.13

 * <sys-kernel/vanilla-sources-3.13

 *

 * You are free to utilize epatch_user to provide whatever

 * support you feel is appropriate, but will not receive

 * support as a result of those changes.

 *

 * Do not file a bug report about this.
```

The kernel compiles, nvidia-drivers compiles, but X does not start.

```
modprobe: ERROR: could not insert 'nvidia': Unknown symbol in module, or unknown parameter (see dmesg)

(EE)

Fatal server error:

(EE) no screens found(EE)
```

The assumption:

You have already keyworded and emerged =sys-kernel/gentoo-sources-3.13.0-r1 and used eselect to select the new kernel.

The solution:

```
mkdir -p /etc/portage/patches/x11-drivers/nvidia-drivers-331.38/
```

Paste this into /etc/portage/patches/x11-drivers/nvidia-drivers-331.38/kernel.patch :

```
--- a/kernel/nv-acpi.c   2014-01-09 03:49:24.000000000 +0100

+++ b/kernel/nv-acpi.c   2014-01-29 11:02:21.673942336 +0100

@@ -303,8 +303,10 @@

 

     if (pNvAcpiObject->notify_handler_installed)

     {

+#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 13, 0)

+/* beginning with 3.13, acpi_remove_notify_handler() waits for events to finish */

         NV_ACPI_OS_WAIT_EVENTS_COMPLETE();

-

+#endif

         // remove event notifier

         status = acpi_remove_notify_handler(device->handle, ACPI_DEVICE_NOTIFY, nv_acpi_event);

     }

--- a/kernel/uvm/nvidia_uvm_linux.h   2014-01-09 03:49:25.000000000 +0100

+++ b/kernel/uvm/nvidia_uvm_linux.h   2014-01-29 11:04:32.352938042 +0100

@@ -405,11 +405,16 @@

 // not require the RCU's read lock on current->cred.

 //

 //

+#if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 5, 0)

+#define NV_KUID_TO_UID(value) (__kuid_val(value))

+#else

+#define NV_KUID_TO_UID(value) (value)

+#endif

 #if defined(NV_TASK_STRUCT_HAS_CRED)

 #define NV_CURRENT_EUID() \

-    (((typeof(*current->cred) __force __kernel *)current->cred)->euid)

+    NV_KUID_TO_UID(((typeof(*current->cred) __force __kernel *)current->cred)->euid)

 #else

-#define NV_CURRENT_EUID() (current->euid)

+#define NV_CURRENT_EUID() NV_KUID_TO_UID(current->euid)

 #endif

 

 #define NV_ATOMIC_SET(data,val)         atomic_set(&(data), (val))
```

Go ahead and emerge nvidia-drivers.

No guarantees that this fix is correct, but it works fine for me.

Changes taken from https://devtalk.nvidia.com/default/topic/644906/linux/331-20-on-3-13-rc1-kernelLast edited by Chopstix on Wed Jan 29, 2014 2:07 pm; edited 1 time in total

----------

## pitcrawler

I've been trying to get my nvidia driver to work in kernel 3.13 for the past couple of days. None of the patches, including the one you posted, worked for me. I just had to go back to 3.12.

I'm using a laptop with an intel and an nvidia GPU and bumblebee/bbswitch for switching between them.

----------

## Chopstix

What was the point of your post?

----------

## gienah

 *Quote:*   

> I've been trying to get my nvidia driver to work in kernel 3.13 for the past couple of days. None of the patches, including the one you posted, worked for me. 

 

In addition to the instructions Chopstix provided, you could try this patch (as well as the patch Chopstix provided, so 2 patches):

Paste this into /etc/portage/patches/x11-drivers/nvidia-drivers-331.38/nvidia_3.13_kernel_DEVICE_ACPI_HANDLE.patch

```
--- a/kernel/nv-acpi.c.orig

+++ b/kernel/nv-acpi.c

@@ -14,6 +14,10 @@

 #include "os-interface.h"

 #include "nv-linux.h"

 #include "nv-reg.h"

+

+#if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 13, 0) && defined(ACPI_HANDLE)

+#define DEVICE_ACPI_HANDLE(a) ACPI_HANDLE(a)

+#endif

 

 #if defined(NV_LINUX_ACPI_EVENTS_SUPPORTED)

 static RM_STATUS   nv_acpi_extract_integer (const union acpi_object *, void *, NvU32, NvU32 *);

```

----------

## pitcrawler

I'll try that when I get home. I know it's solvable. I'm pretty sure it's confined to nvidia-drivers.

 *Chopstix wrote:*   

> What was the point of your post?

 Well, the point was that I've looked everywhere else, and I ended up with a potential solution from posting here.

----------

## Chopstix

It's just that you hadn't provided any information whatsoever based on which we could help you, no explanation of what it is exactly that didn't work, no error messages or logs of what you did, and you didn't contribute to this issue either, so I was puzzled.

----------

## pitcrawler

 *Chopstix wrote:*   

> It's just that you hadn't provided any information whatsoever based on which we could help you, no explanation of what it is exactly that didn't work, no error messages or logs of what you did, and you didn't contribute to this issue either, so I was puzzled.

 I know what you mean. I was making some assumptions in my post, mainly that it could be related to optimus/bumblebee, that someone with that setup might have had the same issue and would jump in saying that they found a solution since it's a current issue. Didn't want to waste time right away posting 10 pages of logs because I know it's probably something simple.

----------

## pitcrawler

I did solve my problem by combining the two patches posted in this thread. Thanks to the both of you.

----------

## albright

these patches fail for me, with

```
cat nvidia-331.38.patch.out 

***** nvidia-331.38.patch *****

PWD: /var/tmp/portage/x11-drivers/nvidia-drivers-331.38/work

===============================

PATCH COMMAND:  patch -p0 -g0 -E --no-backup-if-mismatch  < '/etc/portage/patches//x11-drivers/nvidia-drivers-331.38/nvidia-331.38.patch'

===============================

can't find file to patch at input line 3

Perhaps you used the wrong -p or --strip option?

The text leading up to this was:

--------------------------

|--- a/kernel/nv-acpi.c   2014-01-09 03:49:24.000000000 +0100 

|+++ b/kernel/nv-acpi.c   2014-01-29 11:02:21.673942336 +0100 

--------------------------

No file to patch.  Skipping patch.

1 out of 1 hunk ignored

can't find file to patch at input line 17

Perhaps you used the wrong -p or --strip option?

The text leading up to this was:

--------------------------

|--- a/kernel/uvm/nvidia_uvm_linux.h   2014-01-09 03:49:25.000000000 +0100 

|+++ b/kernel/uvm/nvidia_uvm_linux.h   2014-01-29 11:04:32.352938042 +0100 

--------------------------

No file to patch.  Skipping patch.

1 out of 1 hunk ignored

patch program exited with status 1

.... (repeats like this with different pN options)

```

I copy/pasted the patch from this thread into /etc/portage/patches/x11-drivers/nvidia-drivers-331.38/nvidia-331.38.patch

----------

## gienah

Another thing you could try then is, as root, first remove the user patches that fail:

```
rm /etc/portage/patches/x11-drivers/nvidia-drivers-331.38/*
```

And then to try extracting this tar file I made for you where I copy/pasted the

earlier patches into the tar file:

```
cd ~

wget http://dev.gentoo.org/~gienah/unsupported/etc-portage-patches-x11-drivers-nvidia-drivers-331.38-for-kernel-3.13.tar.gz

cd /

tar xvf ~/etc-portage-patches-x11-drivers-nvidia-drivers-331.38-for-kernel-3.13.tar.gz
```

----------

## albright

thanks v. much - the wget (wgot?) files worked

patch files seem to be very delicate little flowers  :Smile: 

----------

## musv

Tried those 2 patches on my 32bit Atom Notebook. With Kernel-3.13 the complete system freezes when X is starting. I can't even login via ssh. With Kernel-3.9.x (the last one I installed before the update) nvidia-drivers-331.38 works like a charm.

Update: Tried the nvidia-drivers with Kernel-3.12.9 - works too on 32 bit.Last edited by musv on Thu Feb 13, 2014 12:03 pm; edited 1 time in total

----------

## albright

also, the patches don't work (for me at least) for the newer

nvidia-drivers-334.16-r5

----------

## Chopstix

 *albright wrote:*   

> also, the patches don't work (for me at least) for the newer
> 
> nvidia-drivers-334.16-r5

 

Why would they?  :Razz: 

----------

## albright

... you never know ...

the 325 patch worked fine just banging it into a 

/etc/portage/patches/x11-drivers/nvidia-drivers-331.13

directory ...

----------

## ulenrich

I do use without issue:

```
--- a/kernel/nv-acpi.c

+++ b/kernel/nv-acpi.c

@@ -15,6 +15,10 @@

 #include "nv-linux.h"

 #include "nv-reg.h"

 

+#if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 13, 0) && defined(ACPI_HANDLE)

+#define DEVICE_ACPI_HANDLE(a) ACPI_HANDLE(a)

+#endif

+

 #if defined(NV_LINUX_ACPI_EVENTS_SUPPORTED)

 static RM_STATUS   nv_acpi_extract_integer (const union acpi_object *, void *, NvU32, NvU32 *);

 static RM_STATUS   nv_acpi_extract_buffer  (const union acpi_object *, void *, NvU32, NvU32 *);

@@ -303,7 +307,10 @@ static int nv_acpi_remove(struct acpi_de

 

     if (pNvAcpiObject->notify_handler_installed)

     {

+#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 13, 0)

+ /* beginning with 3.13, acpi_remove_notify_handler() waits for events to finish */

         NV_ACPI_OS_WAIT_EVENTS_COMPLETE();

+#endif

 

         // remove event notifier

         status = acpi_remove_notify_handler(device->handle, ACPI_DEVICE_NOTIFY, nv_acpi_event);

```

[Edit] There is an issue with blanks - better use the archlinux link at the bottom of

https://forums.gentoo.org/viewtopic-p-7499724.html#7499724Last edited by ulenrich on Thu Feb 13, 2014 9:36 pm; edited 1 time in total

----------

## Juippisi

Thanks ulenrich, that patch works perfectly with x11-drivers/nvidia-drivers-334.16-r5 and kernel-3.13.1.

----------

## albright

not for me does ulenrich's patch work   :Crying or Very sad: 

just:

```
***** kernel.patch *****

PWD: /var/tmp/portage/x11-drivers/nvidia-drivers-334.16-r5/work

========================

PATCH COMMAND:  patch -p0 -g0 -E --no-backup-if-mismatch  < '/etc/portage/patches//x11-drivers/nvidia-drivers-334.16-r5/kernel.patch'

========================

can't find file to patch at input line 3

Perhaps you used the wrong -p or --strip option?

The text leading up to this was:

--------------------------

|--- a/kernel/nv-acpi.c 

|+++ b/kernel/nv-acpi.c 

--------------------------

No file to patch.  Skipping patch.

2 out of 2 hunks ignored

patch program exited with status 1

```

----------

## Chopstix

Maybe the "//" is the problem?

----------

## darkphader

I used this patch:

```
diff -Naurp NVIDIA-Linux-x86_64-334.16.ORIG/kernel/nv-linux.h NVIDIA-Linux-x86_64-334.16/kernel/nv-linux.h

--- NVIDIA-Linux-x86_64-334.16.ORIG/kernel/nv-linux.h   2014-02-04 22:45:24.000000000 +0100

+++ NVIDIA-Linux-x86_64-334.16/kernel/nv-linux.h        2014-02-11 21:00:58.172923793 +0100

@@ -273,7 +273,11 @@ extern int nv_pat_mode;

 #endif

 #if !defined(NV_VMWARE) && defined(CONFIG_ACPI)

-#include <acpi/acpi.h>

+#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 13, 0)

+#include <acpi/acpi.h>

+#else

+#include <linux/acpi.h>

+#endif

 #include <acpi/acpi_drivers.h>

 #if defined(NV_ACPI_DEVICE_OPS_HAS_MATCH) || defined(ACPI_VIDEO_HID)

 #define NV_LINUX_ACPI_EVENTS_SUPPORTED 1

@@ -308,6 +312,7 @@ extern int nv_pat_mode;

 #endif

 #if defined(NV_LINUX_ACPI_EVENTS_SUPPORTED)

+#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 13, 0)

 #if (NV_ACPI_OS_WAIT_EVENTS_COMPLETE_ARGUMENT_COUNT == 1)

 #define NV_ACPI_OS_WAIT_EVENTS_COMPLETE() \

     acpi_os_wait_events_complete(NULL)

@@ -317,6 +322,11 @@ extern int nv_pat_mode;

 #else

 #error "NV_ACPI_OS_WAIT_EVENTS_COMPLETE_ARGUMENT_COUNT value unrecognized!"

 #endif

+#else

+/* starting with 3.13 acpi_remove_notify_handler() waits for events to finish */

+#define NV_ACPI_OS_WAIT_EVENTS_COMPLETE() \

+    do { } while (0)

+#endif

 #endif

 #if defined(CONFIG_PREEMPT_RT) || defined(CONFIG_PREEMPT_RT_FULL)
```

Which seems to work. However I can no longer emerge media-libs/mesa-10.0.3 without setting opengl to xorg-x11. Can set it back after to nvidia after the emerge but I think I should work with nvidia selected.

----------

## ulenrich

 *albright wrote:*   

> 
> 
> ```
> ***** kernel.patch *****
> 
> ...

 That is odd  :Sad: 

I wonder if you just have to put the patch into 

/etc/portage/patches//x11-drivers/nvidia-drivers-334.16

(without any -rNUM) like me: 

```
>>> Unpacking source...

>>> Unpacking NVIDIA-Linux-x86_64-334.16.run to /tmp/portage/x11-drivers/nvidia-drivers-334.16-r5/work

>>> Source unpacked in /tmp/portage/x11-drivers/nvidia-drivers-334.16-r5/work

>>> Preparing source in /tmp/portage/x11-drivers/nvidia-drivers-334.16-r5/work ...

 Applying user patches from /etc/portage/patches//x11-drivers/nvidia-drivers-334.16 ...

 nvidia-linux-3.13.patch ...

 Done with patching

>>> Source prepared.

>>> Configuring source in /tmp/portage/x11-drivers/nvidia-drivers-334.16-r5/work ...

>>> Source configured.

>>> Compiling source in /tmp/portage/x11-drivers/nvidia-drivers-334.16-r5/work ...

 Preparing nvidia module
```

Perhaps the code is not proper, because of some copy-paste-forum issue of me, try the one correctly named patch file (out of five) of this archive: https://aur.archlinux.org/packages/nv/nvidia-full-beta-all/nvidia-full-beta-all.tar.gzLast edited by ulenrich on Thu Feb 13, 2014 6:02 pm; edited 2 times in total

----------

## ulenrich

 *darkphader wrote:*   

> I used this patch:
> 
> ```
> diff -Naurp NVIDIA-Linux-x86_64-334.16.ORIG/kernel/nv-linux.h NVIDIA-Linux-x86_64-334.16/kernel/nv-linux.h
> 
> ...

 

Interesting, because I have an issue booting in efi mode with a garbled line (thick like a menu bar at the bottom). In the moment I resurrect booting in hybrid mbr mode my MacMini.

Where did you get this patch? (mine was Archlinux, see above). I really wonder if it is supposed to work as such with xorg-x11 opengl: The newest propr. nvidia-drivers is able to use egl. It perhaps needs coworking with mesa? Does someone know exactly how to enable egl? I guess I am still using glx with my setup. 

I never got through all these different opengl1 opengl glx gles gles2 egl  .......Last edited by ulenrich on Thu Feb 13, 2014 6:09 pm; edited 2 times in total

----------

## darkphader

 *ulenrich wrote:*   

> Interesting, because I have an issue booting in efi mode with a garbled line (thick like a menu bar at the bottome). 
> 
> Where did you get this patch? (mine was Archlinux)

 

From the nvidia dev site. I boot via UEFI (directly, using EFI stub - no boot loader) with no issues.

 *ulenrich wrote:*   

> I wonder if it is OK to just use xorg-x11 opengl: Isn't the newest propr. nvidia-drivers able to use egl? Is it perhaps coworking with mesa egl ??? Does someone know exactly how to enable egl? 
> 
> I guess I am still using glx with my setup.

 

It is some sort of egl error that mesa throws during the install when emerging it with opengl set to nvidia.

----------

## ulenrich

 *darkphader wrote:*   

>  *ulenrich wrote:*   Interesting, because I have an issue booting in efi mode with a garbled line (thick like a menu bar at the bottome). Where did you get this patch? (mine was Archlinux) 
> 
> From the nvidia dev site. I boot via UEFI (directly, using EFI stub - no boot loader) with no issues.

 

I was able too - until last christmas.  My Debian-sid-unstable has no problems, but using their kernel  with my Gentoo~unstable didn't help either. Also tried systemd-204 instead systemd-208, tried openrc ....

----------

## darkphader

 *ulenrich wrote:*   

> I was able too - until last christmas.  My Debian-sid-unstable has no problems, but using their kernel  with my Gentoo~unstable didn't help either. Also tried systemd-204 instead systemd-208, tried openrc ....

 

Just switched to systemd 4 days ago (208-r3). Frankly, I like it. Had to rebuild the kernel (I use gentoo-sources) with the additional init= stuff for the kernel command line but it started right up. Also I don't use an initramfs so that simplifies stuff a bit. Of course not all of my services started right up but I've since straightened almost everything out. Now working on using systemd to take over the cron duties as well.

I'm running Fedora on my laptop and Debian on some servers, so with Debian going systemd having Gentoo using the same init system will simplify things for me. Now if only they could all use the same package manager :-)

Chris

----------

## albright

 *Quote:*   

> That is odd 

 

 *Quote:*   

> Perhaps the code is not proper, because of some copy-paste-forum issue

 

thanks; the tar.gz patch worked fine, so I ran diff on the two patches

sure enough, the "bad" patch had one blank space added to the end of each

line which, I expect, was the source of the trouble (the patch was looking for

"nv-acpi.c " instead of "nv-acpi.c" ...

----------

## yuyuyak

I was encouraged by ulenrich's post https://forums.gentoo.org/viewtopic-p-7498982.html#7498982

But it failed for me.  It does appear that patch has been mangled passing from forum to forum, as ulenrich later suggests, the Nvidia discussion on the issue is here: https://devtalk.nvidia.com/default/topic/686157/linux/334-16-won-t-compile-for-linux-v3-13-patch-included-/post/4117392/#4117392

This appears to be the original version of that patch: https://devtalk.nvidia.com/default/topic/686157/linux/334-16-won-t-compile-for-linux-v3-13-patch-included-/post/4117484/#4117484

I haven't tried that one again but I did use this one: https://devtalk.nvidia.com/default/topic/686157/linux/334-16-won-t-compile-for-linux-v3-13-patch-included-/post/4118475/#4118475

Seems to work at least as well as the older 331.38 patch.  I have had an issue with what appears to me a confusion by the driver as to what buffer to use, mostly in bash and geany, a little in chromium.  Occasionally flashes a few lines from one buffer to another a couple of times a second.  Annoying, moving through the document eventually makes it go away.  I see it with this patch too right after startup, but it seems to go away after that, it's intermittent so time will tell.

This is with kernel 3.13.2 and the 334.16-r5 driver, GeForce 8600M GS.

Edit: Oh and I meant to add, darkphader's issues with mesa are reminiscent of this bug with webkit-gtk & nvidia-drivers: https://bugs.gentoo.org/show_bug.cgi?id=463960

In that instance they also found changing opengl to xorg rather than invidia allowed the ebuild to install.  Interesting.

Well, ignorance is bliss.  I have now also the mesa problem and it does not go away by changing opengl to xorg.  To be continued...

----------

## darkphader

 *yuyuyak wrote:*   

> This appears to be the original version of that patch: https://devtalk.nvidia.com/default/topic/686157/linux/334-16-won-t-compile-for-linux-v3-13-patch-included-/post/4117484/#4117484
> 
> I haven't tried that one again but I did use this one: https://devtalk.nvidia.com/default/topic/686157/linux/334-16-won-t-compile-for-linux-v3-13-patch-included-/post/4118475/#4118475

 

The patch I used and posted earlier in this thread came from https://devtalk.nvidia.com/default/topic/686157/334-16-won-t-compile-for-linux-v3-13-patch-included-/?offset=10.

Scroll down to post #11 where the claim is made "Btw, here's a much simpler one which also works on 3.14 (all the way back to 3.0)". I didn't try it with any earlier kernels.

Chris

----------

## yuyuyak

 *darkphader wrote:*   

> The patch I used and posted earlier in this thread came from https://devtalk.nvidia.com/default/topic/686157/334-16-won-t-compile-for-linux-v3-13-patch-included-/?offset=10. 

 

Yes, it's the one I used.  Actually I have now found that either of the patches, post #2 or #11 seem to work equally well for me, and it seems even the patch everyone was using for 331.38, I really can't tell any difference.

The issue I had with jumping text and flashing buffers appears to be more due to my gtk theme, for some reason with the new driver I often get a fallback gtk theme on boot   :Rolling Eyes:   and there are no issues then.  So that problem should be stricken from this discussion.

I still have the mesa issue, won't install with opengl set to either setting.  I'm almost certain I reinstalled it a couple of days ago when I was trying to solve the flashing text problem.  For certain about a week ago it was reinstalled with the 331.38 driver, whole machine had the emerge -e @system @world done to it.

I had trouble returning to the 331.38 driver because of the libEGL and libGLES files being left behind when uninstalling the new driver.  May have to look into trying that again.

----------

## darkphader

 *yuyuyak wrote:*   

> I had trouble returning to the 331.38 driver because of the libEGL and libGLES files being left behind when uninstalling the new driver.  May have to look into trying that again.

 

Ran into that same issue after an initial install of 334 that didn't work (no patch). Had to manually remove some strangely named lib files to get back on track. I think the earlier 334.xx ebuilds were problematic.

----------

## yuyuyak

I have solved the problem.  I managed to downgrade to nvidia-drivers 304.119   :Very Happy: 

The problem with mesa is acquiring a healthy following: https://bugs.gentoo.org/show_bug.cgi?id=481316

I tried both of the fixes described there, neither of them worked for me.  Worth a shot though.  The easiest one is to emerge llvm with -ncurses.

I am the last poster there currently with 2 posts.

In regards to the issue of downgrading, on another thread here, regarding mesa I believe, lburns(? is it?) tells how to do it, worked great for me.

Install the older driver, in my case I had to 1st remove the new driver.  Then it will give you a list of @preserved-rebuilds that need to be addressed.  Rather than doing emerge @preserved-rebuild, do eselect opengl and select xorg and then select nvidia.  Then remove /usr/lib32/opengl/nvidia/lib/libEGL.so.1 and /usr/lib32/opengl/nvidia/lib/libEGL.so.334.16.  Problem solved, no pesky preserved-rebuilds to do and old driver now all good.

If you notice, some ebuilds will do that same eselect opengl trick, I saw it a bit ago, think it was mesa.  Some magic happens there.

If you read my 2 posts on the bug, you'll see that although the initial issue seems to be with llvm, the nvidia driver plays a part as well.  After downgrading, mesa still would not build, but using the -ncurses trick worked with the older driver.

Hmm, I just checked and my massive rebuild of the system was Feb. 2-ending just before Midnight on Feb. 3.  There were no issues with mesa/llvm/nvidia then.  Checking the emerge history I see this:

```
Wed Sep 25 20:54:12 2013 >>> sys-devel/llvm-3.3-r1

Sun Feb  2 22:33:43 2014 >>> sys-devel/llvm-3.3-r3

Mon Feb  3 01:24:19 2014 >>> sys-devel/llvm-3.4

Mon Feb  3 01:31:41 2014 >>> sys-devel/llvm-3.3-r3

Wed Feb  5 02:23:35 2014 >>> sys-devel/llvm-3.4

Wed Feb  5 11:21:54 2014 >>> sys-devel/llvm-3.3-r3

Thu Feb  6 04:35:00 2014 >>> sys-devel/llvm-3.4

```

So it may be worth downgrading llvm until the dust settles.  There are no anomalies in that time period with the other two.  FYI

----------

## yuyuyak

Bug filed on the mesa problem: https://bugs.gentoo.org/show_bug.cgi?id=501328

----------

## gerard27

@yuyuyak

Had the same problem with mesa-9.2.5 and nvidia-drivers-334.16-r5.

In desperation I unmasked mesa-10.0.3 and it compiles fine.

It pulls in some other packages

```

These are the packages that would be merged, in order:

Calculating dependencies  .... done!

[ebuild  N     ] x11-libs/libxshmfence-1.1  USE="-static-libs" ABI_X86="(64) -32 (-x32)" 285 kB

[ebuild  N     ] x11-proto/dri3proto-1.0  ABI_X86="(64) -32 (-x32)" 0 kB

[ebuild  N     ] x11-proto/presentproto-1.0  ABI_X86="(64) -32 (-x32)" 0 kB

[ebuild     U #] media-libs/mesa-10.0.3 [9.2.5] USE="classic egl gallium llvm nptl -bindist -debug -gbm -gles1 -gles2 -llvm-shared-libs -opencl -openvg -osmesa -pax_kernel -pic -r600-llvm-compiler (-selinux) -vdpau -wayland -xa -xvmc (-xorg%)" ABI_X86="(64) -32 (-x32)" VIDEO_CARDS="(-freedreno) -i915 -i965 -ilo -intel -nouveau -r100 -r200 -r300 -r600 -radeon -radeonsi -vmware" 6,631 kB

Total: 4 packages (1 upgrade, 3 new), Size of downloads: 6,915 kB
```

Gerard.

----------

## yuyuyak

@gerald82

Thank you for the information, I did see it at the time, but had nothing of value to add.

Actually I still do not have much, except to add the 10.x mesa series compiles fine for me with the new driver.  I have other issues with the nvidia-drivers-334.x series though that keeps me from using them.

----------

## ulenrich

Please, can someone give be a hint about all of the mesa USE flags!

Howto optimize for Kde and using proprietary nvidia drivers?

How are they related:

egl gallium lvm lvm-shared-libs opencv ....

Is there a wiki explaining?

```
$ uname -r ; emerge -p -1 xorg-drivers nvidia-drivers xorg-server mesa

3.13.6-1001.bfs

These are the packages that would be merged, in order:

Calculating dependencies  ... done!

[ebuild   R    ] media-libs/mesa-10.1.0  USE="-bindist classic -debug dri3 egl -gallium -gbm -gles1 gles2 -llvm -llvm-shared-libs nptl -opencl -openvg -osmesa -pax_kernel -pic -r600-llvm-compiler (-selinux) vdpau -wayland -xa -xvmc" ABI_X86="32 (64) (-x32)" VIDEO_CARDS="(-freedreno) -i915 -i965 -ilo -intel -nouveau -r100 -r200 -r300 -r600 -radeon -radeonsi -vmware" 0 kB

[ebuild   R    ] x11-base/xorg-drivers-1.15  INPUT_DEVICES="-acecad -aiptek -elographics evdev -fpit -hyperpen -joystick -keyboard -mouse -mutouch -penmount -synaptics -tslib -vmmouse -void -wacom" VIDEO_CARDS="-apm -ast -chips -cirrus -dummy -epson -fbdev -fglrx (-freedreno) (-geode) -glint -i128 (-i740) -intel -mach64 -mga -modesetting -neomagic -nouveau -nv nvidia (-omap) (-omapfb) -qxl -r128 -radeon -radeonsi -rendition -s3virge -savage -siliconmotion -sisusb (-sunbw2) (-suncg14) (-suncg3) (-suncg6) (-sunffb) (-sunleo) (-suntcx) -tdfx -tga -trident -tseng -v4l -vesa -via -virtualbox -vmware (-voodoo)" 0 kB

[ebuild   R    ] x11-base/xorg-server-1.15.0:0/1.15.0  USE="-dmx -doc ipv6 -kdrive -minimal nptl (-selinux) -static-libs -suid -tslib udev -unwind -xnest xorg -xvfb" 0 kB

[ebuild   R    ] x11-drivers/nvidia-drivers-334.21  USE="X acpi (multilib) -pax_kernel tools -uvm" 0 kB
```

----------

## aCOSwt

 *ulenrich wrote:*   

> Please, can someone give be a hint about all of the mesa USE flags!
> 
> Howto optimize for Kde and using proprietary nvidia drivers?

 

```
acoswt@PrimaPratica ~ $ equery depends mesa

 * These packages depend on mesa:

app-emulation/emul-linux-x86-opengl-20131008 (media-libs/mesa)

                                             (abi_x86_32 ? media-libs/mesa[abi_x86_32(-)])

dev-qt/qtgui-4.8.5-r1 (egl ? media-libs/mesa[egl])

kde-base/kwin-4.11.5 (opengl ? >=media-libs/mesa-7.10)

                     (gles ? >=media-libs/mesa-7.12[egl(+),gles2])

                     (wayland ? >=media-libs/mesa-9.0[egl(+),wayland])

virtual/glu-9.0 (<media-libs/mesa-9)

virtual/opengl-7.0 (media-libs/mesa)

www-client/firefox-24.2.0 (>=media-libs/mesa-7.10)

x11-apps/mesa-progs-8.1.0 (media-libs/mesa[egl?,gles1?,gles2?])

x11-base/xorg-server-1.14.3-r2 (!minimal ? >=media-libs/mesa-8[nptl=])

x11-libs/cairo-1.12.14-r4 (gles2 ? media-libs/mesa[gles2])

                          (opengl ? media-libs/mesa[egl])

                          (openvg ? media-libs/mesa[openvg])

                          (gallium ? media-libs/mesa[gallium])

x11-libs/gtk+-3.8.7 (wayland ? media-libs/mesa[wayland])
```

Tells me that kwin gets no special requirements regarding mesa (apart from those using the experimental wayland support)

However, you are likely to get cairo +opengl installed on your system in which case, you'll need mesa +egl, and if you get cairo +openvg, then you'll need mesa +openvg.

 *ulenrich wrote:*   

> How are they related: egl gallium lvm lvm-shared-libs opencv ....

 

then ebuild for my 9.1.6 tells me how they are related :

```
REQUIRED_USE="

   llvm?   ( gallium )

   openvg? ( egl gallium )

   gbm?    ( shared-glapi )

   gles1?  ( egl )

   gles2?  ( egl )

   r600-llvm-compiler? ( gallium llvm || ( video_cards_r600 video_cards_radeon ) )

   wayland? ( egl )

   xa?  ( gallium )

   xorg?  ( gallium )

   video_cards_intel?  ( || ( classic gallium ) )

   video_cards_i915?   ( || ( classic gallium ) )

   video_cards_i965?   ( classic )

   video_cards_nouveau? ( || ( classic gallium ) )

   video_cards_radeon? ( || ( classic gallium ) )

   video_cards_r100?   ( classic )

   video_cards_r200?   ( classic )

   video_cards_r300?   ( gallium )

   video_cards_r600?   ( gallium )

   video_cards_radeonsi?   ( gallium llvm )

   video_cards_vmware? ( gallium )
```

(setting llvm or openvg needs gallium to be set...)

As far as I am concerned with kde-4.11.5 + cairo + opengl + nvidia-drivers, I have mesa installed +egl, +nptl, +python_single_target_python2_7, +python_targets_python2_7, +shared-glapi, +vdpau

----------

## ulenrich

 *aCOSwt wrote:*   

>  cairo +openvg, then you'll need mesa +openvg.
> 
> ...
> 
> (setting llvm or openvg needs gallium to be set...)
> ...

 Thanks aCOSwt!

As you can see mesa-10 obsoleted shared-glapi!

I have a fine system running smoothly. But I want to know more about newer developments, where there is talk about everywhere but never explained:

- Is gallium (gallium3d?) only important for opensource drivers?

- llvm pipes can be used when not having any drm drivers available?

I find it hard to tell myself sometimes what of these make sense together. I have recently seen a bug in our bugtracker to widen further the possibilities by introducing more of USE flags regarding graphics. I feel overwhelmed ....

For example just read about the new anouncenment of the OpenGles-3.1 specification: Which is Opengl-4.0 but mobile. 

 :Sad:   :Wink:  ;(

----------

