xorg-server upgrading problem

[Roy Wright-2]

Howdy,

I have a home server/htpc (~x86) that I'm finally updating after a few  
months and I hit an issue with xorg-server.  Here's the background:

Was at xorg-server-1.6.3 and current sync tried to upgrade to 1.7.1,  
which failed to compile.  In researching on b.g.o., discovered that  
nvidia has not released a driver yet that will work with 1.7.1, so  
followed the bug report directions and masked out several packages to  
prevent 1.7.1 upgrading.

So next attempt at upgrading was to 1.6.5.  That failed too, so back  
to b.g.o. where the first directions were to install nvidia-
drivers-190.42.  But nvidia-drivers has a dependency to xorg-
server-1.6.5, so had to mask >1.6.3 to get nvidia to emerge.  Then hit  
the bug with nvidia-settings with the work around of symbolically  
linking /usr/include/X11/extensions/xf86vmproto.h to /usr/include/X11/
extensions/xf86vmode.h.  Finally removed the >xorg-server-1.6.3 mask  
and successfully emerged.

So now it looks like I have xorg-server-1.6.5 and nvidia-
drivers-190.42 installed.

But when starting the xorg server, it is unable to load glx, dri, and  
dri2 modules:

xbmc log # grep EE Xorg.0.log
Current Operating System: Linux xbmc 2.6.29-gentoo-r2 #7 SMP PREEMPT  
Sun Jun 21 10:15:29 CDT 2009 i686
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(EE) Failed to load module "glx" (module does not exist, 0)
(II) Loading extension MIT-SCREEN-SAVER
(EE) Failed to load module "dri" (module does not exist, 0)
(EE) Failed to load module "dri2" (module does not exist, 0)
(EE) Nov 08 13:48:35 NVIDIA(0): Failed to initialize the GLX module;  
please check in your X
(EE) Nov 08 13:48:35 NVIDIA(0):     log file that the GLX module has  
been loaded in your X
(EE) Nov 08 13:48:35 NVIDIA(0):     server, and that the module is the  
NVIDIA GLX module.  If
(EE) Nov 08 13:48:35 NVIDIA(0):     you continue to encounter  
problems, Please try
(EE) Nov 08 13:48:35 NVIDIA(0):     reinstalling the NVIDIA driver.
(EE) Microsoft Natural Keyboard Pro: failed to initialize for relative  
axes.
(EE) Gyration Gyration RF Technology Receiver: failed to initialize  
for relative axes.

I've even rebooted and still see the same problem.

I'm not having any luck finding a hint on b.g.o. or with searching (I  
use startpage instead of google).

Here's my xorg.conf which works with xorg-server-1.6.3 (it's a little  
explicit because it is connected (DVI) to an A/V receiver (Yamaha RX-
V861) which doesn't pass thru EDID):

Section "ServerLayout"
        Identifier     "X.org Configured"
        Screen      0  "Screen0" 0 0
EndSection

Section "Files"
        ModulePath   "/usr/lib/xorg/modules"
        FontPath     "built-ins"
EndSection

Section "Module"
        Load  "glx"
        Load  "dbe"
        Load  "extmod"
EndSection

Section "Monitor"
        # Block type: 2:0 3:fc
        Identifier "FPD TV"
        VendorName "HTC"
        ModelName "FPD TV"
        # Block type: 2:0 3:fc
        # Block type: 2:0 3:fd
        HorizSync 15-70
        VertRefresh 59-61
        # Max dot clock (video bandwidth) 150 MHz
        # DPMS capabilities: Active off:no  Suspend:no  Standby:no

        Mode    "1920x1080"     # vfreq 60.000Hz, hfreq 67.500kHz
                 DotClock        148.500000
                 HTimings        1920 2008 2052 2200
                 VTimings        1080 1084 1089 1125
                 Flags   "+HSync" "+VSync"
        EndMode
        Mode    "1920x540"      # vfreq 60.053Hz, hfreq 33.750kHz
                 DotClock        74.250000
                 HTimings        1920 2008 2052 2200
                 VTimings        540 542 547 562
                 Flags   "Interlace" "+HSync" "+VSync"
        EndMode
EndSection

Section "Device"
        Identifier  "Card0"
        Driver      "nvidia"
        VendorName  "nVidia Corporation"
        Option      "RenderAccel" "true"
        Option "ModeValidation" "NoDFPNativeResolutionCheck,  
NoMaxSizeCheck"
        Option "NoLogo" "true"
        Option "ConnectedMonitor" "DFP"
        Option  "TVStandard"    "HD1080p"
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "FPD TV"
       
        # depth of 16 breaks xbmc
        DefaultDepth    24

        Option "renderAccel" "true"
        Option "ExactModeTimingsDVI" "true"
        Option "NoLogo" "true"
        Option "DynamicTwinView" "false"
        Option "UseEvents" "true"
        Option "AllowGLXWithComposite" "true"
        Option "AddARGBGLXVisuals" "true"
        Option "FlatPanelProperties" "Scaling = Native"

        SubSection "Display"
                Depth 24
                Modes "1920x1080" "1080p" "1080i" "720p" "720i" "480p"  
"480i" "1024x768" "800x600" "640x480"
                Virtual 1920 1080
        EndSubSection
EndSection


Any ideas?

TIA,
Roy

[Nikos Chantziaras]

On 11/09/2009 02:46 AM, Roy Wright wrote:

> Howdy,
>
> I have a home server/htpc (~x86) that I'm finally updating after a few
> months and I hit an issue with xorg-server. Here's the background:
>
> Was at xorg-server-1.6.3 and current sync tried to upgrade to 1.7.1,
> which failed to compile. In researching on b.g.o., discovered that
> nvidia has not released a driver yet that will work with 1.7.1, so
> followed the bug report directions and masked out several packages to
> prevent 1.7.1 upgrading.

I think the bug about ati-drivers should help:

   http://bugs.gentoo.org/show_bug.cgi?id=290739

 From that bug, follow those two comments *exactly*:

   http://bugs.gentoo.org/show_bug.cgi?id=290739#c3
   http://bugs.gentoo.org/show_bug.cgi?id=290739#c6

This should get you to a correctly installed 1.6.5 again.

[Neil Bothwick]

On Sun, 8 Nov 2009 18:46:15 -0600, Roy Wright wrote:

> Was at xorg-server-1.6.3 and current sync tried to upgrade to 1.7.1,  
> which failed to compile.  In researching on b.g.o., discovered that  
> nvidia has not released a driver yet that will work with 1.7.1, so  
> followed the bug report directions and masked out several packages to  
> prevent 1.7.1 upgrading.

I have had xorg-server-1.7.1 and nvidia-drivers-190.42-r[23], working
together since Nov 3rd, with no masking or keywording, although this is
on ~amd64. For a while the newer xorg was blocked but as soon as the
newer nvidia-drivers hit portage, everything upgraded without a hitch.


--
Neil Bothwick

Reality is an obstacle to hallucination.

[William Kenworthy-2]

On Mon, 2009-11-09 at 01:13 +0000, Neil Bothwick wrote:

> On Sun, 8 Nov 2009 18:46:15 -0600, Roy Wright wrote:
>
> > Was at xorg-server-1.6.3 and current sync tried to upgrade to 1.7.1,  
> > which failed to compile.  In researching on b.g.o., discovered that  
> > nvidia has not released a driver yet that will work with 1.7.1, so  
> > followed the bug report directions and masked out several packages to  
> > prevent 1.7.1 upgrading.
>
> I have had xorg-server-1.7.1 and nvidia-drivers-190.42-r[23], working
> together since Nov 3rd, with no masking or keywording, although this is
> on ~amd64. For a while the newer xorg was blocked but as soon as the
> newer nvidia-drivers hit portage, everything upgraded without a hitch.
>

I am just in the process of updating a machine stored for over a year -
relatively straight forward except its taking awhile as expected.  It
has an old TNT nvidia card that needs the older drivers (169 something
with 2.6.21 is working on it at the moment - I upgraded to 2.6.31 and
belatedly remembered this Achilles heal for nvidia stuff :)

Are the older nvidia drivers locked to older kernels?  If so, is there a
map that tells what driver version is usable with which kernels?

BillK

[Johannes Kimmel]

Roy Wright wrote:

> Howdy,
>
> I have a home server/htpc (~x86) that I'm finally updating after a few
> months and I hit an issue with xorg-server.  Here's the background:
>
> Was at xorg-server-1.6.3 and current sync tried to upgrade to 1.7.1,
> which failed to compile.  In researching on b.g.o., discovered that
> nvidia has not released a driver yet that will work with 1.7.1, so
> followed the bug report directions and masked out several packages to
> prevent 1.7.1 upgrading.
>
> So next attempt at upgrading was to 1.6.5.  That failed too, so back
> to b.g.o. where the first directions were to install
> nvidia-drivers-190.42.  But nvidia-drivers has a dependency to
> xorg-server-1.6.5, so had to mask >1.6.3 to get nvidia to emerge.  
> Then hit the bug with nvidia-settings with the work around of
> symbolically linking /usr/include/X11/extensions/xf86vmproto.h to
> /usr/include/X11/extensions/xf86vmode.h.  Finally removed the
> >xorg-server-1.6.3 mask and successfully emerged.
>
> So now it looks like I have xorg-server-1.6.5 and
> nvidia-drivers-190.42 installed.
>
> But when starting the xorg server, it is unable to load glx, dri, and
> dri2 modules:
>
> xbmc log # grep EE Xorg.0.log
> Current Operating System: Linux xbmc 2.6.29-gentoo-r2 #7 SMP PREEMPT
> Sun Jun 21 10:15:29 CDT 2009 i686
>     (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> (EE) Failed to load module "glx" (module does not exist, 0)
> (II) Loading extension MIT-SCREEN-SAVER
> (EE) Failed to load module "dri" (module does not exist, 0)
> (EE) Failed to load module "dri2" (module does not exist, 0)
> (EE) Nov 08 13:48:35 NVIDIA(0): Failed to initialize the GLX module;
> please check in your X
> (EE) Nov 08 13:48:35 NVIDIA(0):     log file that the GLX module has
> been loaded in your X
> (EE) Nov 08 13:48:35 NVIDIA(0):     server, and that the module is the
> NVIDIA GLX module.  If
> (EE) Nov 08 13:48:35 NVIDIA(0):     you continue to encounter
> problems, Please try
> (EE) Nov 08 13:48:35 NVIDIA(0):     reinstalling the NVIDIA driver.
> (EE) Microsoft Natural Keyboard Pro: failed to initialize for relative
> axes.
> (EE) Gyration Gyration RF Technology Receiver: failed to initialize
> for relative axes.
>
> I've even rebooted and still see the same problem.
>
> I'm not having any luck finding a hint on b.g.o. or with searching (I
> use startpage instead of google).
>
> Here's my xorg.conf which works with xorg-server-1.6.3 (it's a little
> explicit because it is connected (DVI) to an A/V receiver (Yamaha
> RX-V861) which doesn't pass thru EDID):
>
> Section "ServerLayout"
>     Identifier     "X.org Configured"
>     Screen      0  "Screen0" 0 0
> EndSection
>
> Section "Files"
>     ModulePath   "/usr/lib/xorg/modules"
>     FontPath     "built-ins"
> EndSection
>
> Section "Module"
>     Load  "glx"
>     Load  "dbe"
>     Load  "extmod"
> EndSection
>
> Section "Monitor"
>        # Block type: 2:0 3:fc
>        Identifier "FPD TV"
>        VendorName "HTC"
>        ModelName "FPD TV"
>        # Block type: 2:0 3:fc
>        # Block type: 2:0 3:fd
>        HorizSync 15-70
>        VertRefresh 59-61
>        # Max dot clock (video bandwidth) 150 MHz
>        # DPMS capabilities: Active off:no  Suspend:no  Standby:no
>
>        Mode    "1920x1080"     # vfreq 60.000Hz, hfreq 67.500kHz
>                 DotClock        148.500000
>                 HTimings        1920 2008 2052 2200
>                 VTimings        1080 1084 1089 1125
>                 Flags   "+HSync" "+VSync"
>        EndMode
>        Mode    "1920x540"      # vfreq 60.053Hz, hfreq 33.750kHz
>                 DotClock        74.250000
>                 HTimings        1920 2008 2052 2200
>                 VTimings        540 542 547 562
>                 Flags   "Interlace" "+HSync" "+VSync"
>        EndMode
> EndSection
>
> Section "Device"
>     Identifier  "Card0"
>     Driver      "nvidia"
>     VendorName  "nVidia Corporation"
>     Option      "RenderAccel" "true"
>        Option "ModeValidation" "NoDFPNativeResolutionCheck,
> NoMaxSizeCheck"
>        Option "NoLogo" "true"
>        Option "ConnectedMonitor" "DFP"
>        Option  "TVStandard"    "HD1080p"
> EndSection
>
> Section "Screen"
>     Identifier "Screen0"
>     Device     "Card0"
>     Monitor    "FPD TV"
>    
>     # depth of 16 breaks xbmc
>        DefaultDepth    24
>
>        Option "renderAccel" "true"
>        Option "ExactModeTimingsDVI" "true"
>        Option "NoLogo" "true"
>        Option "DynamicTwinView" "false"
>        Option "UseEvents" "true"
>        Option "AllowGLXWithComposite" "true"
>        Option "AddARGBGLXVisuals" "true"
>        Option "FlatPanelProperties" "Scaling = Native"
>
>     SubSection "Display"
>                Depth    24
>                Modes "1920x1080" "1080p" "1080i" "720p" "720i" "480p"
> "480i" "1024x768" "800x600" "640x480"
>             Virtual 1920 1080
>     EndSubSection
> EndSection
>
>
> Any ideas?
>
> TIA,
> Roy
>
>

Try to resync and emerge the new eselect-opengl and run "eselect opengl
set nvidia" again. This could fix it, as I had a similar problem. The
old eselect did something wrong, but I can't remember exactly because it
went somehow long yesterday :)


Johannes

[Dale-46]

Bill Kenworthy wrote:

> On Mon, 2009-11-09 at 01:13 +0000, Neil Bothwick wrote:
>  
>> On Sun, 8 Nov 2009 18:46:15 -0600, Roy Wright wrote:
>>
>>    
>>> Was at xorg-server-1.6.3 and current sync tried to upgrade to 1.7.1,  
>>> which failed to compile.  In researching on b.g.o., discovered that  
>>> nvidia has not released a driver yet that will work with 1.7.1, so  
>>> followed the bug report directions and masked out several packages to  
>>> prevent 1.7.1 upgrading.
>>>      
>> I have had xorg-server-1.7.1 and nvidia-drivers-190.42-r[23], working
>> together since Nov 3rd, with no masking or keywording, although this is
>> on ~amd64. For a while the newer xorg was blocked but as soon as the
>> newer nvidia-drivers hit portage, everything upgraded without a hitch.
>>
>>    
> I am just in the process of updating a machine stored for over a year -
> relatively straight forward except its taking awhile as expected.  It
> has an old TNT nvidia card that needs the older drivers (169 something
> with 2.6.21 is working on it at the moment - I upgraded to 2.6.31 and
> belatedly remembered this Achilles heal for nvidia stuff :)
>
> Are the older nvidia drivers locked to older kernels?  If so, is there a
> map that tells what driver version is usable with which kernels?
>
> BillK
>
>  

I have a older card to, FX-5200, and sometimes finding the driver that
works is a trial and error process.  Right now I'm using 173.14.20 but a
couple months ago I was using a older kernel and had to use a older
version that was no longer in portage, still in the 173 series tho.  If
you have the latest stable kernel, then the latest stable nvidia driver
in your series should work.  If not, back up a version and try it.  If
it doesn't work just keep backing up until one works.

You may be able to search the nvidia website to fine the correct drivers
for your model but I don't know if they have one for kernel version.
Just think of it this way, the older the kernel then the older the
driver version.  The newer the kernel, the newer the driver should be.

All that said, I think this is yours:

http://www.nvidia.com/object/linux_display_ia32_71.86.11.html

If not, try this:

http://www.nvidia.com/Download/index.aspx?lang=en-us

Like me, you have to select legacy in the first menu.

I would try nvidia-drivers-71.86.11 first and if that doesn't work, try
nvidia-drivers-71.86.09 next. Once you get a working driver, mask the
others so it will stick to it until you upgrade your kernel and start
this process over again.

Hope that helps.

Dale

:-)  :-)

[William Kenworthy-2]

On Mon, 2009-11-09 at 03:06 -0600, Dale wrote:

> Bill Kenworthy wrote:
> > On Mon, 2009-11-09 at 01:13 +0000, Neil Bothwick wrote:
> >  
> >> On Sun, 8 Nov 2009 18:46:15 -0600, Roy Wright wrote:
> >>
> >>    
> >>> Was at xorg-server-1.6.3 and current sync tried to upgrade to 1.7.1,  
> >>> which failed to compile.  In researching on b.g.o., discovered that  
> >>> nvidia has not released a driver yet that will work with 1.7.1, so  
> >>> followed the bug report directions and masked out several packages to  
> >>> prevent 1.7.1 upgrading.
> >>>      
> >> I have had xorg-server-1.7.1 and nvidia-drivers-190.42-r[23], working
> >> together since Nov 3rd, with no masking or keywording, although this is
> >> on ~amd64. For a while the newer xorg was blocked but as soon as the
> >> newer nvidia-drivers hit portage, everything upgraded without a hitch.
> >>
> >>    
> > I am just in the process of updating a machine stored for over a year -
> > relatively straight forward except its taking awhile as expected.  It
> > has an old TNT nvidia card that needs the older drivers (169 something
> > with 2.6.21 is working on it at the moment - I upgraded to 2.6.31 and
> > belatedly remembered this Achilles heal for nvidia stuff :)
> >
> > Are the older nvidia drivers locked to older kernels?  If so, is there a
> > map that tells what driver version is usable with which kernels?
> >
> > BillK
> >
> >  
>
> I have a older card to, FX-5200, and sometimes finding the driver that
> works is a trial and error process.  Right now I'm using 173.14.20 but a
> couple months ago I was using a older kernel and had to use a older
> version that was no longer in portage, still in the 173 series tho.  If
> you have the latest stable kernel, then the latest stable nvidia driver
> in your series should work.  If not, back up a version and try it.  If
> it doesn't work just keep backing up until one works.
>
> You may be able to search the nvidia website to fine the correct drivers
> for your model but I don't know if they have one for kernel version.
> Just think of it this way, the older the kernel then the older the
> driver version.  The newer the kernel, the newer the driver should be.
>
> All that said, I think this is yours:
>
> http://www.nvidia.com/object/linux_display_ia32_71.86.11.html
>
> If not, try this:
>
> http://www.nvidia.com/Download/index.aspx?lang=en-us
>
> Like me, you have to select legacy in the first menu.
>
> I would try nvidia-drivers-71.86.11 first and if that doesn't work, try
> nvidia-drivers-71.86.09 next. Once you get a working driver, mask the
> others so it will stick to it until you upgrade your kernel and start
> this process over again.
>
> Hope that helps.
>
> Dale
>
> :-)  :-)
>

Decided to sidestep the issue - the nv driver works fine (no multimedia
etc needed).  This was to be a temporary desktop while waiting for parts
for a dead HD in the laptop, but I found it (much) faster to add x, oo
etc to a core2 duo server instead of trying to bring the old machine up
to date.  Will still complete it as you cant have too many backup
systems ... as my luck of late has proved :(

BillK

[Dale-46]

William Kenworthy wrote:

> On Mon, 2009-11-09 at 03:06 -0600, Dale wrote:
>  
>> Bill Kenworthy wrote:
>>    
>>> On Mon, 2009-11-09 at 01:13 +0000, Neil Bothwick wrote:
>>>  
>>>      
>>>> On Sun, 8 Nov 2009 18:46:15 -0600, Roy Wright wrote:
>>>>
>>>>    
>>>>        
>>>>> Was at xorg-server-1.6.3 and current sync tried to upgrade to 1.7.1,  
>>>>> which failed to compile.  In researching on b.g.o., discovered that  
>>>>> nvidia has not released a driver yet that will work with 1.7.1, so  
>>>>> followed the bug report directions and masked out several packages to  
>>>>> prevent 1.7.1 upgrading.
>>>>>      
>>>>>          
>>>> I have had xorg-server-1.7.1 and nvidia-drivers-190.42-r[23], working
>>>> together since Nov 3rd, with no masking or keywording, although this is
>>>> on ~amd64. For a while the newer xorg was blocked but as soon as the
>>>> newer nvidia-drivers hit portage, everything upgraded without a hitch.
>>>>
>>>>    
>>>>        
>>> I am just in the process of updating a machine stored for over a year -
>>> relatively straight forward except its taking awhile as expected.  It
>>> has an old TNT nvidia card that needs the older drivers (169 something
>>> with 2.6.21 is working on it at the moment - I upgraded to 2.6.31 and
>>> belatedly remembered this Achilles heal for nvidia stuff :)
>>>
>>> Are the older nvidia drivers locked to older kernels?  If so, is there a
>>> map that tells what driver version is usable with which kernels?
>>>
>>> BillK
>>>
>>>  
>>>      
>> I have a older card to, FX-5200, and sometimes finding the driver that
>> works is a trial and error process.  Right now I'm using 173.14.20 but a
>> couple months ago I was using a older kernel and had to use a older
>> version that was no longer in portage, still in the 173 series tho.  If
>> you have the latest stable kernel, then the latest stable nvidia driver
>> in your series should work.  If not, back up a version and try it.  If
>> it doesn't work just keep backing up until one works.
>>
>> You may be able to search the nvidia website to fine the correct drivers
>> for your model but I don't know if they have one for kernel version.
>> Just think of it this way, the older the kernel then the older the
>> driver version.  The newer the kernel, the newer the driver should be.
>>
>> All that said, I think this is yours:
>>
>> http://www.nvidia.com/object/linux_display_ia32_71.86.11.html
>>
>> If not, try this:
>>
>> http://www.nvidia.com/Download/index.aspx?lang=en-us
>>
>> Like me, you have to select legacy in the first menu.
>>
>> I would try nvidia-drivers-71.86.11 first and if that doesn't work, try
>> nvidia-drivers-71.86.09 next. Once you get a working driver, mask the
>> others so it will stick to it until you upgrade your kernel and start
>> this process over again.
>>
>> Hope that helps.
>>
>> Dale
>>
>> :-)  :-)
>>
>>    
>
> Decided to sidestep the issue - the nv driver works fine (no multimedia
> etc needed).  This was to be a temporary desktop while waiting for parts
> for a dead HD in the laptop, but I found it (much) faster to add x, oo
> etc to a core2 duo server instead of trying to bring the old machine up
> to date.  Will still complete it as you cant have too many backup
> systems ... as my luck of late has proved :(
>
> BillK
>
>  

Well at least you have links for next time.  lol

Dale

:-)  :-)

[Roy Wright-2]

On Nov 9, 2009, at 1:04 AM, Johannes Kimmel wrote:
> Try to resync and emerge the new eselect-opengl and run "eselect  
> opengl set nvidia" again. This could fix it, as I had a similar  
> problem. The old eselect did something wrong, but I can't remember  
> exactly because it went somehow long yesterday :)

Good catch, but unfortunately it didn't help.  I've downgraded the  
nvidia drivers to 185.18.36-r1 which then loaded glx, but still not  
dri or dri2.

Maybe I need to upgrade the kernel from 2.6.29...

BTW, xorg-server-1.6.5 does work with nv drivers, but I need opengl.

I'm currently trying to downgrade server to 1.6.3, but that's not  
compiling.  Let's say I'm not very impressed with the xorg ebuild  
technique of specifying dependencies using >=.  xorg ebuilds should be  
holistic based on the xorg-server version.  Instead I have to figure  
out the version masks for each of the dependencies.  PITA!

Thank you,
Roy

[Johannes Kimmel]

Roy Wright wrote:

>
> On Nov 9, 2009, at 1:04 AM, Johannes Kimmel wrote:
>> Try to resync and emerge the new eselect-opengl and run "eselect
>> opengl set nvidia" again. This could fix it, as I had a similar
>> problem. The old eselect did something wrong, but I can't remember
>> exactly because it went somehow long yesterday :)
>
> Good catch, but unfortunately it didn't help.  I've downgraded the
> nvidia drivers to 185.18.36-r1 which then loaded glx, but still not
> dri or dri2.
>
> Maybe I need to upgrade the kernel from 2.6.29...
>
> BTW, xorg-server-1.6.5 does work with nv drivers, but I need opengl.
>
> I'm currently trying to downgrade server to 1.6.3, but that's not
> compiling.  Let's say I'm not very impressed with the xorg ebuild
> technique of specifying dependencies using >=.  xorg ebuilds should be
> holistic based on the xorg-server version.  Instead I have to figure
> out the version masks for each of the dependencies.  PITA!
>
> Thank you,
> Roy
>
>

AFAIK it doesn't matter if dri and dri2 don't load. On the three systems
I maintain the "dris" don't load, too, but I have full opengl acceleration.

[Nikos Chantziaras]

On 11/09/2009 11:18 PM, Roy Wright wrote:

>
> On Nov 9, 2009, at 1:04 AM, Johannes Kimmel wrote:
>> Try to resync and emerge the new eselect-opengl and run "eselect
>> opengl set nvidia" again. This could fix it, as I had a similar
>> problem. The old eselect did something wrong, but I can't remember
>> exactly because it went somehow long yesterday :)
>
> Good catch, but unfortunately it didn't help. I've downgraded the nvidia
> drivers to 185.18.36-r1 which then loaded glx, but still not dri or dri2.
>
> Maybe I need to upgrade the kernel from 2.6.29...
>
> BTW, xorg-server-1.6.5 does work with nv drivers, but I need opengl.
>
> I'm currently trying to downgrade server to 1.6.3, but that's not
> compiling. Let's say I'm not very impressed with the xorg ebuild
> technique of specifying dependencies using >=. xorg ebuilds should be
> holistic based on the xorg-server version. Instead I have to figure out
> the version masks for each of the dependencies. PITA!

I already posted how do downgrade to 1.6.5 correctly :P

[Roy Wright-2]

On Nov 9, 2009, at 3:36 PM, Nikos Chantziaras wrote:

> On 11/09/2009 11:18 PM, Roy Wright wrote:
>>
>> On Nov 9, 2009, at 1:04 AM, Johannes Kimmel wrote:
>>> Try to resync and emerge the new eselect-opengl and run "eselect
>>> opengl set nvidia" again. This could fix it, as I had a similar
>>> problem. The old eselect did something wrong, but I can't remember
>>> exactly because it went somehow long yesterday :)
>>
>> Good catch, but unfortunately it didn't help. I've downgraded the  
>> nvidia
>> drivers to 185.18.36-r1 which then loaded glx, but still not dri or  
>> dri2.
>>
>> Maybe I need to upgrade the kernel from 2.6.29...
>>
>> BTW, xorg-server-1.6.5 does work with nv drivers, but I need opengl.
>>
>> I'm currently trying to downgrade server to 1.6.3, but that's not
>> compiling. Let's say I'm not very impressed with the xorg ebuild
>> technique of specifying dependencies using >=. xorg ebuilds should be
>> holistic based on the xorg-server version. Instead I have to figure  
>> out
>> the version masks for each of the dependencies. PITA!
>
> I already posted how do downgrade to 1.6.5 correctly :P
>
>

Sorry, forgot to mention that I did try those instructions.  Didn't  
help.

I'm currently punting, removing all of X from my system, then will  
start over...

Thank you,
Roy

[Roy Wright-2]

Unmerged all of x11, then installed xorg-server-1.6.5 and it is  
working now.

One of the issues I hit is that python-3.1.1-r1 can not be installed  
with the tk use flag due to cyclic dependencies when installing xorg  
(portage insists on installing python before libX11 so python[tk]  
fails as it is missing Xlib.h).

Thanks everyone!

Roy

[Alan McKinnon-2]

On Tuesday 10 November 2009 11:46:50 Roy Wright wrote:
> Unmerged all of x11, then installed xorg-server-1.6.5 and it is
> working now.
>
> One of the issues I hit is that python-3.1.1-r1 can not be installed
> with the tk use flag due to cyclic dependencies when installing xorg
> (portage insists on installing python before libX11 so python[tk]
> fails as it is missing Xlib.h).

Would this work?

emerge python with USE=-tk
install libX11
install python with USE=tk

--
alan dot mckinnon at gmail dot com

[Roy Wright-2]

On Nov 10, 2009, at 4:21 AM, Alan McKinnon wrote:

> On Tuesday 10 November 2009 11:46:50 Roy Wright wrote:
>> One of the issues I hit is that python-3.1.1-r1 can not be installed
>> with the tk use flag due to cyclic dependencies when installing xorg
>> (portage insists on installing python before libX11 so python[tk]
>> fails as it is missing Xlib.h).
>
> Would this work?
>
> emerge python with USE=-tk
> install libX11
> install python with USE=tk
>

What I did was set python -tk in package.use then finished installing  
xorg-server, then removed the python -tk from package.use and emerge  
updated.  That worked fine so your example should also work fine.

Thank you,
Roy

[covici]

Nikos Chantziaras <realnc@...> wrote:

>
> I already posted how do downgrade to 1.6.5 correctly :P
>

I have a slightly different case, but related -- I tried the upgrade
because I saw a message that the new nvidia drivers would actually work,
but xorg-server 1.7.1 would not compile and so I followed the
instructions in the bug 290739 comments 3 and 6 and xorg-server 1.6.5
and 1.6.4 which is the one I still have -- neither one will compile.  In
the 1.6.5 case I get errors in rensize.c.

Thanks in advance for any ideas on how to fix.

--
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@...