# nouveau on 2.6.33 64bit

## Hetfield666

Hi all

I included the staging driver check but i cannot find any nouveau reference in it, nor drm.

can anyone help me in finding it?

thx

----------

## larophel

If you have to have Direct Rendering Manager (in Device Drivers -> Graphics Support) enabled for the "Nouveau (nVidia) cards" prompt in staging drivers to be visible.

From the help:

Depends on: STAGING [=y] && !STAGING_EXCLUDE_BUILD [=n] && DRM [=y]

----------

## Hetfield666

great i found it!!!!!

----------

## d2_racing

I will test this one on monday.

I hope that my little video card will handle this great driver.... at least I hope that's better then the nv driver.

----------

## Hetfield666

i have a strange issue.

on startup (no X) i don't have the console tty, i mean the monitor goes in stand-by as soon as kernel starts after the boot.

i think i need to pass some cmd line option, need to read more docs....maybe disable the vga fb driver.

----------

## alacheesu

 *Hetfield666 wrote:*   

> i have a strange issue.
> 
> on startup (no X) i don't have the console tty, i mean the monitor goes in stand-by as soon as kernel starts after the boot.
> 
> i think i need to pass some cmd line option, need to read more docs....maybe disable the vga fb driver.

 

I've struggled with this as well. Do you have fbcon.ko loaded? If not, you'll have a black console, but X should still work.

I finally gave up on the in-kernel driver. Here's what I ended up doing, which is working beautifully so far:

2.6.33-gentoo kernel, with the following options enabled:

Device drivers -->

  <*> I2C support -->

       I2C Algorithms -->

           <*> I2C bit-banging interfaces

    Graphics support -->

          <*> Support for frame buffer devices -->

                  [*]   Enable Video Mode Handling Helpers

                  [*]   Enable Tile Blitting Support

                  <M> VGA 16-color graphics support (I needed this to get some of the CONFIG_FB_CFB_XXXX enabled, I'm not actually loading it)

           [*] Backlight & LCD device support  --->

                  <*>   Lowlevel Backlight controls

           Console display driver support  --->

                  <*> Framebuffer Console support

Nouveau disabled in kernel, of course. 

I then emerged the latest ~amd64 versions of nouveau-firmware, nouveau-drm and xf86-video-nouveau. After loading the nouveau module it just worked.

If anyone can get the in-kernel driver to work I would be interested in that as well.

----------

## Hetfield666

i'm trying in-kernel built-in at the moment i will report it when i have it working

----------

## Hetfield666

ok the fb module works like a charm and actually resolution is better than the sw fb i had before.

but i cannot start X.

(--) PCI:*(0:1:0:0) 10de:0391:0000:0000 nVidia Corporation G73 [GeForce 7600 GT] rev 161, Mem @ 0xfa000000/16777216, 0xd0000000/268435456, 0xf9000000/16777216, I/O @ 0x0000bc00/128, BIOS @ 0x????????/131072                                                                                                                                                                  

(WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)                                                                                                               

(II) "extmod" will be loaded. This was enabled by default and also specified in the config file.                                                                                        

(II) "dbe" will be loaded. This was enabled by default and also specified in the config file.                                                                                           

(II) "glx" will be loaded. This was enabled by default and also specified in the config file.                                                                                           

(II) "record" will be loaded by default.                                                                                                                                                

(II) "dri" will be loaded. This was enabled by default and also specified in the config file.                                                                                           

(II) "dri2" will be loaded by default.                        

...bla bla bla...

(II) LoadModule: "nouveau"

(II) Loading /usr/lib64/xorg/modules/drivers/nouveau_drv.so

(II) Module nouveau: vendor="X.Org Foundation"

        compiled for 1.7.5, module version = 0.0.15

        Module class: X.Org Video Driver

        ABI class: X.Org Video Driver, version 6.0

(II) NOUVEAU driver

(II) NOUVEAU driver for NVIDIA chipset families :

        RIVA TNT    (NV04)

        RIVA TNT2   (NV05)

        GeForce 256 (NV10)

        GeForce 2   (NV11, NV15)

        GeForce 4MX (NV17, NV18)

        GeForce 3   (NV20)

        GeForce 4Ti (NV25, NV28)

        GeForce FX  (NV3x)

        GeForce 6   (NV4x)

        GeForce 7   (G7x)

        GeForce 8   (G8x)

(II) Primary Device is: PCI 01@00:00:0

drmOpenDevice: node name is /dev/dri/card0

drmOpenDevice: open result is 7, (OK)

drmOpenByBusid: Searching for BusID pci:0000:01:00.0

drmOpenDevice: node name is /dev/dri/card0

drmOpenDevice: open result is 7, (OK)

drmOpenByBusid: drmOpenMinor returns 7

drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0

(EE) [drm] failed to open device

(EE) No devices detected.

Fatal server error:

no screens found

so it looks like it finds the card but cannot init DRM. i don't care about DRM at the moment!

i just left the 

driver "nouveau" line..... nothing expecial  :Sad: ((

any idea?

----------

## alacheesu

What version of libdrm are you running? libdrm-2.4.18 is incompatible with in-kernel nouveau. libdrm-2.4.18_pre20100211 and earlier will work, according to this bug report

I'm not sure what else could be wrong. Here's my full xorg.conf for a dual head setup with nouveau:

```
Section "ServerLayout"

    Identifier     "X.org Configured"

    Screen      0  "Screen0" 0 0

EndSection

Section "Monitor"

    Identifier     "DVI-I-1"

    Option         "DPMS"

    Option         "PreferredMode" "1280x1024"

EndSection

Section "Monitor"

    Identifier    "DVI-I-2"

    Option        "RightOf" "DVI-I-1"

    Option         "DPMS"

    Option        "PreferredMode" "1920x1200"

EndSection

Section "Device"

    Identifier     "Device0"

    Driver         "nouveau"

EndSection

Section "Screen"

    Identifier     "Screen0"

    Device         "Device0"

    DefaultDepth    24

    SubSection     "Display"

        Depth       24

    EndSubSection

EndSection

```

----------

## M

I just tried in kernel nouveau and am getting the same error as Hetfield666

```
(EE) [drm] failed to open device 

(EE) No devices detected. 
```

That is with libdrm-9999 and mesa-9999. I tried many times before and always had some 3d support but now I can't start X. I also installed nouveau-firmware but am not sure if it is needed for NV4.

----------

## alacheesu

 *M wrote:*   

> I just tried in kernel nouveau and am getting the same error as Hetfield666
> 
> ```
> (EE) [drm] failed to open device 
> 
> ...

 

Does it work with a compatible version of libdrm?

----------

## Zeerak

I was initially getting the same error  as Hetfield.

I downgraded my lbdrm, and the error changed:

```
(II) [drm] nouveau interface version: 0.0.15

(EE) [drm] wrong version, expecting 0.0.16

(EE) No devices found
```

and this is with libdrm-2.4.18_pre20100211

----------

## Hetfield666

so at the moment the problem looks with xorg drm module.

any progress around_ i had to time to investigate bugzillas

----------

## Zeerak

Well perhaps this can be of help.

I haven't tried it out yet as I needed X quickly (and had already emerge nv driver). But perhaps one of you guys can test and report back?

----------

## alacheesu

I tried the in-kernel module since so many seem to have a problem with it. I can report that the following works for me:

linux-2.6.33-gentoo kernel w/nouveau compiled as a module

libdrm-2.4.18_pre20100211

nouveau-firmware-20091212

xf86-video-nouveau-0.0.15_pre20100213

Procedure:

emerge --unmerge nouveau-drm (if you have it)

compile and install kernel as usual

emerge =libdrm-2.4.18_pre20100211

emerge nouveau-firmware (if you need it)

emerge -1 xorg-server 

emerge -1 xf86-video-nouveau

reboot

 *Zeerak wrote:*   

> I was initially getting the same error  as Hetfield.
> 
> I downgraded my lbdrm, and the error changed:
> 
> ```
> ...

 

Did you rebuild xorg-server and xf86-video-nouveau after downgrading libdrm?

----------

## Hetfield666

the nouveau driver in portage doesn't build.

instead, i updated all to 0.0.16 using the nouveau-drm modules.

console works, while xorg DRM fails silently giving the "no device found" error.

really bored. i think i'll wait more before switching...

----------

## xaviermiller

So, till now, nobody can run the in-kernel nouveau drivers with xorg ?

----------

## agent_jdh

 *XavierMiller wrote:*   

> So, till now, nobody can run the in-kernel nouveau drivers with xorg ?

 

alacheesu above seems to have got it working with in-kernel drm by downgrading libdrm.

I've been keeping an eye on this thread myself as I really want to try nouveau, it might be an idea to let it be for a bit until the version numbers et al sort themselves out.

As a sort-of-related question, does this mean we will also get high-res accelerated console support, like fb support, or kms or whatever will do that.  Have to say, a lot of these recent developments have gone over my head as I've been using the nvidia binary driver, so a quick explanation of the current state of play would help (or link to such).

----------

## M

Yes, you get KMS, fast fb console, xv, very fast 2d rendering, a bit of composite and some kind of 3d   :Smile: 

I didn't really bother to downgrade libdrm and recompile, what I would like to know is if nouveau-drm is still updated? Does this ebuild still folows recently changes or what. After all this time nouveau is finally in the kernel and can not be used.

----------

## alacheesu

 *agent_jdh wrote:*   

> alacheesu above seems to have got it working with in-kernel drm by downgrading libdrm.
> 
> I've been keeping an eye on this thread myself as I really want to try nouveau, it might be an idea to let it be for a bit until the version numbers et al sort themselves out.

 

The easiest way, imo, is to not use the in-kernel nouveau, especially if you're on ~amd64. If you use the latest versions of ~amd64 packages in portage, everything will be 0.0.16 and thus compatible. Most likely they will upgrade together when a new API breakage occurs as well. The latest nouveau-drm doesn't need any extra firmware anymore, either. 

It's only when you run the in-kernel nouveau that you're likely to see "wrong version" errors, because the in-kernel nouveau is 0.0.15. I got that error as well, but it is fixable by downgrading libdrm and rebuilding xorg-server and xf86-video-nouveau.

----------

## jokerwww

Just to let everyone know that the in kernel drm does indeed work with the downgraded libdrm(and a rebuild of xorg-server and xf86-video-nouveau).

Is there any advantage to using nouveau-drm instead of in-kernel drm(other than not needing firmware)?

I'm running ~amd64 and the latest(as of yesterday) xf86-video-nouveau was 0.0.15? When did 0.0.16 hit the portage tree?

----------

## alacheesu

 *jokerwww wrote:*   

> Is there any advantage to using nouveau-drm instead of in-kernel drm(other than not needing firmware)?

 

According to the nouveau devs, the in-kernel drm won't be updated to 0.0.16 for "some time". If you want to run the latest version it's probably better to stick with nouveau-drm. I don't think there's much that separates them right now, though.

 *Quote:*   

> I'm running ~amd64 and the latest(as of yesterday) xf86-video-nouveau was 0.0.15? When did 0.0.16 hit the portage tree?

 

It's not in the portage tree, afaik. xf86-video-nouveau-0.0.15 works with the latest nouveau-drm and libdrm.

----------

## agent_jdh

Hmm, gave this a quick try after rebuilding my kernel.  Getting 'no screens found' in xorg log, it appears to attempt to load the nouveau driver though.  It does switch to VT7 and appears to change resolution though.  A quick obvious one - does it conflict with nvidiafb?  Starting with an empty xorg.conf file attempts to use the nv driver which I also have installed.  Mesa is built with nouveau USE flag.

----------

## alacheesu

 *agent_jdh wrote:*   

> A quick obvious one - does it conflict with nvidiafb?

 

nvidiafb is known not to work with nouveau, so you should definitely remove that.

----------

## d2_racing

With nouveau, you should remove all the framebuffer stuff and actually try to make run a stock version of nouveau  :Razz: 

----------

## larophel

I have been able to start X with the in-kernel nouveau without a problem. However, I have libdrm from they layman overlay installed. 

Unfortunately, using nouvea freezes my system after some time (mostly under load, but not always) so I had to go back to the nvidia drivers.

It used to not freeze with some old version of nouveau but that did not support resume from hibernate. 

I have a GT230M. Anyone experienced similar results?

----------

## agent_jdh

Still not working here for me.  The only way I could get the nouveau kernel driver to load was to include nvidiafb as a module in the kernel, because then it adds in CONFIG_FB_CFB_FILLRECT, COPYAREA, IMAGEBLIT and I2C_ALGOBIT, without which the nouveau module fails to modprobe.  Manually rmmod'ing nvidiafb and restarting X didn't help, still no screens found in Xorg log.

Giving up for now for a bit, unless someone is willing to help...

----------

## alacheesu

 *agent_jdh wrote:*   

> Still not working here for me.  The only way I could get the nouveau kernel driver to load was to include nvidiafb as a module in the kernel, because then it adds in CONFIG_FB_CFB_FILLRECT, COPYAREA, IMAGEBLIT and I2C_ALGOBIT, without which the nouveau module fails to modprobe.  Manually rmmod'ing nvidiafb and restarting X didn't help, still no screens found in Xorg log.
> 
> Giving up for now for a bit, unless someone is willing to help...

 

You didn't specify, but I assume you're running nouveau-drm? I ran into that as well. It seems you need a frame buffer device enabled to get those CONFIG_FB_CFB_foo enabled. You can use any frame buffer device, though, and it's better to select one that is known to be compatible with nouveau, like "VGA 16-color graphics support". I have that one enabled as a module, and I haven't run into any problems.

If you don't have it already, I2C_ALGOBIT can be enabled as Device drivers -> I2C support -> I2C Algorithms -> I2C bit-banging interfaces.

----------

## larophel

As far as I know nvidiafb is incompatible with nouveau. So, do as alacheesu suggested and use "VGA 16-color graphics support".

----------

## agent_jdh

Right-ho, will try and give that a go this evening, after firefox and thunderbird have been upgraded.  And yes, I'm using the nouveau-drm ebuild instead of the in-kernel modules.

EDIT - I don't know where I got this from, but is it entirely possible that nouveau doesn't work with DVI output on a GF 7600GT yet?  Just a thought, because that's my set-up.

----------

## s4e8

new git kernel has the nouveau ABI 0.0.16, and work fine except float texture.

----------

## agent_jdh

OK, it _nearly_ works.  Got around the problem with needing nvidiafb to select the required FB_CF_foo modules (and the ALGOBIT one) by building the matroxfb module instead.  Using vga16 doesn't select the I2C_ALGOBIT module.  Anyway.  It boots now, but when (presumably) the nouveau module gets loaded, my monitor goes into power saving mode, but a few seconds later it recovers, and presents me with the KDM login screen.

HOWEVER

I can log in, and the KDE startup process kicks in, but then the display goes white -> black -> grey-ish, the cursor is always there, and if I click on e.g. where the KDE 'start' button is I can see a ghosted outline of the menu.  I guess this may have something to do with KDE compositing options, so I may try again with it disabled.  From the Xorg log, it looks like it's starting in software rendering mode, which would probably explain this.  Is mesa-9999 or whatever required for direct rendering?

I can't switch to a console with ctrl+alt=Fx - just gives me a blank screen.  Booting my failsafe kernel and looking at /var/log/messages, I see this -

```
[drm:drm_mode_getfb] *ERROR* invalid framebuffer id
```

Which looks fairly terminal *cough*  A quick Google doesn't really tell me much other than someone else is seeing this with nouveau, but no solutions are offered.

Any tips?

----------

## alacheesu

vga16 doesn't select I2C_ALGOBIT, but it doesn't have to. Just enable it yourself in kernel config: Device drivers -> I2C support -> I2C Algorithms -> I2C bit-banging interfaces. 

I would try using that one first. Most frame buffer devices won't work with nouveau.

----------

## agent_jdh

 *alacheesu wrote:*   

> vga16 doesn't select I2C_ALGOBIT, but it doesn't have to. Just enable it yourself in kernel config: Device drivers -> I2C support -> I2C Algorithms -> I2C bit-banging interfaces. 
> 
> I would try using that one first. Most frame buffer devices won't work with nouveau.

 

The option doesn't appear for me - I can only get it by selecting a framebuffer device that forces it, so I chose matroxfb as udev wouldn't load it.  I don't even get the I2C Algorithms section in menuconfig.

----------

## alacheesu

 *agent_jdh wrote:*   

> The option doesn't appear for me - I can only get it by selecting a framebuffer device that forces it, so I chose matroxfb as udev wouldn't load it.  I don't even get the I2C Algorithms section in menuconfig.

 

Go to Device drivers -> I2C support and disable "Autoselect pertinent helper modules". I2C Algorithms should then show up.

If you're doing a "make menuconfig" you can press / and search for I2C_ALGOBIT. It will tell you both the location and dependencies. I2C_ALGOBIT has the following dependencies

```
Depends on: I2C && !I2C_HELPER_AUTO
```

In other words, I2C selected and I2C_HELPER_AUTO not selected. I assume you have I2C selected, which leaves only I2C_HELPER_AUTO.

----------

## agent_jdh

 *alacheesu wrote:*   

>  *agent_jdh wrote:*   The option doesn't appear for me - I can only get it by selecting a framebuffer device that forces it, so I chose matroxfb as udev wouldn't load it.  I don't even get the I2C Algorithms section in menuconfig. 
> 
> Go to Device drivers -> I2C support and disable "Autoselect pertinent helper modules". I2C Algorithms should then show up.
> 
> If you're doing a "make menuconfig" you can press / and search for I2C_ALGOBIT. It will tell you both the location and dependencies. I2C_ALGOBIT has the following dependencies
> ...

 

Ah, the key part is this - "disable "Autoselect pertinent helper modules" - I'd not fully looked at the deps when I searched for ALGOBIT.

Trying it again... according to the nouveau wiki, the VESA fb device is fully compatible, so I've compiled fb support straight into the kernel which enables my to use vesa instead of vga16, will report back.

EDIT - nouveau-drm ebuild reports vesafb is enabled but shouldn't be.   Hmmm.  Rebuilding kernel without it, but keeping fb support compiled-in and the matroxfb driver as a module to ensure the correct FB_CFB modules get built.

----------

## agent_jdh

WAHEY!  It works.  Seems that building fb support into the kernel instead of as a module is key.  Also emerged the nouveau-firmware package, but afaik I shouldn't need that with my card (G73).

And disabling desktop effects allows me to log into KDE successfully.  2D is WAY better than nv driver.

So the only problem now is that it's using software rendering, 

```
(EE) AIGLX error: dlopen of /usr/lib/dri/nouveau_dri.so failed (/usr/lib/dri/nouveau_dri.so: cannot open shared object file: No such file or directory)

(EE) AIGLX: reverting to software rendering

(II) AIGLX: Screen 0 is not DRI capable

(II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so

(II) GLX: Initialized DRISWRAST GL provider for screen 0
```

I'm guessing /usr/lib/dri/nouveau_dri.so is meant to be provided by mesa with VIDEO_CARDS="nouveau", which is already set, as it provides /usr/lib/dri/swrast_dri.so.  Do I need an updated (9999?) mesa?  Got media-libs/mesa-7.7-r1 installed here.

Console in 1920x1080 is nice, beats 640x480 stretched at the wrong aspect for sure... and switching between X and console is lightning fast (as expected).  Wow!

EDIT - OK switching compositing to using XRender instead of OpenGL in KDE allows desktop effects, which are understandably a bit slower, (mainly the fade in switching between virtual desktops), but still usable.  I didn't really miss them to be honest.  There are another couple of slight oddities in KDE (e.g. System Activity window doesn't show CPU usage) but nothing major yet.

Any idea how to get a bigger font in the console?  Using lat9w-16 here, it's a little bit too small, but 16 looks like the biggest font there is.

----------

## j-kidd

 *agent_jdh wrote:*   

> 
> 
> EDIT - nouveau-drm ebuild reports vesafb is enabled but shouldn't be. Hmmm. Rebuilding kernel without it, but keeping fb support compiled-in and the matroxfb driver as a module to ensure the correct FB_CFB modules get built.
> 
> 

 

I think the nouveau-drm ebuild wrongly prints out the warning for vesafb, because vesafb is compatible according to the nouveau wiki, and I have it enabled and nothing breaks.

 *agent_jdh wrote:*   

> 
> 
> I'm guessing /usr/lib/dri/nouveau_dri.so is meant to be provided by mesa with VIDEO_CARDS="nouveau", which is already set, as it provides /usr/lib/dri/swrast_dri.so. Do I need an updated (9999?) mesa? Got media-libs/mesa-7.7-r1 installed here.
> 
> 

 

Yup, mesa-9999 does provide nouveau_dri.so, though with my nv40 card, everything shows up as either "Slow" or "None" from the ouput of glxinfo   :Laughing: 

BTW, the mesa-9999 ebuild has to refetch 100MB everytime it get emerged. That's totally insane. I don't think that's how git is supposed to work   :Rolling Eyes: 

----------

## agent_jdh

 *j-kidd wrote:*   

>  *agent_jdh wrote:*   
> 
> EDIT - nouveau-drm ebuild reports vesafb is enabled but shouldn't be. Hmmm. Rebuilding kernel without it, but keeping fb support compiled-in and the matroxfb driver as a module to ensure the correct FB_CFB modules get built.
> 
>  
> ...

 

Yup, copied the mesa ebuild to my local overlay, renamed it to 9999, did the git thing and I'm got it to build with gallium support.  Like you, on my NV40/G73 glxinfo shows everything as slow or none, but I guess that's to be expected.

Also like you, I'd have expected git just to pick up the changes when you re-emerge the mesa live ebuild.

----------

## urcindalo

 *agent_jdh wrote:*   

> WAHEY!  It works.

 

Would you mind explaining what you have finally installed, which versions, and how did you configure everything to make it work? Thanks very much in advance.

I'd like to migrate from nv to nouveau in my production box and I can't afford the time for trial & error  :Sad: 

----------

## R_W

I got it working with kernel 2.6.33 with framebuffer VGA 16-color graphics support enabled, using the following packages from portage:

xorg-server-1.7.5.901

mesa-7.7-r1

nouveau-drm-20100226

libdrm-2.4.18

xf86-video-nouveau-9999 (so built from git since portage does not seem to have a 0.0.16 version, only 0.0.15. Git-ebuild for this package can be found in "x11" overlay)

Any more info you need I'll be happy to provide.

----------

## alunduil

Was there any other kernel options you needed to enable or disable to get this working?

----------

## urcindalo

 *R_W wrote:*   

> libdrm-2.4.18

 

Thanks for your kind help.

I have a doubt, though: libdrm is currently at version 2.4.19 in the x11 overlay. Is it OK to use this version or is it necessary to use the previous 2.4.18 version?

Any other framebuffer support in kernel apart from VGA-16? More precisely, should I remove any other built-in framebuffer support I may have selected right now?

----------

## R_W

 *alunduil wrote:*   

> Was there any other kernel options you needed to enable or disable to get this working?

 

You need to disable CONFIG_DRM since nouveau-drm provides it. There were some other things related to I2C I had to enable for nouveau-drm to compile. I'm not 100% sure I can remember all of them, but as mentioned earlier in this topic I disabled CONFIG_I2C_HELPER_AUTO and enabled CONFIG_I2C_ALGOBIT (I think the nouveau-drm ebuild complains about this if it's not set so you'll run into it regardless).

 *urcindalo wrote:*   

> I have a doubt, though: libdrm is currently at version 2.4.19 in the x11 overlay. Is it OK to use this version or is it necessary to use the previous 2.4.18 version?

 

I imagine 2.4.19 will work just as well, I haven't tried it though. The only reason I installed 2.4.18 instead of 2.4.19 is that I try to minimize the number of packages I have installed from overlays since the portage ebuilds are a little more stable I think. This is just a "feeling" more than anything though.

 *Quote:*   

> Any other framebuffer support in kernel apart from VGA-16? More precisely, should I remove any other built-in framebuffer support I may have selected right now?

 

VGA-16 is the only framebuffer I have enabled. I don't know if you *have* to disable the rest. I think you should definitely disable the nVidia framebuffer.

N.B. I'm no expert, this is just the info I gathered by reading/trying.  :Smile: 

----------

## alacheesu

You don't need to use overlays at all. Everything you need is in portage now. All the relevant ~amd64 keyworded packages are compatible.

In the kernel I think you need at least this:

```
Device drivers --->

  <*> I2C support  --->

    <*>   I2C device interface

       [ ]   Autoselect pertinent helper modules

           I2C Algorithms  --->

                <*> I2C bit-banging interfaces

  Graphics support  --->

      <*> Support for frame buffer devices  --->

          [*]   Enable Video Mode Handling Helpers

          [*]   Enable Tile Blitting Support

         <M>   VGA 16-color graphics support

      [*] Backlight & LCD device support  --->

         <*>   Lowlevel Backlight controls

      Console display driver support  --->

         <*> Framebuffer Console support

```

Disable all other frame buffer devices. You want to use the nouveau frame buffer anyway, but you need VGA-16 (or VESA) to get some needed modules built even though you won't be using it.

Let me know if this works for you or if you had to change anything. Maybe we can eventually make a decent step by step guide so other people don't have to spend time figuring this out.

----------

## R_W

So you're using xf86-video-nouveau-0.0.15_pre20100213? This seems odd to me 'cause this commit breaks the interface (if you scroll all the way down you see they completely changed it, breaking backwards-compatibility). 

Unless you are using versions of nouveau-drm and libdrm which are also on version 0.0.15. Can you post all the versions you're using like I did few posts back?

[edit]

xf86-video-nouveau-0.0.15_pre20100213 seems to work fine here as well. So it seems that xf86-video-nouveau does not depend on the userspace interface and can work with both 0.0.15 and 0.0.16 of drm. Can someone confirm this?

Maybe, if this is the case, the "0.0.15" should be dropped from the version # to prevent confusion.

----------

## alacheesu

Yes, I'm using that version. It's libdrm and nouveau drm that have caused some people problems. xf86-video-nouveau seems unaffected. Quoting the nouveau wiki:

 *Quote:*   

> 16.2.2010 posted by xavier+pq
> 
> Bump of the userspace interface to 0.0.16.
> 
> libdrm and nouveau drm have to be updated together for nouveau to keep working. The kernel.org version will not work with the current git user space for some time. See the kernel commit log for more information. 

 

The gentoo maintainer of nouveau has this bug report about compatibility issues. I run mesa-7.7-r1 and libdrm-2.4.18, though, but according to the bug report those are not compatible.

----------

## larophel

 *R_W wrote:*   

> I got it working with kernel 2.6.33 with framebuffer VGA 16-color graphics support enabled, using the following packages from portage:
> 
> 

 

Have you experienced any freezing while using it? Which graphic card do you have?

----------

## urcindalo

 *alacheesu wrote:*   

> Yes, I'm using that version. It's libdrm and nouveau drm that have caused some people problems.

 

So, to get things straight: is libdrm-2.4.19 from the x11 overlay *incompatible* with portage's nouveau-drm-20100226?

Currently I have libdrm-2.4.19 and I want to make sure if I need to downgrade it to 2.4.18.

Thanks.

EDIT: I have removed libdrm-2.4.19 and installed 2.4.18.

Everything works, but I lost the ability to change to text consoles. Whenever I press Control+Alt+F1 all I can see is a black window with a flashing grayish-color underscore in the upper left corner of the screen. Is this normal?

----------

## urcindalo

 *urcindalo wrote:*   

> Everything works, but I lost the ability to change to text consoles. Whenever I press Control+Alt+F1 all I can see is a black window with a flashing grayish-color underscore in the upper left corner of the screen. Is this normal?

 

I solved it. I ran xorg-server without xorg.conf, and it turns out vesa was chosen as the driver. So, I installed this very tiny xorg.conf:

```
Section "Device"

    Identifier  "tarjeta nVidia GeForce"

     Driver      "nouveau"

     Option      "DPMS" "on"

EndSection
```

That is my whole xorg.conf. With this setup everything works, including the change to text consoles. I'm a happy camper   :Very Happy: 

----------

## Hetfield666

Hi all

i'm writing from kde 4.4 and nouveau driver. it works cool  :Smile: 

the only thing i notice is that, even with gallium3d enabled i don't get kwin composing.

glxinfo show lots of ext and direct rendering is on.

any idea how to force it?

----------

## Hetfield666

ok it looks like we need to switch from OpenGL to Xrender extension in kwin composing

uses more cpu but works great  :Smile: 

i just would like to compile the git tree in the kernel now in order to have the driver immediatly loaded on startup

----------

## agent_jdh

 *Hetfield666 wrote:*   

> ok it looks like we need to switch from OpenGL to Xrender extension in kwin composing
> 
> uses more cpu but works great 
> 
> i just would like to compile the git tree in the kernel now in order to have the driver immediatly loaded on startup

 

I think I might have mentioned the XRender thing earlier in the thread - KDE won't even start properly here w/ opengl enabled, had to manually edit the config file at the console to switch off compositing, then re-enable it and change to Xrender.  I'm seeing a few KDE oddities as well, such as systemsettings disappearing from my menu, and system activity (ctrl+esc) not displaying cpu usage correctly.

With you on wanting nouveau from boot - might be time for an initrd kernel - I'd really like to have a nice Gentoo boot screen, after 13 years of watching text scroll by as Linux boots.

----------

## Hetfield666

that's no need to force by editing config file

in kde the display-> effects menu will disable composing, and forcing it will not succed.

then you switch to Xrender and apply.

some effects like windows rotating will be notified as down, but others as transparency are fine.

if anything fail you have the windows-style 10 secs dialog to confirm or revert

----------

## agent_jdh

The point I was making (in case others see this) was that in my case, I was forced to manually edit the relevant kde config file at the console because enabling opengl compositing (and it was enabled ,as I'd been using the nvidia binary drivers) renders KDE totally unusable - it allows you to login, but when the desktop starts to load and (presumably) it enables compositing, the screen goes black and all you can see of any windows on the desktop is a dark grey background.  So there was physically no way I could open systemsettings to make the changes as I would normally.

The relevant file incidentally is 

```
~/.kde4/share/config/kwinrc
```

 where one can switch the Backend to XRender, thus making KDE usable again.  Or indeed just disable compositing entirely if that is proving too slow / using too much CPU.

----------

## Hetfield666

it realyl strange as on startup it checks for composing capabilities and automatically disables it.

i switched from nvidia too and never had any crash or black screen.

the only black screen is when i mark "do not check config" (but goes away in 10 secs)....maybe u had that checkbox marked.

----------

## agent_jdh

I had "Disable functionality checks" ticked, if that's what you mean - I must have changed it at some point and forgotten, which is presumably why I got the black screen.  I've not got a particularly powerful system by today's standards and iirc KDE was disabling compositing constantly when my box was under load.

Probably explains it.

----------

## Hetfield666

ok, now we got the reason why you had the crash on startup so  :Smile: 

----------

## regomodo

I've finally got nouveau to work after ~4hrs this afternoon. No matter what I tried I could not get 2.6.33.1's nouveau to work with X but console worked fine.

My setup:

linux-2.6.33.1 (no drm or nouveau. Device drivers -> I2C support and disable "Autoselect pertinent helper modules" was set. Disabled VGA16fb)

mesa-7.7

xorg-server-1.7.6

x11-base/nouveau-drm-20100316

x11-libs/libdrm-2.4.18_pre20100211-r1 (I may try 2.19)

Composiiting in KDE4.4 works after a fashion (xrender only). It's very sluggish doing most of the effects so i've kept it minimal. 

The only major issue I have is the inability to set a monitor profile which is a major thing.

----------

## Hetfield666

Hi all

with mesa 7.8 i unmasked the gallium flag and i'm now running hw acceleration under X!

glxgears shows about 800 fps/s

bad thing is that under kde 4.4 i must continue to use Xrender as OpenGL get automatically disabled.

i'm on a geforce 7600GT

----------

## Dominique_71

I try nouveau. As I need CONFIG_DRM into the kernel for xf86-video-virtualbox, the only choice I have is to use the nouveau in-kernel driver. It is working fine with gentoo-sources-2.6.36, nouveau for X vesafb for the consoles, but a little problem remain, I cannot switch the screen resolution in X with CTRL-Alt_+ and CTRL-Alt--.

It is a must have feature for me and it is working fine with the nvidia driver. Is it not possible with nouveau and the same xorg.conf or am I missing something?

----------

## chithanh

Please open a new thread for such inquiry, it is no use resurrecting such an old thread.

----------

