| Summary: | nvidia-drivers-1.0.97xx doesn't support GPUs older than NV3x | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Georgi Chulkov <g.chulkov> |
| Component: | New packages | Assignee: | X11 External Driver Maintainers <x11-drivers> |
| Status: | VERIFIED UPSTREAM | ||
| Severity: | enhancement | CC: | betelgeuse, bugs, caster, djfarid, gnuorder, henning, jakub, m.debruijne, mihalw, pkdevel, zbox |
| Priority: | High | ||
| Version: | 2006.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
nvidia-guide.xml.diff
Fixed error (NV3x shuold be NV2x) |
||
|
Description
Georgi Chulkov
2006-11-11 07:26:47 UTC
How about that we forget all this legacy branches nonsense and let users figure out which drivers version they need? :P Because in the future some NV2x user will just try nvidia-drivers, get an error message, and go back to nvidia-legacy-drivers, which will still be 7xxx at the time. That user will have no idea that one could use 96xx and still get all the good stuff that comes with that branch. And that's a lot of good stuff. (In reply to comment #1) > How about that we forget all this legacy branches nonsense and let users figure > out which drivers version they need? :P > Another way to solve this without new packages would be to make the nvidia VIDEO_CARDS value more specific. Then xorg-server would depend on the right version. *** This bug has been marked as a duplicate of 154739 *** *** Bug 159308 has been marked as a duplicate of this bug. *** *** Bug 159372 has been marked as a duplicate of this bug. *** (In reply to comment #4) > *** This bug has been marked as a duplicate of 154739 *** This bug is not about broken opengl but about dropped support for older cards in 1.0.97* *** Bug 159939 has been marked as a duplicate of this bug. *** Well have to add to this that I too got hit by this at work. NV28GL (Quadro4 980 XGL card). So following what the driver said I ran the legacy drivers and it ended up locking my system hard. So this becomes much more than just an opengl/extras issue. Would it be possible to do some kind of hardware check (such as lspci |grep NV2) and notify the users if they have one of those cards to install 9631? Or later on if a new-legacy branch is created. Hard locks are a bit more of a problem than just an enhancement, IMHO. *** Bug 161662 has been marked as a duplicate of this bug. *** Maybe a meta package could solve this problem. Its deps could depend on special USE-flags link "nvidia(1|2|3)". Everytime a new legagy branch is introduced you have a version bump with a new flag to set and an einfo to the supported GPUs from the README. (http://us.download.nvidia.com/XFree86/Linux-x86/1.0-9746/README/appendix-a.html) That way noone can accidentally switch to a new branch even when he/she has set ~keyword. And this might end up in a somehow consistent state that does not require rewriting of docs. Honestly, that's an abuse of the USE flag system. A USE flag shouldn't *only* determine a dependency, but should actually change compile or run-time options. In this case, it would be doing neither. Currently, I'm waiting to see what emerges from UPSTREAM, but most likely, I'm just going to let the users manage this themselves. After all, they already have the tools required (package.mask) to fix this on their own. Sure, it will require some changes to the documentation, but that's not really that big of a deal. I think Petteri Räty has the right idea! The wame way we have "nv" and "nvidia" now for VIDEO_CARDS, we could have "nv", "nvidia-legacy", "nvidia-middle", and "nvidia-current" (or just "nvidia" for the last one). The only difficult part I see is coming up with a good name for "nvidia-middle". I dont really know much about when to use USE-Flags. But i do believe that this a a bug that should be fixed. The update simply works well without any portage error. After a reboot you will see the problem which your distribution simply ignored. Ok you have pacakge.mask and may downgrade with "emerge =" but this are tools many users don't use very often. They might want to use google or the forums to solve the problem, but they don't even know about lynx/links/w3m.. or don't like them. So they have about an hour work for downgrading and masking, and every experienced user has about 15min of work. And all of them will ask themselfs "why the f did that happen?" since the update went well. Maybe the ebuild could parse the output of lspci or content of /proc or /sys to determine the GPU. I dont know if thats possible since it requires root privileges.. Leaving it up to the users would be a really bad idea. I guess many people will have or already have had this problem. (In reply to comment #14) > Maybe the ebuild could parse the output of lspci or content of /proc or /sys to > determine the GPU. I dont know if thats possible since it requires root > privileges. Nope. There's no standards for lspci output. Unless we used the exact PCI ID, which means we would have to maintain a database of *every* single supported PCI ID for a given driver set. While I understand the frustration people will have, I am not going to waste my time on supporting some crazy scheme to have the system know which driver to use. Quite simply, the user should know what hardware they have and act accordingly. I mean, genkernel doesn't check your hardware to see if you've made a mistake when compiling your kernel... portage doesn't check to see fi you have an ATI card when you "emerge ati-drivers"... we expect the user to have *some* ability to maintain their own system. After all, upstream expects the users to be savvy enough to pick the right driver. I'm simply following their lead. If you have a problem with this, you have two choices: Complain to the vendor Speak with your wallet and don't buy NVIDIA I could care less which option you choose, but trying to come up with some half-assed hack of a solution to work around user laziness isn't part of my plans. If someone else wants to step up and do all the work necessary, as well as continuing to maintain the drivers from now on, then so be it. I have tons of other places my time can be better spent, especially if we document everything. Created attachment 109442 [details, diff]
nvidia-guide.xml.diff
Here's a patch to the NVIDIA Guide for the newer information.
...and here it is online in parsed format: http://dev.gentoo.org/~wolf31o2/nvidia-guide.xml Created attachment 109449 [details, diff]
Fixed error (NV3x shuold be NV2x)
There is an error where it says that NV3x has been dropped; that should be NV2x. NV2x is the GeForce 4 line of cards (except the MX which is NV1x), while NV3x is the GeForce FX line. I've posted a new attachment.
I agree with your argument that users should know what their doing, and I agree USE flags are not a good option. With all due respect for your efforts and time, I disagree that portage should ignore such a problem. This is the kind of poish and attention to detail that makes Gentoo stands out. I think a VIDEO_CARDS approach is optimal, and not difficult to maintain. If I knew how to implement this, I would have done so by now.
So, before I spend any time on this, if I read the documentation and submit a solution with the VIDEO_CARDS approach described above, would it be accepted?
No, it would not. Using VIDEO_CARDS is functionally equivalent to using USE. It doesn't *fix* anything. What would we do, require a user to specify a certain VIDEO_CARDS output? We would *have* to break compatibility with what is currently there, or we're right back to this bug. The simple truth is that there isn't a good solution. Everything else is a complete hack, and not something I would be a part of maintaining. Using USE or VIDEO_CARDS does not solve the problem, which is determining which hardware is supported and whether the package will work. Also, this line of thinking has completely avoided what happens if someone is compiling for another machine. We cannot use a solution that reduces this flexibility. Quite simply, it is up to the user to not screw up their system. As for portage "ignoring" a problem, it isn't. As I said, you're more than welcome to mask the newer versions. Just like if you only had a license for VMware Workstation 4.x where you would be responsible for masking >= 5.0, you are responsible for masking the driver. I've said it once, and I'll say it again just to make sure the point is not missed. If you have a problem with this, complain to NVIDIA. They are the ones that are creating this entire mess. You are their customer. Let them know what you think. I've submitted a bug (bug #165844) to have the documentation updated. If anyone wants to follow the progress of that, it's there. I'm marking this one as UPSTREAM since it is a problem in a package we don't have the source for, so we cannot fix. (In reply to comment #19) > (...) > I've submitted a bug (bug #165844) to have the documentation updated. If > anyone wants to follow the progress of that, it's there. I'm marking this one > as UPSTREAM since it is a problem in a package we don't have the source for, so > we cannot fix. > The problem has nothing to do with having access to source or not. It is only a question how to organize something within gentoo. If using package.mask is a solution, then it should be used for legacy version of the driver. Then, nvidia-legacy-driver is a bad idea or package.mask. In my opinion there should be three independent packages nvidia-drivers - for 97xx and what follows, nvidia-legacy-1 - currently nvidia-legacy-drivers nvidia-legacy-2 - 96xx series Marking this as resolved seems like ignoring the problem. I respect all the maintainers work fixing and making gentoo to what it is. But ignoring a problem like this, and just saying that it is up to the user, is not good spirit in my opinion. I think that it is due to these kind of things that Linux will never be suitable for the general public. What is the problem with creating a third nvidia package? Would you re-read Comment #19 couple of times before adding yet another rants? We have better things to do than shuffling the packages between legacy/more-legacy/very-legacy just because nVidia likes to drop support for older cards in new drivers versions. Do the legwork yourself and p.mask as needed and/or complain to nVidia, not our fault. I realize the issue is closed and the problem is not the fault of gentoo developers but you are still leaving users in the lurch. If I am correct, one of the 9xxx drivers should work for my card, GeForce4 MX 4000, just not the current in mask. I've tried all the 9xxx drivers I found, 9746 and 9631 and neither worked. I am about to try 8776 now which seems like a step backwards but is the last one available that I know of. It would be nice to know where I should set the p mask to get the 9xxx driver I need because one of them should work. Also the current situation has people in #gentoo getting testy with people like me because as far as they know, It the current driver doesn't support my card, the legacy driver should and they get mad when I tell them it doesn't. Can we at least get some sort of guide that lists clearly which versions of the driver are available and which one is considered the cut off point? http://www.gentoo.org/doc/en/nvidia-guide.xml It's all there. If your card isn't supported and it is supposed to be, contact NVIDIA. Now, please, quit commenting here. This is *not* a discussion forum. As i tried to point out in: http://bugs.gentoo.org/show_bug.cgi?id=174030 There is a new legacy driver out since some time: http://www.nvnews.net/vbulletin/showthread.php?t=81668 (no it's not reflected on the home page) And since the first request to get this newer legacy driver in was denied i added: http://bugs.gentoo.org/show_bug.cgi?id=174219 Since i found it stupid to reject the first one. From what i have read here, ppl have had problems with this *WHILE* this driver existed, check the post date. (In reply to comment #25) > As i tried to point out in: <snip> As I tried to point out, the damned driver is already there. And this whole bug is about what's legacy and what's not. Kindly don't comment before you've done your reading as suggested on the other bug. Jakub: Sorry, if you had mentioned that 96xx didn't support TNT or GeForce 1 then it would have been clear... From what i found here it supported all hardware mentioned and i saw nothing about it... (Well, i only skimmed trough the whole webpage thing, that might be it.) |
