Bugzilla Bug 176135

the nvidia-drivers package doesn't install the nvidia-xconfig package. Also
technically it should probably provide nvidia-settings rather then our source
based once since I've heard the binary one is better tuned to each driver set
and comes out more often the source based one.

For xconfig, see bug #129446.

Created an attachment (id=117320) [details]
nvidia-drivers-100.14.03.ebuild

Installs nvidia-settings and nvidia-xconfig. Works on x86.

I have been running this for a few days on an amd64 machine and it appears to
be working fine.

I have also tried to run on an amd64 machine with gtx8800 and it works fine.

According to NVIDIA_ChangeLog, 100.14.13 supports SLI with gtx8800 but
unfortunately I don't have another gtx8800 to test.

NVIDIA_ChangeLog:
    * Added support for Quadro FX 4600 and Quadro FX 5600.
    * Added support for SLI with GeForce 8800, Quadro FX 4600,
      and Quadro FX 5600.

The problem that windows will be filled with black suddenly seems to have been
fixed but it is not certain.

Created an attachment (id=117671) [details]
nvidia-drivers-100.14.03.ebuild

Added checks that "nvidia" and "libGL.la-r2" are present in $FILESDIR,
otherwise they are installed as empty files, causing people like me to make
stupid errors as in bug #176423.

I did try this new ebuild example from Bredbury and again did run into this
sandbox failure:
http://bugs.gentoo.org/show_bug.cgi?id=176791
http://bugs.gentoo.org/show_bug.cgi?id=135745

Because nvidia-settings is now installed by this package. Sensors-applet which
depends on it and requires some header files failed to build.

checking for NVCtrl/NVCtrl.h... no
checking for NVCtrl/NVCtrlLib.h... no
configure: error: The NV-CONTROL header files cannot be found! make sure you
have installed nvidia-settings.

Not sure which package should install those. It would seem logical that
nvidia-drivers would do.

Created an attachment (id=118826) [details]
nvidia-drivers-100.14.03.ebuild

(In reply to comment #7)
> checking for NVCtrl/NVCtrl.h... no
> checking for NVCtrl/NVCtrlLib.h... no

The nvidia-drivers source file does not contain those headers.

This ebuild includes all of nvidia-settings also, using the nvidia-settings
executable from nvidia-drivers.

I just ran across this filesdir problem:

!!! ERROR: x11-drivers/nvidia-drivers-100.14.03 failed.
Call stack:
  ebuild.sh, line 1614:   Called dyn_install
  ebuild.sh, line 1060:   Called qa_call 'src_install'
  environment, line 4333:   Called src_install
  nvidia-drivers-100.14.03.ebuild, line 230:   Called die

!!! nvidia missing in FILESDIR

I'm somewhat lost as of what I can do to solve this problem, as I don't know
what's supposed to be in "nvidia".

(By the way:
The ebuild should download "NVIDIA_glx-defines.patch" and
"NVIDIA_glx-glheader.patch" to the files directory if needed, so it doesn't
complain about their absence during epatch.)


emerge --info
Portage 2.1.2.2 (default-linux/x86/2007.0/desktop, gcc-4.1.1, glibc-2.5-r2,
2.6.21.1 i686)
=================================================================
System uname: 2.6.21.1 i686 AMD Athlon(tm) XP 1700+
Gentoo Base System release 1.12.9
Timestamp of tree: Sat, 12 May 2007 22:30:10 +0000
ccache version 2.4 [disabled]
dev-java/java-config: 1.3.7, 2.0.31-r5
dev-lang/python:     2.3.5-r3, 2.4.4-r4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.4-r6
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.16
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf
/etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c"
CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks fixpackages metadata-transfer parallel-fetch sandbox
sfperms strict"
GENTOO_MIRRORS="http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/
ftp://gentoo.inode.at/source/ ftp://ftp.tu-clausthal.de/pub/linux/gentoo/
rsync://mirrors.sec.informatik.tu-darmstadt.de/gentoo"
LANG="de_DE@euro"
LC_ALL="de_DE@euro"
LINGUAS="de"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="3dnow 3dnowext 7zip X a52 acl acpi alsa amarok arj asf bash-completion
berkdb binary-drivers bitmap-fonts blender-game bzip2 cairo cal3d canna
cdparanoia cdr cegui cg chroot cjk cli connectionstatus cracklib crypt cscope
css cups dbus de_tvtoday devil dia divx dmi dri dv dvd dvdr dvdread eds effects
emboss enca encode evo exif fam fame fat firefox flac fortran ftp fuse gdbm gif
gimp gimpprint gpm gstreamer gtk hal hddtemp highlight history iconv icq
imagemagick immqt-bc inkjar ipv6 isdnlog ivtv jpeg jpeg2k kde kerberos latex
latin1 ldap libclamav libg++ lm_sensors logitech-mouse logrotate mad midi
mikmod mmx mmxext mng mozilla mozsvg mp3 mpeg mplayer ncurses no-old-linux
no-seamonkey nowlistening nptl nptlonly ntfs nuv nvidia offensive ogg ogre
on-the-fly-crypt openal openexr opengl oscar oss pam parse-clocks pcre pdf perl
plotutils plugin png posix postproc postscript povray ppds pppd print python
qt3support qt4 quicktime rdesktop readline real realmedia reflection reiser4
reiserfs replytolist samba scanner sdl session spell spl sse sse2 ssl
startup-notification subtitles svg swat symlink tcpd tetex texteffect theora
tidy tiff truetype truetype-fonts tta tv_check type1-fonts unicode usb
userlocales v4l v4l2 vcd vim vim-syntax vim-with-x visualization vorbis
win32codecs winpopup wireshark wma wmf wmp x86 xcb xcomposite xine xml xorg xpm
xv xvid xvmc zip zlib" ALSA_CARDS="intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym
copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat
linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc"
INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz
cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de"
LIRC_DEVICES="hauppauge" USERLAND="GNU" VIDEO_CARDS="nvidia"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS,
PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

Get the files from:

/usr/portage/x11-drivers/nvidia-drivers/files/
/usr/portage/media-video/nvidia-settings/files/icon/

FILESDIR is *not* a directory that ebuilds put files into. This is a test of
your knowledge of how ebuilds work ;)

(From update of attachment 118826 [details])
Renamed from 03 to 06, for version bump.

nvidia-drivers-100.14.06 works fine with my 8600GTS.

It's critical that these drivers go into portage, as they're the only ones to
support 8600 and 8500 video cards!!!

Just tested attached nvidia-drivers-100.14.03.ebuild on x86/GF6600 PCIe.
Renamed it to nvidia-drivers-100.14.06.ebuild. Emerges and works fine!

Also note that >=nvidia-drivers-100.14.03 fixes the slow scrolling with AA
fonts/subpixel rendering in konsole and konqueror etc.!

Renaming this to nvidia-drivers-100.14.06.evuild does not work for me.  I get
the following error message:

>>> Install nvidia-drivers-100.14.06 into /var/tmp/portage/x11-drivers/nvidia-drivers-100.14.06/image/ category x11-drivers
 * Installing nvidia module

!!! ERROR: x11-drivers/nvidia-drivers-100.14.06 failed.
Call stack:
  ebuild.sh, line 1615:   Called dyn_install
  ebuild.sh, line 1061:   Called qa_call 'src_install'
  ebuild.sh, line 44:   Called src_install
  nvidia-drivers-100.14.06.ebuild, line 230:   Called die

!!! nvidia missing in FILESDIR

When you copy it to your own overlay, you need to remember to copy over the
FILESDIR

I did copy FILESDIR.  I also double checked to make sure I had everything in
FILESDIR and I do.  This whole thing is strange as I was able to get the
100.14.03 ebuild to work a few weeks back.  I did have a significant issue with
it though and I backed it out.  So I was surprised that this one failed to
install.

Created an attachment (id=121512) [details]
nvidia-drivers-100.14.09.ebuild

More little formatting tidyups. Version bump. Changelog:
http://www.nvidia.com/object/linux_display_ia32_100.14.09.html

I actually have an ebuild all written up and ready to commit. The only problem
I have is now nvidia has 2 sets of legacy drivers and I'm not sure how to
handle the versioning.

I've been planning on writing an eclass to handle everything via lspci to check
out your graphics card however, I first need to find a list of what cards are
supported by each driver and what's dropped from support. I'm sure it's out
there but I haven't looked.

Essentially the idea is to make a call out to lspci during pkg_setup and inform
people what they should mask in their /etc/portage/package.mask for the best
support. i.e. if their card is only supported up the the 96xx series it would
inform them they need to mask 9700 and higher.

In the appendix A of the README of every package there is a List of Card that
it's supported. I attach them.

Created an attachment (id=121515) [details]
Graphics card supported with driver 7485

Created an attachment (id=121516) [details]
Graphics card supported with driver 9639

(In reply to comment #18)
> I've been planning on writing an eclass to handle everything via lspci to check
> out your graphics card however, I first need to find a list of what cards are
> supported by each driver and what's dropped from support. I'm sure it's out
> there but I haven't looked.
> 
> Essentially the idea is to make a call out to lspci during pkg_setup and inform
> people what they should mask in their /etc/portage/package.mask for the best
> support. i.e. if their card is only supported up the the 96xx series it would
> inform them they need to mask 9700 and higher.
> 

Imho, this is too dificult. I have anover idea.
May be it's need add new VIDEO_CARDS flags for nvidia-driver, for examle:
tnt, tnt2, gf, gf2, gf3, gf4, gf5, gf6, gf7, gf8, etc.
Ebuild should detect compatibility of flags (for example, gf6 and gf8 are
compatible, but tnt and gf8 are not) and build best driver for them.
This is not very accurate, but it helps to provide working for most people
nvidia driver via one ebuild and without any masking/unmasking.
Ebuild version should be set from latest NVIDIA package (currently 100.14.09).
As You say ebuild may detect via lspci (if present) real videocard and inform
user about best chooice of flags. But when I build for slow machine new gentoo
system in chroot at my host this driver should not break emerge.
Also it is possible to keep nvidia-legacy-driver ebuilds which can helps user
build specific version of driver. But all nvidia-legacy-driver ebuilds should
be arch-masked by default.

I'd prefer being able to install different drivers in slots, and perhaps even
autodetect the hardware on X startup, but this is probably difficult to
implement in practice. This would allow one system (LiveUSB) to boot on any
Nvidia card.

(In reply to comment #23)
> I'd prefer being able to install different drivers in slots, and perhaps even
> autodetect the hardware on X startup, but this is probably difficult to
> implement in practice. This would allow one system (LiveUSB) to boot on any
> Nvidia card.

And this method reduce loading speed of system.

(In reply to comment #23)
> I'd prefer being able to install different drivers in slots, and perhaps even
> autodetect the hardware on X startup, but this is probably difficult to
> implement in practice. This would allow one system (LiveUSB) to boot on any
> Nvidia card.
> 

While this is possible because Nvidia exports the proper kernel interface. They
do not provide a wrapper as would be necessary for the X.org bits. They also
hardset a lot of paths that they use. If this was a source based driver, it
would be possible however since it's binary based it's not possible.

Doug, my plan was to put the drivers all under nvidia-drivers.  I am not really
concerned with "fixing" upstream's stupidity.  My plan was to get the newer
nvidia-legacy-drivers (7185) into the tree, then to get the newer
nvidia-drivers into the tree, then stabilize the last 96xx series, since it
still has support for all the cards, with the newer drivers staying ~arch. 
Basically, I wasn't going to let any ideas/decisions on the three branches keep
the drivers out of the tree.  Also, I think the lspci idea isn't the best,
since, as stated by others, it breaks if you do builds on another system, like
I do.

and whats the problem in setting different VIDEO_CARDS uses flaags? With the
ati driver it's doing in that form, isn't? there are a r128 and a radeon
useflag.

Chris: I wouldn't error out based on the lspci results. It would be more of a:

ewarn "The video card driver you are compiling is known not to work"
ewarn " with the currently installed video card"
ewarn "If you intend to use this card it is recommended you add the following"
ewarn "mask to /etc/portage/package.mask"
ewarn "mask here"

The ATI stuff builds different drivers.  (Ab)using VIDEO_CARDS for that isn't
the best solution, since it doesn't change the build-time, at all.

i've just committed your ebuild (thanks though) - and works fine for me on
amd64 (w/ my freshly bought FX 8500GT :D)

@x11-drivers team, please verify.

(In reply to comment #10)
> Get the files from:
> 
> /usr/portage/x11-drivers/nvidia-drivers/files/
> /usr/portage/media-video/nvidia-settings/files/icon/
> 
> FILESDIR is *not* a directory that ebuilds put files into. This is a test of
> your knowledge of how ebuilds work ;)
> 

I cannot follow the logic on how ebuilds work, what I do know is that the icon
and menu/desktop settings don't work from the ebuild of nvidia-settings within
nvidia-drivers-100.14.09 here;
        # Install icon and .desktop entry
        doicon "${FILESDIR}/nvidia-settings.png" || die "doicon"
        domenu "${FILESDIR}/nvidia-settings.desktop" || die "domenu"

Would it work if the old nvidia-settings files/icon dir was added to the
nvidia-drivers portage files dir?
If I just did; 
'#cp -p -R /usr/portage/media-video/nvidia-settings/files/icons
/usr/portage/x11-drivers/nvidia-drivers/files/'
would that work as though the files had been put there by emerge --sync?
Or have I got the whole ${FILESDIR} thing wrong? 

You would need to copy the ebuild and supporting files to a local overlay. 
Just cp -r the whole nvidia-drivers directory to your overlay, modify files,
"ebuild full-name-of-ebuild.ebuild digest" and emerge.  If the .desktop file
you have works and the one we're supplying isn't please file a bug (not this
one) about it and attach your working .desktop file so we can fix it in the
tree.

Thanks

(In reply to comment #32)
> You would need to copy the ebuild and supporting files to a local overlay. 
> Just cp -r the whole nvidia-drivers directory to your overlay, modify files,
> "ebuild full-name-of-ebuild.ebuild digest" and emerge.  If the .desktop file
> you have works and the one we're supplying isn't please file a bug (not this
> one) about it and attach your working .desktop file so we can fix it in the
> tree.
> 
> Thanks
> 
Have done so now, bug# 184432.

(In reply to comment #8)
> This ebuild includes all of nvidia-settings also, using the nvidia-settings
> executable from nvidia-drivers.

This bug has been fixed and then un-fixed again, to compile nvidia-settings
from source. What about "the binary one is better tuned to each driver set" at
the top of this bug?

That's what nVidia claims since they only enable features and settings for each
driver. Also, driver releases do happen before new nvidia-settings releases.

However, the issue with the binary shipped file it didn't run properly. So
someone changed it to compile in the drivers. However the opengl change from
x11 to nvidia doesn't happen until after everything is installed so you get
compile failures, so end result is we have to go back to the old way.

I did however add a PDEPEND on the gtk USE flag.