xorg.conf

[SteveRiley]

Ah, hm.... I didn't realize that this thread is in the Trusty forum! Oops. My nVidia-equipped laptop is still running Saucy. I wonder if that's the difference?

[oshunluvr]

Ah, hm.... I didn't realize that this thread is in the Trusty forum! Oops. My nVidia-equipped laptop is still running Saucy. I wonder if that's the difference?

I'm on saucy too. I wonder what is causing the disparity.

[GreyGeek]

To fill in some details. I decided to try to activate the NVidia chip through the hardware app. It downloaded a driver from their website and installed it. When I rebooted I got a black screen. I logged in using the root terminal in the recovery mode. I used apt to unload the driver downloaded from Nvidia and rebooted. Got another black screen. I looked at the lsmod list and noticed that the nvidia kernel module was being loaded this time. I unloaded it and modprobed the nouveau driver, did "depmod -a" and rebooted. I got my desktop back. That's when I noticed the xorg.conf.03072014 files setting in /etc/X11. A little while later, on March 11th, came another kernel update. I didn't get a black screen, but 3D was unstable and firefox was constantly locking up with ring buffer errors. That's when I tried Chromium and SRIron, but didn't like them. That's when I noticed that setting next to xorg.conf.03072014 was xorg.conf.03112014. I restored my modified xorg.conf file, logged out and back in, and got a stable 3D screen back!

[abalone]

Am I completely off base here? Since nvidia-331 (at least on trusty) recommends "nvidia-prime (>= 0.5) | bumblebee", and since recommends are treated as dependencies by default, and since these are for systems with Nvidia Optimus hybrid graphics, and bumblebee at least uses its own xorg.conf files under /etc/bumblebee... wouldn't it make sense that the presence of either one of those packages (nvidia-prime or bumblebee) would remove the 'standard' nvidia-activating xorg.conf so the system will start up using the 'cheaper' graphics?

Just odd that it does that even on desktop systems with nvidia-only graphics.

[SteveRiley]

Am I completely off base here? Since nvidia-331 (at least on trusty) recommends "nvidia-prime (>= 0.5) | bumblebee", and since recommends are treated as dependencies by default, and since these are for systems with Nvidia Optimus hybrid graphics, and bumblebee at least uses its own xorg.conf files under /etc/bumblebee... wouldn't it make sense that the presence of either one of those packages (nvidia-prime or bumblebee) would remove the 'standard' nvidia-activating xorg.conf so the system will start up using the 'cheaper' graphics?

Ding ding ding! I believe you may have at least revealed a clue, if not the actual answer. Because I have no need for or interest in Bumblebee/Optimus/SlicedVideoBread, I have the following:

steve@t520:~$ [B]cat /etc/apt/preferences.d/no-bumblebee-prime[/B] 
Package: bumblebee
Pin: version 0.0
Pin-Priority: -1

Package: bumblebee:i386
Pin: version 0.0
Pin-Priority: -1

Package: nvidia-prime
Pin: version 0.0
Pin-Priority: -1

Package: nvidia-prime:i386
Pin: version 0.0
Pin-Priority: -1

This APT preferences file prohibits the installation of Bumblebee and Prime packages. I created it months ago and then (as usual) promptly forgot about it. This would appear to explain why I'm not experiencing the xorg.conf replacement that everyone else has written about.

[GreyGeek]

THanks for posting that file, Steve. I am going to install it. When my Intel graphics started working as fast with the nouveau driver as the GT 650M did with Bumblebee I stopped using Bumblebee. My big mistake was experimenting with the "Hardware Activation" screen to see what would happen in Trusty if I activated my secondary graphics chip. I found out.

[Teunis]

In the mean time an update on the 14th. had again disabled xorg.conf.

[SteveRiley]

If someone who's experiencing this problem could report a packaging bug, that would be cool. Instructions here: https://launchpad.net/~xorg-edgers

BUG REPORTS:
The idea is that you file bugs and especially regressions directly upstream at bugs.freedesktop.org If you are not sure or you think it is a packaging issue, file a bug as normal in launchpad (using "ubuntu-bug xorg" or the name of the package) but mark the bug with "[xorg-edgers]" in the title and subscribe the last uploader. Please tell which was the last version to work and the first one to fail. For upstream, the git commit identifier (the 8 hexadecimal digits after the date in the package version) is the most precise version information.

[abalone]

Done, but (a) with very little bug reporting experience and (b) for the vanilla Ubuntu 14.04 package (I'm not using xorg-edgers)

[SteveRiley]

Interesting... yes, I see that in Trusty, the default nvidia-331 includes nvidia-prime or bumblebee as recommended, just like the Xorg-Edgers PPA does. Did you file the bug against xorg or against nvidia-331?

[abalone]

...

[abalone]

Against the nvidia-graphics-drivers-331 source package, which probably didn't make the most sense if the issue lies with the packaging/dependencies. To be honest, it took me long enough just to figure out how to report a bug at all (I've done it before but keep forgetting how)

[Spadge]

Hm. Version 331.49? My system updated to that recently. My hand-crafted xorg.conf remained untouched.

steve@t520:~$ [B]cat /etc/X11/xorg.conf[/B]
Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "NVS 4200M"
    Option         "TripleBuffer" "1"
    Option         "OnDemandVBlankInterrupts" "1"
    Option         "RegistryDwords" "EnableBrightnessControl=1"
    Option         "RegistryDwords" "PerfLevelSrc=0x2222; PowerMizerLevel=0x3; PowerMizerLevelAC=0x3; PowerMizerDefault=0x3; PowerMizerDefaultAC=0x3"
EndSection

Interesting ...

I'm not using a mobile machine, so am not bothered about the power settings. I've found another way to fix the tearing, so am not bothered about the vblank or triple buffer ... I am a bit excited about the brightness control setting though. Does that fix the age-old problem with brightness settings made in nvidia-settings not persisting beyond the next reboot?

Meanwhile ... gtkperf Total time: 3.33 - fresh after booting. No tearing, brightness etc loaded on startup, things have never been so good.

Thanks

[SteveRiley]

I am a bit excited about the brightness control setting though. Does that fix the age-old problem with brightness settings made in nvidia-settings not persisting beyond the next reboot?

No. Brightness always is 100% on boot.

Edit: see below. Apparently preserving the brightness setting works on certain configurations.

[Spadge]

No. Brightness always is 100% on boot.

While I agree with what you're saying, it's also true that my settings are now loading after a reboot for the first time in a long time.