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 attachment 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 attachment 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 attachment 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 ;)
Comment on attachment 118826 [details] nvidia-drivers-100.14.03.ebuild 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 attachment 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 attachment 121515 [details] Graphics card supported with driver 7485
Created attachment 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.
