1 |
On 11/16/05, Richard Fish <bigfish@××××××××××.org> wrote: |
2 |
> |
3 |
> On 11/16/05, Derek Tracy <tracyde@×××××.com> wrote: |
4 |
> > When a branch is marked stable all of the packages in that branch should |
5 |
> > work, |
6 |
> |
7 |
> I'm not sure this is always possible. Much of your complaint comes |
8 |
> from the ipw2200 driver, which is new in 2.6.14. But the in-kernel |
9 |
> version is several versions older than the external driver. So should |
10 |
> 2.6.14 remain marked as unstable because of this one driver that works |
11 |
> for some people, but not for others? Or because a specific externally |
12 |
> maintained driver or package doesn't build against it? |
13 |
> |
14 |
> On my system, either the in-kernel or external drivers work fine. The |
15 |
> only caveat is that I need firmware version 2.2 with the in-kernel |
16 |
> drivers, and a different version for the external. If I am using the |
17 |
> external version, the portage dependancy tree makes sure I have the |
18 |
> right version of the firmware. But the kernel sources do not (and |
19 |
> should not) depend upon the ipw2200-firmware package, so this is a |
20 |
> case where I need to know the driver requirements. (Also, the kernel |
21 |
> help specifies that the driver requires external firmware, although it |
22 |
> doesn't specify what version.) |
23 |
|
24 |
|
25 |
What I am complaining about is that neither of the drivers will work. |
26 |
|
27 |
Regarding the X.org <http://X.org> issue, without an Xorg.0.log file, it is |
28 |
> really |
29 |
> impossible to say what the problem there is. It could be something as |
30 |
> simple as your kernel configuration; for example leaving out I2C or |
31 |
> AGP support could cause this. |
32 |
> |
33 |
> But in my view, you cannot take an existing xorg.conf file and expect |
34 |
> it to work without any issues _without_ duplicating the same system |
35 |
> configuration (kernel version, kernel config, and nvidia driver |
36 |
> version). The fastest method of configuring X on a new system is to |
37 |
> run "X -configure", test the resulting configuration, and use that |
38 |
> xorg.conf file. Yes, this would use the opensource x.org <http://x.org> Nv |
39 |
> driver, |
40 |
> but it should definitely work for getting X up and running. If this |
41 |
> doesn't work, then you have reason to complain. |
42 |
|
43 |
|
44 |
I have tried both ways. My reasoning for taking my old config was originally |
45 |
for the Modeline info. The only reason that I arbitrarily threw it into the |
46 |
newly built system was because the X -configure did not work (even after I |
47 |
switched the dev/mouse to /dev/input/mice) I get the same error with both of |
48 |
the configs. |
49 |
|
50 |
If the proprietary nvidia driver doesn't work with a particular kernel |
51 |
> version, you can only complain to nvidia. |
52 |
|
53 |
|
54 |
I have had that happen in the past and would not ever think about blaming |
55 |
the Gentoo Developers for NVidias work. |
56 |
|
57 |
I'm quite sure a binary-based distribution would have worked better |
58 |
> for you in this case, only because nothing would have been upgraded or |
59 |
> changed. Everything that worked before would have continued to work, |
60 |
> just like everything that was broken before would have continued to be |
61 |
> broken. It is the price of progress, IMO. |
62 |
> |
63 |
> -Richard |
64 |
> |
65 |
> -- |
66 |
> gentoo-user@g.o mailing list |
67 |
> |
68 |
> |
69 |
|
70 |
|
71 |
-- |
72 |
--------------------------------- |
73 |
Derek Tracy |
74 |
tracyde@×××××.com |
75 |
--------------------------------- |