Re: [gentoo-user] Nvidia-drivers fails to patch

[Dale]

Neil Bothwick wrote:
> On Fri, 21 Apr 2023 09:55:24 -0500, Dale wrote:
>
 Also, I switch to the current kernel, it failed in the same way.  It
 isn't just the new kernel, it seems to be any of them.  I wonder how
 hard it is to switch to that other driver.  From the wiki page, it
 looks like a big deal.   
>>> Not really, AFAIR. You just enable nouveau drivers in your kernel
>>> config, uninstall the nvidia package and reboot. This assumes you
>>> haven't got any direct references to the nvisia driver in
>>> /etc/xorg.conf*.
>> I think, pretty much certain, I have it set to nvidia in xorg.conf. 
>> This is a old install.  If I recall correctly, I have to change that. 
>> Also, I'd need to edit make.conf I think.  I read the wiki thingy a few
>> times.  It's mostly undoing things but with the age of this install, I
>> don't think my old way is the new way.  Yep.  I'm getting better at
>> grep.  lol
>>
>> root@fireball / # cat /etc/X11/xorg.conf | grep driver
>>     Driver "mouse"
>>     Driver "kbd"
>>     Driver "nvidia"
> xorg.conf is often unnecessary these days. I only have a file in
> xorg.conf.d to switch the buttons on my trackball.

I thought I read that somewhere.  This is a old install tho.  A decade
or so.  To be honest tho, I'd like to configure my 2nd screen in the
conf file.  As it is, I have it set up within KDE itself I think.  When
I kill the X part, the 2nd screen dies since KDE and friends isn't
running.  I just haven't had the nerve to do it yet.  I can't even be
sure how it is done nowadays.  I think nvidia has a command that does it. 


>> root@fireball / #cat /etc/make.conf | grep video_cards
>> VIDEO_CARDS="nvidia vesa"
>> root@fireball / #
>>
>> I think I'd have to change those.  It may or may not rebuild some
>> packages.  Would I need to leave out vesa or OK to leave it in?
> You'll need to replace nvidia with nouveau here, leave in vesa as a
> fallback.
>
> The worst that can happen is that X fails to start and you need to
> re-emerge the nvidia drivers, which you quickpkg'd of course.
>
>


Back when I was using Mandrake, I actually wrote a step by step guide to
installing the video drivers and did it a way that even a noobie could
follow it.  That was back in the mid 2000's tho.  It was on Linux
Questions I think.  That thing had tons of views and lots of grateful
users.  I thought I had to change that and the one in the xorg.conf file
too.  The big one when rebooting is the xorg file tho.  I just wasn't
sure if something had changed. 

I looked at a Nvidia GTX 1050 video card.  May be good for starting to
accumulate parts for new rig.  Anyway, it has a weird set of outputs.  I
need two HDMI, or three, for mine.  My current monitor will take either
DB15HD or HDMI.  My TV ports are HDMI.  I kinda like everything else
about it except the outputs.  I may have to dig further. 

Dale

:-)  :-)

Re: [gentoo-user] Nvidia-drivers fails to patch

[Neil Bothwick]

On Fri, 21 Apr 2023 09:55:24 -0500, Dale wrote:

> >> Also, I switch to the current kernel, it failed in the same way.  It
> >> isn't just the new kernel, it seems to be any of them.  I wonder how
> >> hard it is to switch to that other driver.  From the wiki page, it
> >> looks like a big deal.   
> > Not really, AFAIR. You just enable nouveau drivers in your kernel
> > config, uninstall the nvidia package and reboot. This assumes you
> > haven't got any direct references to the nvisia driver in
> > /etc/xorg.conf*.

> I think, pretty much certain, I have it set to nvidia in xorg.conf. 
> This is a old install.  If I recall correctly, I have to change that. 
> Also, I'd need to edit make.conf I think.  I read the wiki thingy a few
> times.  It's mostly undoing things but with the age of this install, I
> don't think my old way is the new way.  Yep.  I'm getting better at
> grep.  lol
> 
> root@fireball / # cat /etc/X11/xorg.conf | grep driver
>     Driver "mouse"
>     Driver "kbd"
>     Driver "nvidia"

xorg.conf is often unnecessary these days. I only have a file in
xorg.conf.d to switch the buttons on my trackball.

> root@fireball / #cat /etc/make.conf | grep video_cards
> VIDEO_CARDS="nvidia vesa"
> root@fireball / #
> 
> I think I'd have to change those.  It may or may not rebuild some
> packages.  Would I need to leave out vesa or OK to leave it in?

You'll need to replace nvidia with nouveau here, leave in vesa as a
fallback.

The worst that can happen is that X fails to start and you need to
re-emerge the nvidia drivers, which you quickpkg'd of course.


-- 
Neil Bothwick

This is as bad as it can get; but don't bet on it.


pgp76AGQEPv1X.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Nvidia-drivers fails to patch

[Dale]

Dr Rainer Woitok wrote:
> Dale,
>
> On Thursday, 2023-04-20 17:36:23 -0500, you wrote:
>
>> ...
>> * Package:    x11-drivers/nvidia-drivers-470.182.03:0/470
>>  * Repository: mine
> Maybe I'm  missing something,  but as of today  "x11-drivers/nvidia-dri-
> vers" version 470.182.03 is still in the normal Gentoo tree.  So why use
> your personal repo?  Do you have a local patch applied?
>
> Sincerely,
>   Rainer
> .
>

I ran into a buggy driver a while back and once I synced and upgraded,
the old one was gone.  So, I started keeping a local copy just in case. 
Of course, as long as I keep a older driver to fall back on, it won't
break anymore.  As soon as I miss one tho, problems.  LOL 

Thanks to you and Ionen.

Dale

:-)  :-) 

Re: [gentoo-user] Nvidia-drivers fails to patch

[Dale]

Arve Barsnes wrote:
> On Fri, 21 Apr 2023 at 11:55, Dale  wrote:
>> Did something change with overlays?  In the past, I copied the ebuild
>> over to local overlay and ran the ebuild command for the manifest.  It
>> downloaded everything that was needed.  Now, it seems it doesn't.  They
>> add a step?  I miss a step that slipped my mind?
> I don't think the files/ directory contents were ever downloaded by
> the ebuilds, they are a part of the portage tree, so they appear when
> you sync. Maybe the files/ contents from the main tree were available
> for your overlay ebuild somehow? I've never had that luxury, so now
> I*m wondering how your ebuild ever worked :-)
>
> Regards,
> Arve
>
>

That's right.  I rarely do anything with local overlays so I forgot
about that.  Next time I'll try to remember to copy the whole directory,
without deleting files no longer in the tree tho.  Don't want to remove
one I need.  ;-)

Thanks.

Dale

:-)  :-) 

Re: [gentoo-user] Nvidia-drivers fails to patch

[Dale]

Neil Bothwick wrote:
> On Fri, 21 Apr 2023 03:58:11 -0500, Dale wrote:
>
>> I did a emerge -ef nvidia-drivers and it still fails.  I was hoping that
>> would pick up the needed files.  Guess not.  I decided to do some more
>> digging.  I noticed that the same version is still in the tree.  I
>> copied the ebuild a while back to a local overlay to make sure I don't
>> lose it.  It seems emerge gives my local overlay priority over the one
>> in the tree.  I renamed the ebuild in my overlay with .old tacked on. 
>> It emerges fine after that since it uses the ebuild in the tree.  It
>> seems my overlay is broken somehow.  Likely a design improvement.  ;-) 
> That's the default by design. If you copy an ebuild to your overlay, it's
> usually because you want to make changes to it, so it should be given
> priority. You can change the priority of overlays in
> /etc/portage/repos.conf, or you can simply mask the overlay version.
>
>

Found the needed info on the wiki and added the priority setting.  I
added "priority=100" which should work right?  It will use the Gentoo
tree first and then mine?  That's my reading of the wiki page anyway. 

Thanks.

Dale

:-)  :-) 

Re: [gentoo-user] Nvidia-drivers fails to patch

[Dale]

Neil Bothwick wrote:
> On Thu, 20 Apr 2023 20:33:22 -0500, Dale wrote:
>
>> Also, I switch to the current kernel, it failed in the same way.  It
>> isn't just the new kernel, it seems to be any of them.  I wonder how
>> hard it is to switch to that other driver.  From the wiki page, it looks
>> like a big deal. 
> Not really, AFAIR. You just enable nouveau drivers in your kernel config,
> uninstall the nvidia package and reboot. This assumes you haven't got any
> direct references to the nvisia driver in /etc/xorg.conf*.
>
>


I think, pretty much certain, I have it set to nvidia in xorg.conf. 
This is a old install.  If I recall correctly, I have to change that. 
Also, I'd need to edit make.conf I think.  I read the wiki thingy a few
times.  It's mostly undoing things but with the age of this install, I
don't think my old way is the new way.  Yep.  I'm getting better at
grep.  lol

root@fireball / # cat /etc/X11/xorg.conf | grep driver
    Driver "mouse"
    Driver "kbd"
    Driver "nvidia"
root@fireball / #cat /etc/make.conf | grep video_cards
VIDEO_CARDS="nvidia vesa"
root@fireball / #

I think I'd have to change those.  It may or may not rebuild some
packages.  Would I need to leave out vesa or OK to leave it in?

The easiest part, enable in kernel and build it.  With your nifty dracut
command option, it just works. LOL  By the way, the nvidia-driver
package compiled fine against the new kernel.

I may be into to much today to play with this tho.  Maybe late today. 
Tomorrow depending on weather. 

Next time I copy a ebuild to a local overlay, I need to remember to copy
any files directory over too.  I don't recall ever doing that before. 

Thanks to all.  Gotta do some things so may reply to others later. 

Dale

:-)  :-) 

Re: [gentoo-user] Nvidia-drivers fails to patch

[Neil Bothwick]

On Thu, 20 Apr 2023 20:33:22 -0500, Dale wrote:

> Also, I switch to the current kernel, it failed in the same way.  It
> isn't just the new kernel, it seems to be any of them.  I wonder how
> hard it is to switch to that other driver.  From the wiki page, it looks
> like a big deal. 

Not really, AFAIR. You just enable nouveau drivers in your kernel config,
uninstall the nvidia package and reboot. This assumes you haven't got any
direct references to the nvisia driver in /etc/xorg.conf*.


-- 
Neil Bothwick

New sig wanted good price paid.


pgp7HlTOyzzcT.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Nvidia-drivers fails to patch

[Neil Bothwick]

On Fri, 21 Apr 2023 03:58:11 -0500, Dale wrote:

> I did a emerge -ef nvidia-drivers and it still fails.  I was hoping that
> would pick up the needed files.  Guess not.  I decided to do some more
> digging.  I noticed that the same version is still in the tree.  I
> copied the ebuild a while back to a local overlay to make sure I don't
> lose it.  It seems emerge gives my local overlay priority over the one
> in the tree.  I renamed the ebuild in my overlay with .old tacked on. 
> It emerges fine after that since it uses the ebuild in the tree.  It
> seems my overlay is broken somehow.  Likely a design improvement.  ;-) 

That's the default by design. If you copy an ebuild to your overlay, it's
usually because you want to make changes to it, so it should be given
priority. You can change the priority of overlays in
/etc/portage/repos.conf, or you can simply mask the overlay version.


-- 
Neil Bothwick

Dream as if you'll live forever. Live as if you'll die today.


pgptWnU_q8g1I.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Nvidia-drivers fails to patch

[Ionen Wolkens]

On Thu, Apr 20, 2023 at 05:36:23PM -0500, Dale wrote:
> /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch:
> No such file or directory

This sounds like you copied the ebuild to your local overlay but not
the files/ dir which includes the patch. So the patch is not found.

> this error tho and it work when I reboot, it would be great.  I don't
> think that driver version is in the tree anymore.  It shows it is in my
> local overlay.

It is in the tree, 470.x is a long-term-support branch and as long as
NVIDIA continue to support it there's no reason to drop it from the
tree. Just use the ::gentoo version.

470.182.03 is even fairly recent, was a security release added to the
tree last month followed by the cleanup of the vulnerable 470.161.03.

https://packages.gentoo.org/packages/x11-drivers/nvidia-drivers

-- 
ionen


signature.asc
Description: PGP signature

Re: [gentoo-user] Nvidia-drivers fails to patch

[Dr Rainer Woitok]

Dale,

On Thursday, 2023-04-20 17:36:23 -0500, you wrote:

> ...
> * Package:    x11-drivers/nvidia-drivers-470.182.03:0/470
>  * Repository: mine

Maybe I'm  missing something,  but as of today  "x11-drivers/nvidia-dri-
vers" version 470.182.03 is still in the normal Gentoo tree.  So why use
your personal repo?  Do you have a local patch applied?

Sincerely,
  Rainer

Re: [gentoo-user] Nvidia-drivers fails to patch

[Arve Barsnes]

On Fri, 21 Apr 2023 at 11:55, Dale  wrote:
> Did something change with overlays?  In the past, I copied the ebuild
> over to local overlay and ran the ebuild command for the manifest.  It
> downloaded everything that was needed.  Now, it seems it doesn't.  They
> add a step?  I miss a step that slipped my mind?

I don't think the files/ directory contents were ever downloaded by
the ebuilds, they are a part of the portage tree, so they appear when
you sync. Maybe the files/ contents from the main tree were available
for your overlay ebuild somehow? I've never had that luxury, so now
I*m wondering how your ebuild ever worked :-)

Regards,
Arve

Re: [gentoo-user] Nvidia-drivers fails to patch

[Dale]

Arve Barsnes wrote:
> On Fri, 21 Apr 2023 at 10:58, Dale  wrote:
>> I put my local ebuilds in /usr/local/portage.  Obviously emerge sees it
>> since it was trying to use it.  I don't understand why it doesn't work
>> tho.  I looked at the ebuild in the tree and my overlay, they look the
>> same, including the patches from different versions.
>>
>> Now I need to figure out why the overlay version isn't working.  I've
>> had occasion to need older versions before, due to some bug or
>> something.  Gonna see if it builds against the new kernel now.  Let us
>> pray.
> If your ebuild and the repo ebuild are the same, that means that the
> patch was changed, look in your
> /usr/local/portage/x11-drivers/nvidia-drivers/files/ folder and
> compare with the current files.
>
> Regards,
> Arve
>
>


Well, there's the problem.  There's no files directory there.  I ran the
ebuild command when I added it to the overlay, I don't think it
downloaded anything.  I just copied the ebuild file from the Gentoo
tree.  If I ever need to emerge from the overlay, I hope it works now. 

Did something change with overlays?  In the past, I copied the ebuild
over to local overlay and ran the ebuild command for the manifest.  It
downloaded everything that was needed.  Now, it seems it doesn't.  They
add a step?  I miss a step that slipped my mind? 

Dale

:-)  :-) 

Re: [gentoo-user] Nvidia-drivers fails to patch

[Arve Barsnes]

On Fri, 21 Apr 2023 at 10:58, Dale  wrote:
> I put my local ebuilds in /usr/local/portage.  Obviously emerge sees it
> since it was trying to use it.  I don't understand why it doesn't work
> tho.  I looked at the ebuild in the tree and my overlay, they look the
> same, including the patches from different versions.
>
> Now I need to figure out why the overlay version isn't working.  I've
> had occasion to need older versions before, due to some bug or
> something.  Gonna see if it builds against the new kernel now.  Let us
> pray.

If your ebuild and the repo ebuild are the same, that means that the
patch was changed, look in your
/usr/local/portage/x11-drivers/nvidia-drivers/files/ folder and
compare with the current files.

Regards,
Arve

Re: [gentoo-user] Nvidia-drivers fails to patch

[Dale]

Frank Steinmetzger wrote:
> Am Thu, Apr 20, 2023 at 08:33:22PM -0500 schrieb Dale:
>
>> I cleared the tmp files to give it a fresh start.  It still failed.  The
>> directory and files it complains about being missing, they are.  I went
>> to the ebuild to see what patches are supposed to be installed.  This is
>> the part of the ebuild. 
>>
>>
>> PATCHES=(
>>     "${FILESDIR}"/nvidia-drivers-470.141.03-clang15.patch
>>     "${FILESDIR}"/nvidia-modprobe-390.141-uvm-perms.patch
>>     "${FILESDIR}"/nvidia-settings-390.144-desktop.patch
>>     "${FILESDIR}"/nvidia-settings-390.144-no-gtk2.patch
>>     "${FILESDIR}"/nvidia-settings-390.144-raw-ldflags.patch
>> )
>>
>>
>> As you can see, it wants to apply patches from several versions so while
>> odd, I guess it really does it that way.  I suspect given the age of the
>> drivers that the patches no longer exist or something.  I'd think it
>> would report it couldn't download the files but maybe not.  I may be
>> running out of luck here.  Odd thing is, it compiled a while back. 
> If I read your error output correctly, it’s not that the patch file is 
> missing, but that a file that is mentioned inside the patch is.
>


Oh.  The output of emerge has always been sort of cryptic.  LOL  I just
hope nothing happens where I have to re-emerge it.  At this point, I'd
be in a pickle if the drivers failed and needed to be reinstalled. 

I did a emerge -ef nvidia-drivers and it still fails.  I was hoping that
would pick up the needed files.  Guess not.  I decided to do some more
digging.  I noticed that the same version is still in the tree.  I
copied the ebuild a while back to a local overlay to make sure I don't
lose it.  It seems emerge gives my local overlay priority over the one
in the tree.  I renamed the ebuild in my overlay with .old tacked on. 
It emerges fine after that since it uses the ebuild in the tree.  It
seems my overlay is broken somehow.  Likely a design improvement.  ;-) 

I put my local ebuilds in /usr/local/portage.  Obviously emerge sees it
since it was trying to use it.  I don't understand why it doesn't work
tho.  I looked at the ebuild in the tree and my overlay, they look the
same, including the patches from different versions. 

Now I need to figure out why the overlay version isn't working.  I've
had occasion to need older versions before, due to some bug or
something.  Gonna see if it builds against the new kernel now.  Let us
pray. 

Always something.  :/

Dale

:-)  :-) 

Re: [gentoo-user] Nvidia-drivers fails to patch

[Frank Steinmetzger]

Am Thu, Apr 20, 2023 at 08:33:22PM -0500 schrieb Dale:

> I cleared the tmp files to give it a fresh start.  It still failed.  The
> directory and files it complains about being missing, they are.  I went
> to the ebuild to see what patches are supposed to be installed.  This is
> the part of the ebuild. 
> 
> 
> PATCHES=(
>     "${FILESDIR}"/nvidia-drivers-470.141.03-clang15.patch
>     "${FILESDIR}"/nvidia-modprobe-390.141-uvm-perms.patch
>     "${FILESDIR}"/nvidia-settings-390.144-desktop.patch
>     "${FILESDIR}"/nvidia-settings-390.144-no-gtk2.patch
>     "${FILESDIR}"/nvidia-settings-390.144-raw-ldflags.patch
> )
> 
> 
> As you can see, it wants to apply patches from several versions so while
> odd, I guess it really does it that way.  I suspect given the age of the
> drivers that the patches no longer exist or something.  I'd think it
> would report it couldn't download the files but maybe not.  I may be
> running out of luck here.  Odd thing is, it compiled a while back. 

If I read your error output correctly, it’s not that the patch file is 
missing, but that a file that is mentioned inside the patch is.

-- 
Grüße | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

Error: this virus requires DirectX and 64 MB of RAM!


signature.asc
Description: PGP signature

Re: [gentoo-user] Nvidia-drivers fails to patch

[Dale]

Morgan Wesström wrote:
> On 2023-04-21 00:36, Dale wrote:
>> /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/temp/environment:
>> line 1291:
>> /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch:
>>
>> No such file or directory
>>
>> Any thoughts?  Ideas?
>>
>
> I couldn't reproduce the error here. One thing that comes to mind is
> that your system might have an error in its repository configuration.
> /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files is a
> symlink and should point to your main repository, normally
> /var/db/repos/gentoo/x11-drivers/nvidia-drivers/files. When the emerge
> fails, can you check what that symlink actually points to and if this
> is where your repository is stored? What is the output of emerge
> --info? (Repository info is in that output).
>
> /Morgan
>
>

I cleared the tmp files to give it a fresh start.  It still failed.  The
directory and files it complains about being missing, they are.  I went
to the ebuild to see what patches are supposed to be installed.  This is
the part of the ebuild. 


PATCHES=(
    "${FILESDIR}"/nvidia-drivers-470.141.03-clang15.patch
    "${FILESDIR}"/nvidia-modprobe-390.141-uvm-perms.patch
    "${FILESDIR}"/nvidia-settings-390.144-desktop.patch
    "${FILESDIR}"/nvidia-settings-390.144-no-gtk2.patch
    "${FILESDIR}"/nvidia-settings-390.144-raw-ldflags.patch
)


As you can see, it wants to apply patches from several versions so while
odd, I guess it really does it that way.  I suspect given the age of the
drivers that the patches no longer exist or something.  I'd think it
would report it couldn't download the files but maybe not.  I may be
running out of luck here.  Odd thing is, it compiled a while back. 

I tried to google and find the patch, no luck.  No idea where it comes
from.  May run emerge -ef nvidia-drivers and see if it works. 

Also, I switch to the current kernel, it failed in the same way.  It
isn't just the new kernel, it seems to be any of them.  I wonder how
hard it is to switch to that other driver.  From the wiki page, it looks
like a big deal. 

Dale

:-)  ;-)

Re: [gentoo-user] Nvidia-drivers fails to patch

[Morgan Wesström]

On 2023-04-21 00:36, Dale wrote:

/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/temp/environment:
line 1291:
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch:
No such file or directory

Any thoughts?  Ideas?



I couldn't reproduce the error here. One thing that comes to mind is that your 
system might have an error in its repository configuration. 
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files is a symlink and 
should point to your main repository, normally 
/var/db/repos/gentoo/x11-drivers/nvidia-drivers/files. When the emerge fails, 
can you check what that symlink actually points to and if this is where your 
repository is stored? What is the output of emerge --info? (Repository info is 
in that output).

/Morgan

Re: [gentoo-user] Nvidia-drivers fails to patch

[Mark Knecht]

On Thu, Apr 20, 2023 at 3:36 PM Dale  wrote:

>  *   patch -p1  failed with
>
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch


You know I don't run Gentoo, right?

That looks weird to me - building 470.182.03 but patching it with
470.141.03.
Just looks weird...

I think the other day someone - maybe Thelma? - had a problem
where there was something left over in some 'patch' directory.
Possibly you have something like that going on?

You know I don't run Gentoo, right? ;-)

Cheers,
Mark

Re: [gentoo-user] nvidia-drivers wants static-libs, I do not.

[Dale]

Arve Barsnes wrote:
> On Sun, 13 Feb 2022 at 14:12, Dale  wrote:
>> I suspect Kicad is not used by most but removing digikam seemed to be
>> the one that opened the door to a clear path for emerge.  That package
>> is commonly used.  So, that info may help if a person runs into this.
>> I'm not sure what if any effect boost had.  It may be worth not removing
>> it unless others fail to give a clear path.
>>
>> Thanks again for the help.  I saw it but didn't realize its meaning.
>> You did.
> You shouldn't have libs in your world file anyway, it should only be
> the packages that you directly use. If packages need it, and many use
> boost, they will pull it in as needed. :)
>
> Regards,
> Arve
>
>


I noticed that boost was pulled in when doing the other updates since. 
I have -1 in my emerge defaults so at some point, I had to have a good
reason for putting it there on purpose.  Thing is, you are correct, it
shouldn't be there. 

As a update to status, it is doing a emerge @preserved-rebuild right now
but it found a clear path.  Once that is done, I plan to add the others
in my list except boost.  I'm going to scan my world file too, just in
case something else is lurking about that shouldn't be there.  We all
know that having things in there that shouldn't be there causes issues. 
How boost got there, I'm not sure. 

Thanks again.  So far, nvidia-settings is not wanting static-libs so it
seems that is fixed. 

Dale

:-)  :-) 

P. S.  I got a email that another part of KDE just got released.  Oh
yeppie.  :-D

Re: [gentoo-user] nvidia-drivers wants static-libs, I do not.

[Arve Barsnes]

On Sun, 13 Feb 2022 at 14:12, Dale  wrote:
> I suspect Kicad is not used by most but removing digikam seemed to be
> the one that opened the door to a clear path for emerge.  That package
> is commonly used.  So, that info may help if a person runs into this.
> I'm not sure what if any effect boost had.  It may be worth not removing
> it unless others fail to give a clear path.
>
> Thanks again for the help.  I saw it but didn't realize its meaning.
> You did.

You shouldn't have libs in your world file anyway, it should only be
the packages that you directly use. If packages need it, and many use
boost, they will pull it in as needed. :)

Regards,
Arve

Re: [gentoo-user] nvidia-drivers wants static-libs, I do not.

[Dale]

Arve Barsnes wrote:
> On Sun, 13 Feb 2022 at 09:43, Dale  wrote:
>> The following USE changes are necessary to proceed:
>>  (see "package.use" in the portage(5) man page for more details)
>> # required by sci-libs/vtk-9.0.3-r4::gentoo[video_cards_nvidia]
>> # required by sci-libs/opencascade-7.5.2-r5::gentoo[vtk]
>> # required by sci-electronics/kicad-5.1.12-r2::gentoo[occ]
>> # required by sci-electronics/kicad-packages3d-5.1.12-r1::gentoo
>> # required by sci-electronics/kicad-meta-5.1.12::gentoo[-minimal]
>> # required by @selected
>> # required by @world (argument)
>>> =x11-drivers/nvidia-drivers-470.103.01 static-libs
>> Would you like to add these changes to your config files? [Yes/No]
>>
>>
>> I'm not sure if the boost output is related or not.  I did read
>> somewhere that opencascade is replacing oce.  From the above, I suspect
>> vtk and/or opencascade is causing this.  That may be related but dang if
>> I can figure out a way around this.  Anyone else run into this and find
>> a fix or see something I'm missing?
> I don't know how this would impact functionality, but it looks like
> you could avoid this by setting USE on sci-libs/vtk to
> "-video_cards_nvidia". The cuda USE flag requires this, but that is
> already disabled for you.
>
> Regards,
> Arve
>
>

Oh thank you for that hint.  I thought that was coming from make.conf
that I had a nvidia video card as opposed to a ATI or something.  No
idea I could disable it since it was just a USE flag.  Changing that got
me out of the static-libs USE flag demand. 

Now I'm having issues with hdf5 and flann.  I think this is like the
harfbuzz circle people run into.  I ended up removing packages that are
not absolutely needed in order to get it to give me a clean path.  I
plan to add those packages back to the world file once this emerge is
done and see if it emerges those back without problems.  In case someone
else runs into this problem, even tho this thread wasn't exactly about
this, this is what I had to remove from the world file.


dev-libs/boost
sci-electronics/kicad-meta
media-gfx/digikam


I suspect Kicad is not used by most but removing digikam seemed to be
the one that opened the door to a clear path for emerge.  That package
is commonly used.  So, that info may help if a person runs into this. 
I'm not sure what if any effect boost had.  It may be worth not removing
it unless others fail to give a clear path.

Thanks again for the help.  I saw it but didn't realize its meaning. 
You did. 

Dale

:-)  :-) 

Re: [gentoo-user] nvidia-drivers wants static-libs, I do not.

[Arve Barsnes]

On Sun, 13 Feb 2022 at 09:43, Dale  wrote:
> The following USE changes are necessary to proceed:
>  (see "package.use" in the portage(5) man page for more details)
> # required by sci-libs/vtk-9.0.3-r4::gentoo[video_cards_nvidia]
> # required by sci-libs/opencascade-7.5.2-r5::gentoo[vtk]
> # required by sci-electronics/kicad-5.1.12-r2::gentoo[occ]
> # required by sci-electronics/kicad-packages3d-5.1.12-r1::gentoo
> # required by sci-electronics/kicad-meta-5.1.12::gentoo[-minimal]
> # required by @selected
> # required by @world (argument)
> >=x11-drivers/nvidia-drivers-470.103.01 static-libs
>
> Would you like to add these changes to your config files? [Yes/No]
>
>
> I'm not sure if the boost output is related or not.  I did read
> somewhere that opencascade is replacing oce.  From the above, I suspect
> vtk and/or opencascade is causing this.  That may be related but dang if
> I can figure out a way around this.  Anyone else run into this and find
> a fix or see something I'm missing?

I don't know how this would impact functionality, but it looks like
you could avoid this by setting USE on sci-libs/vtk to
"-video_cards_nvidia". The cuda USE flag requires this, but that is
already disabled for you.

Regards,
Arve

Re: [gentoo-user] nvidia-drivers-440.82-r3 failing to compile: Kernel configuration is invalid

[Ján Zahornadský]

On 21/05/2020 20:25, Ashley Dixon wrote:

On Thu, May 21, 2020 at 08:13:38PM +0100, Ján Zahornadský wrote:

when updating the system today, a new revision of nvidia-drivers ebuild
fails with

ERROR: Kernel configuration is invalid.
include/generated/autoconf.h or include/config/auto.conf are missing.
Run 'make oldconfig && make prepare' on kernel src to fix it.

(full log attached as build.log)

I'm fairly sure my kernel sources and configuration are in place:

bolt /usr/src/linux-5.6.14-gentoo # ls -l include/generated/autoconf.h
include/config/auto.conf
-rw--- 1 root root 26144 May 21 10:13 include/config/auto.conf
-rw--- 1 root root 35329 May 21 10:13 include/generated/autoconf.h


Try executing `chmod a+r ` on both of those files.



Yes, thanks, it was a permission issue after all, re-setting umask and 
re-running make mrproper && make && make modules_install fixed it!


All the best,
Jan

Re: [gentoo-user] nvidia-drivers-440.82-r3 failing to compile: Kernel configuration is invalid

[Ján Zahornadský]

On 21/05/2020 20:25, Ashley Dixon wrote:

On Thu, May 21, 2020 at 08:13:38PM +0100, Ján Zahornadský wrote:

when updating the system today, a new revision of nvidia-drivers ebuild
fails with

ERROR: Kernel configuration is invalid.
include/generated/autoconf.h or include/config/auto.conf are missing.
Run 'make oldconfig && make prepare' on kernel src to fix it.

(full log attached as build.log)

I'm fairly sure my kernel sources and configuration are in place:

bolt /usr/src/linux-5.6.14-gentoo # ls -l include/generated/autoconf.h
include/config/auto.conf
-rw--- 1 root root 26144 May 21 10:13 include/config/auto.conf
-rw--- 1 root root 35329 May 21 10:13 include/generated/autoconf.h


Try executing `chmod a+r ` on both of those files.



That sadly didn't help :-(

> Is  /usr/src/linux a symlink to  /usr/src/linux-5.6.14-gentoo ? The
> nvidia-drivers package looks for the kernel sources in /usr/src/linux
> so if the symlink is wrong then you might get errors like these.

Yes, I have a symlink in /usr/src:

bolt ~ # ls -l /usr/src/
total 8
lrwxrwxrwx  1 root root   19 May 21 10:12 linux -> linux-5.6.14-gentoo
drwxr-xr-x 25 root root 4096 May 20 22:03 linux-5.6.13-gentoo
drwxr-xr-x 25 root root 4096 May 21 10:58 linux-5.6.14-gentoo

Re: [gentoo-user] nvidia-drivers-440.82-r3 failing to compile: Kernel configuration is invalid

[Ashley Dixon]

On Thu, May 21, 2020 at 08:13:38PM +0100, Ján Zahornadský wrote:
> when updating the system today, a new revision of nvidia-drivers ebuild
> fails with
> 
> ERROR: Kernel configuration is invalid.
>include/generated/autoconf.h or include/config/auto.conf are missing.
>Run 'make oldconfig && make prepare' on kernel src to fix it.
> 
> (full log attached as build.log)
> 
> I'm fairly sure my kernel sources and configuration are in place:
> 
> bolt /usr/src/linux-5.6.14-gentoo # ls -l include/generated/autoconf.h
> include/config/auto.conf
> -rw--- 1 root root 26144 May 21 10:13 include/config/auto.conf
> -rw--- 1 root root 35329 May 21 10:13 include/generated/autoconf.h

Try executing `chmod a+r ` on both of those files.

-- 

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA



signature.asc
Description: PGP signature

Re: [gentoo-user] nvidia-drivers-440.82-r3 failing to compile: Kernel configuration is invalid

[Manuel McLure]

On Thu, May 21, 2020 at 12:14 PM Ján Zahornadský  wrote:

>
> bolt /usr/src/linux-5.6.14-gentoo # ls -l include/generated/autoconf.h
> include/config/auto.conf
> -rw--- 1 root root 26144 May 21 10:13 include/config/auto.conf
> -rw--- 1 root root 35329 May 21 10:13 include/generated/autoconf.h
>
>
Is  /usr/src/linux a symlink to  /usr/src/linux-5.6.14-gentoo ? The
nvidia-drivers package looks for the kernel sources in /usr/src/linux so if
the symlink is wrong then you might get errors like these.

-- 
Manuel A. McLure WW1FA  
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat.   -- H.P. Lovecraft

Re: [gentoo-user] nvidia-drivers-396.24-r1

[Philip Webb]

180709 Davyd McColl wrote:
> 180610 Philip Webb wrote:
>> I updated to the latest stable Nvidia-drivers-396.24-r1 ,
>> rebooted & 'startx' :
>> the result was an X error "No devices detected ... no screens found".
>> I updated to kernel 4.14.52-gentoo & tried Nvidia-drivers as above
>> with the same result ; downgrading to 390.67 got X working again.
> I have exactly the same kernel (4.14.52-gentoo) and nvidia-drivers 
> (396.24-r1) and I don't experience this issue
> Perhaps this is specific to the card ? I have a 660ti.

I have ASUS GT610 , which is supported by Nvidia 396.18 :
https://www.geforce.com/drivers/results/133571 .
NB they say '18' is beta & don't list '24' at all :
I'm not sure why it's marked stable by Gentoo.

> Have you checked that the nvidia module is even being loaded :
> 'lsmod | grep nvidia' ?

No problem loading the '390' driver : why would the '396' be different ?

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

Re: [gentoo-user] nvidia-drivers-396.24-r1

[Davyd McColl]

I have exactly the same kernel (4.14.52-gentoo) and nvidia-drivers 
(396.24-r1) and I don't experience this issue (though games requiring 
Vulkan crash out sporadically - there's an ongoing issue on the nvidia 
forums for this, where apparently it's already been fixed in some ancient 
fork, and not merged back).

Perhaps this is specific to the card? I have a 660ti.

Have you checked that the nvidia module is even being loaded (lsmod | grep 
nvidia)?


-d


On July 9, 2018 00:46:34 Philip Webb  wrote:


180610 Philip Webb wrote:

I updated to the latest stable Nvidia-drivers-396.24-r1 ,
rebooted & 'startx' :
the result was an X error "No devices detected ... no screens found".
Downgrading to 390.48 got X working again.
Nothing to see on the Forum or among Gentoo 'nvidia' bugs.
My kernel is 4.9.16-gentoo.


I've updated to kernel 4.14.52-gentoo & tried Nvidia-drivers as above
with the same result ; downgrading to 390.67 got X working again.

Has anyone else experienced this problem or similar ?
Does anyone have advice ?

--
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

Re: [gentoo-user] nvidia-drivers-396.24-r1

[Jack]

On 2018.07.08 18:46, Philip Webb wrote:

180610 Philip Webb wrote:
> I updated to the latest stable Nvidia-drivers-396.24-r1 ,
> rebooted & 'startx' :
> the result was an X error "No devices detected ... no screens  
found".

> Downgrading to 390.48 got X working again.
> Nothing to see on the Forum or among Gentoo 'nvidia' bugs.
> My kernel is 4.9.16-gentoo.

I've updated to kernel 4.14.52-gentoo & tried Nvidia-drivers as above
with the same result ; downgrading to 390.67 got X working again.

Has anyone else experienced this problem or similar ?
Does anyone have advice ?


Check the xorg log.  New(er) nvidia-drivers often take a bit of time to  
get upgraded to handle the most recent kernels.  There is likely a more  
concrete (if no less helpful) message in the xorg log.  You may need to  
stick to an older driver and/or kernel until one of them catches up  
with the other.  (I no longer have an nvidia card in my Gentoo box, so  
I have no current specifics, but even when I did, it was legacy 340.xx.


Jack

Re: [gentoo-user] nvidia-drivers-396.24-r1

[Philip Webb]

180610 Philip Webb wrote:
> I updated to the latest stable Nvidia-drivers-396.24-r1 ,
> rebooted & 'startx' :
> the result was an X error "No devices detected ... no screens found".
> Downgrading to 390.48 got X working again.
> Nothing to see on the Forum or among Gentoo 'nvidia' bugs.
> My kernel is 4.9.16-gentoo.

I've updated to kernel 4.14.52-gentoo & tried Nvidia-drivers as above
with the same result ; downgrading to 390.67 got X working again.

Has anyone else experienced this problem or similar ?
Does anyone have advice ?

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

Re: [gentoo-user] nvidia-drivers-396.24-r1

[T ed Ozolins]

On 18-06-09 10:22 PM, Philip Webb wrote:

I updated to the latest stable Nvidia-drivers-396.24-r1 ,
rebooted & 'startx' :
the result was an X error "No devices detected ... no screens found".
Downgrading to 390.48 got X working again.
Nothing to see on the Forum or among Gentoo 'nvidia' bugs.
My kernel is 4.9.16-gentoo.

Has anyone else run into this ?  Any other advice or comments ?


Last time that happened here, I ended up buying a newer nvidia card.

--
Ted Ozolins
Cranbrook, BC

Re: [gentoo-user] Nvidia-drivers,

[Jigme Datse Yli-Rasku]

Some time around when Spectre/Meltdown were announced, I started
experiencing similar problems.  I don't know "what's wrong" because so
far I have found no answers.

The best I can offer at this point is that on my system, it seems that
it will work with Nouveau drivers much better than the system currently
works with NVIDIA drivers.

Unfortunately, I haven't managed to get a working version of that yet,
but I usually only manage to put a few hours a week on trying to figure
it out.

I fortunately haven't had the problem that I have to kill power to the
computer, though I think I have gone through some times I have needed to
reboot, rather than just get back into X either through killing
processes, or (very rarely) stopping one problematic process which is
the source.

On 03/18/2018 09:40 AM, Alan Grimes wrote:
> Gentlemen, we have a problem...
> 
> Okay, ~ a week ago there was a power outage at my place, everything goes
> down for a day or two. I had recently refreshed my UPS batteries, so I
> had a chance to put that into the circuit, no biggy.
> 
> Since nobody will offer me a job, I was playing Kerbal space program yet
> again. (not even Don Corleone could get me a job at this point, I
> frequently joke about the horse head trick but, seriously, I don't think
> even that would work...)
> 
> So, after all of two and a half days of uptime, nvidia drivers takes
> x'-doze down.
> 
> I was like "Ok, fine, I'll do a maintenance cycle on my machine and all
> will be good..."
> 
> So I update the bios, update the kernel, update portage, flush a few
> dead packages down the memory hole... Ok, my system was in shape again...
> 
> So, I'm back in kerbal, another day or two goes by, I'm sitting there
> trying to figure out whether I have enough room in my departure corridor
> to slot in a contract mission to Jool.. I wasn't even sitting down, just
> poking around in my kitchen. When I got back, the game was frozen. I had
> to log in with my PoS laptop which is useful only for this task. I found
> that KSP, and X'doze were live-locked, presumably on a Nvidia-drivers
> bug. =( I tried killing off KSP but it ended up going zombie... I tried
> killing off parent processes, no luck, I then tried shutting down the
> machine the normal way, no good. I eventually ended up going to the
> dusty 28 year old power commander thing and throwing the big orange
> switch labelled COMPUTER (complete and instantaneous removal of power).
> 
> What's going on here? Nvidia drivers have been stable for years...
> what's the deal? =\
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Nvidia Drivers. =(

[Andreas K. Huettel]

Am Mittwoch, 5. April 2017, 18:53:43 CEST schrieb Alan Grimes:
> I hit the "view raw" link and used save as... I then copied it into the
> "files" subdirectoy and portage threw a hissy fit 

Please re-read the instructions in Fabio's mail.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Nvidia Drivers. =(

[Neil Bothwick]

On Wed, 05 Apr 2017 12:53:43 -0400, Alan Grimes wrote:

> I hit the "view raw" link and used save as... I then copied it into the
> "files" subdirectoy and portage threw a hissy fit and refused to do
> anything because letting the user patch a package is simply
> unthinkable!!! A mere USER, applying a custom patch to one of our
> immaculate packages on HIS OWN COMPUTER??!?!?! UNTHINKABLE!!!

Yes, just let anyone modify files in your portage tree and have portage
ignore any such changes, very secure.

> So it
> doesn't flash a warning, or a "are you sure?", it just barfs and
> quits.  I then mv ..'d it. and portage completely ignores the file. 
> Doesn't match any of the versions I have anyway.

One of the problems with top posting is it makes it much easier to reply
to an email without properly reading it. The text you quoted tells you
exactly how to apply user patches, and they don't go in the portage tree.
 
> Which gets me back to how wise I was for version-freezing myself at
> 4.6.7...
> 
> And yes, I am continuing to call my Ryzen 1800x "tortoise". =P
> 
> ###
> 
> tortoise nvidia-drivers # ls -l
> total 268
> -rw-r--r-- 1 rootroot10392 Apr  5 12:42 378.09-4.10-rc8.patch
> drwxr-xr-x 2 portage portage  4096 Apr  5 12:43 files
> -rw-r--r-- 1 portage portage 32304 Mar 30 03:29 Manifest
> -rw-r--r-- 1 portage portage  1250 Mar 30 03:27 metadata.xml
> -rw-r--r-- 1 portage portage 16490 Feb 28 14:50
> nvidia-drivers-173.14.39-r1.ebuild
> -rw-r--r-- 1 portage portage 16476 Feb 28 14:50
> nvidia-drivers-173.14.39-r2.ebuild
> -rw-r--r-- 1 portage portage 13327 Feb 28 14:50
> nvidia-drivers-304.134.ebuild
> -rw-r--r-- 1 portage portage 13412 Feb 28 14:50
> nvidia-drivers-304.134-r1.ebuild
> -rw-r--r-- 1 portage portage 13410 Mar 30 03:29
> nvidia-drivers-304.135.ebuild
> -rw-r--r-- 1 portage portage 14460 Feb 28 14:50
> nvidia-drivers-340.101.ebuild
> -rw-r--r-- 1 portage portage 14525 Feb 28 14:50
> nvidia-drivers-340.101-r1.ebuild
> -rw-r--r-- 1 portage portage 14523 Mar 30 03:29
> nvidia-drivers-340.102.ebuild
> -rw-r--r-- 1 portage portage 15425 Feb 28 14:50
> nvidia-drivers-375.26.ebuild -rw-r--r-- 1 portage portage 15613 Feb 28
> 14:50 nvidia-drivers-375.26-r3.ebuild
> -rw-r--r-- 1 portage portage 15611 Mar 30 03:29
> nvidia-drivers-375.39.ebuild -rw-r--r-- 1 portage portage 15676 Mar 30
> 03:29 nvidia-drivers-378.13.ebuild -rw-r--r-- 1 portage portage 14755
> Feb 28 14:50 nvidia-drivers-96.43.23-r1.ebuild
> tortoise nvidia-drivers #
> 
> 
> 
> 
> Fabio Scaccabarozzi wrote:
> >
> > You can drop it in /etc/portage/patches/x11-drivers/nvidia-drivers
> > folder, portage should take care of the rest when you emerge the
> > package. You should see 3 lines near the prepare phase, before the
> > configure phase, saying something like "applying user patches from...
> > Applying ...Done applying user patches"
> >
> >
> > Il mer 5 apr 2017, 17:40 Alan Grimes  > > ha scritto:
> >
> > Looks like a good patch but can you link to instructions for
> > applying this patch?
> >
> >
> > Fabio Scaccabarozzi wrote:  
> > >
> > > Hi Alan,
> > >
> > > That is expected with 4.10 kernels.
> > > You can grab a patch from my /etc/portage repository:
> > >  
> > 
> > https://github.com/fsvm88/gentoo-portage_etc/blob/master/patches/x11-drivers/nvidia-drivers/378.09-4.10-rc8.patch
> >   
> > >
> > > I took it from the NVidia forums, you can also find it there, I
> > > just rebased it for portage.
> > >  
> >
> >
> > --
> > Strange Game.
> > The only winning move is not to play.
> >
> > Powers are not rights.
> >
> >  
> 
> 




-- 
Neil Bothwick

NOTICE:
  --  THE ELEVATORS WILL BE OUT OF ORDER TODAY  --
  (The nearest working elevators are in the building
   across the street.)


pgpvSPvO0uqsN.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Nvidia Drivers. =(

[Manuel McLure]

On Wed, Apr 5, 2017 at 9:53 AM, Alan Grimes  wrote:

> I hit the "view raw" link and used save as... I then copied it into the
> "files" subdirectoy and portage threw a hissy fit and refused to do
> anything because letting the user patch a package is simply
> unthinkable!!! A mere USER, applying a custom patch to one of our
> immaculate packages on HIS OWN COMPUTER??!?!?! UNTHINKABLE!!! So it
> doesn't flash a warning, or a "are you sure?", it just barfs and
> quits.  I then mv ..'d it. and portage completely ignores the file.
> Doesn't match any of the versions I have anyway.
>
> Which gets me back to how wise I was for version-freezing myself at
> 4.6.7...
>
> And yes, I am continuing to call my Ryzen 1800x "tortoise". =P
>
> It looks like you put it in /usr/portage/x11-drivers/nvidia-drivers, not
in  /etc/portage/patches/x11-drivers/nvidia-drivers

>
>

-- 
Manuel A. McLure WW1FA  
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat.   -- H.P. Lovecraft

Re: [gentoo-user] Nvidia Drivers. =(

[Alan Grimes]

I hit the "view raw" link and used save as... I then copied it into the
"files" subdirectoy and portage threw a hissy fit and refused to do
anything because letting the user patch a package is simply
unthinkable!!! A mere USER, applying a custom patch to one of our
immaculate packages on HIS OWN COMPUTER??!?!?! UNTHINKABLE!!! So it
doesn't flash a warning, or a "are you sure?", it just barfs and
quits.  I then mv ..'d it. and portage completely ignores the file. 
Doesn't match any of the versions I have anyway.

Which gets me back to how wise I was for version-freezing myself at
4.6.7...

And yes, I am continuing to call my Ryzen 1800x "tortoise". =P

###

tortoise nvidia-drivers # ls -l
total 268
-rw-r--r-- 1 rootroot10392 Apr  5 12:42 378.09-4.10-rc8.patch
drwxr-xr-x 2 portage portage  4096 Apr  5 12:43 files
-rw-r--r-- 1 portage portage 32304 Mar 30 03:29 Manifest
-rw-r--r-- 1 portage portage  1250 Mar 30 03:27 metadata.xml
-rw-r--r-- 1 portage portage 16490 Feb 28 14:50
nvidia-drivers-173.14.39-r1.ebuild
-rw-r--r-- 1 portage portage 16476 Feb 28 14:50
nvidia-drivers-173.14.39-r2.ebuild
-rw-r--r-- 1 portage portage 13327 Feb 28 14:50
nvidia-drivers-304.134.ebuild
-rw-r--r-- 1 portage portage 13412 Feb 28 14:50
nvidia-drivers-304.134-r1.ebuild
-rw-r--r-- 1 portage portage 13410 Mar 30 03:29
nvidia-drivers-304.135.ebuild
-rw-r--r-- 1 portage portage 14460 Feb 28 14:50
nvidia-drivers-340.101.ebuild
-rw-r--r-- 1 portage portage 14525 Feb 28 14:50
nvidia-drivers-340.101-r1.ebuild
-rw-r--r-- 1 portage portage 14523 Mar 30 03:29
nvidia-drivers-340.102.ebuild
-rw-r--r-- 1 portage portage 15425 Feb 28 14:50 nvidia-drivers-375.26.ebuild
-rw-r--r-- 1 portage portage 15613 Feb 28 14:50
nvidia-drivers-375.26-r3.ebuild
-rw-r--r-- 1 portage portage 15611 Mar 30 03:29 nvidia-drivers-375.39.ebuild
-rw-r--r-- 1 portage portage 15676 Mar 30 03:29 nvidia-drivers-378.13.ebuild
-rw-r--r-- 1 portage portage 14755 Feb 28 14:50
nvidia-drivers-96.43.23-r1.ebuild
tortoise nvidia-drivers #




Fabio Scaccabarozzi wrote:
>
> You can drop it in /etc/portage/patches/x11-drivers/nvidia-drivers
> folder, portage should take care of the rest when you emerge the
> package. You should see 3 lines near the prepare phase, before the
> configure phase, saying something like "applying user patches from...
> Applying ...Done applying user patches"
>
>
> Il mer 5 apr 2017, 17:40 Alan Grimes  > ha scritto:
>
> Looks like a good patch but can you link to instructions for applying
> this patch?
>
>
> Fabio Scaccabarozzi wrote:
> >
> > Hi Alan,
> >
> > That is expected with 4.10 kernels.
> > You can grab a patch from my /etc/portage repository:
> >
> 
> https://github.com/fsvm88/gentoo-portage_etc/blob/master/patches/x11-drivers/nvidia-drivers/378.09-4.10-rc8.patch
> >
> > I took it from the NVidia forums, you can also find it there, I just
> > rebased it for portage.
> >
>
>
> --
> Strange Game.
> The only winning move is not to play.
>
> Powers are not rights.
>
>


-- 
Strange Game.
The only winning move is not to play. 

Powers are not rights.

Re: [gentoo-user] Nvidia Drivers. =(

[Fabio Scaccabarozzi]

You can drop it in /etc/portage/patches/x11-drivers/nvidia-drivers folder,
portage should take care of the rest when you emerge the package. You
should see 3 lines near the prepare phase, before the configure phase,
saying something like "applying user patches from... Applying
...Done applying user patches"

Il mer 5 apr 2017, 17:40 Alan Grimes  ha scritto:

> Looks like a good patch but can you link to instructions for applying
> this patch?
>
>
> Fabio Scaccabarozzi wrote:
> >
> > Hi Alan,
> >
> > That is expected with 4.10 kernels.
> > You can grab a patch from my /etc/portage repository:
> >
> https://github.com/fsvm88/gentoo-portage_etc/blob/master/patches/x11-drivers/nvidia-drivers/378.09-4.10-rc8.patch
> >
> > I took it from the NVidia forums, you can also find it there, I just
> > rebased it for portage.
> >
>
>
> --
> Strange Game.
> The only winning move is not to play.
>
> Powers are not rights.
>
>
>

Re: [gentoo-user] Nvidia Drivers. =(

[Alan Grimes]

Looks like a good patch but can you link to instructions for applying
this patch?


Fabio Scaccabarozzi wrote:
>
> Hi Alan,
>
> That is expected with 4.10 kernels.
> You can grab a patch from my /etc/portage repository:
> https://github.com/fsvm88/gentoo-portage_etc/blob/master/patches/x11-drivers/nvidia-drivers/378.09-4.10-rc8.patch
>
> I took it from the NVidia forums, you can also find it there, I just
> rebased it for portage.
>


-- 
Strange Game.
The only winning move is not to play. 

Powers are not rights.

Re: [gentoo-user] Nvidia Drivers. =(

[Fabio Scaccabarozzi]

Hi Alan,

That is expected with 4.10 kernels.
You can grab a patch from my /etc/portage repository:
https://github.com/fsvm88/gentoo-portage_etc/blob/master/patches/x11-drivers/nvidia-drivers/378.09-4.10-rc8.patch

I took it from the NVidia forums, you can also find it there, I just
rebased it for portage.

Il mer 5 apr 2017, 16:19 Alan Grimes  ha scritto:

> I'm still running on my old kernel as I re-build my system, Nvidia
> drivers just barfed
>
> ###
> tortoise src # ls -l
> total 12
> lrwxrwxrwx  1 root root   13 Apr  5 09:50 linux -> linux-4.10.8/
> drwxr-xr-x 25 root root 4096 Apr  5 10:01 linux-4.10.8
> drwxrwxr-x 25 root root 4096 Apr  4 22:34 linux-4.6.7
> drwxr-xr-x  7 root root 4096 Nov 23  2014 rpm
> tortoise src #
> ###
>
>
> x86_64-pc-linux-gnu-gcc
>
> -Wp,-MD,/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/.nv-pat.o.d
> -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include
> -I/usr/src/linux-4.10.8/arch/x86/include
> -I./arch/x86/include/generated/uapi -I./arch/x86/include/generated
> -I/usr/src/linux-4.10.8/include -I./include
> -I/usr/src/linux-4.10.8/arch/x86/include/uapi
> -I/usr/src/linux-4.10.8/include/uapi -I./include/generated/uapi -include
> /usr/src/linux-4.10.8/include/linux/kconfig.h
>
> -I/usr/src/linux-4.10.8//var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel
> -I/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel
> -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
> -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
> -Wno-format-security -std=gnu89 -fno-PIE -mno-sse -mno-mmx -mno-sse2
> -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387
> -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup
> -march=k8 -mno-red-zone -mcmodel=kernel -funit-at-a-time
> -maccumulate-outgoing-args -DCONFIG_AS_CFI=1
> -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
> -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1
> -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1
> -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno-sign-compare
> -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -O2
> --param=allow-store-data-races=0 -Wframe-larger-than=2048
> -fno-stack-protector -Wno-unused-but-set-variable
> -fno-omit-frame-pointer -fno-optimize-sibling-calls
> -fno-var-tracking-assignments -fno-inline-functions-called-once
> -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
> -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes
> -Werror=date-time -Werror=incompatible-pointer-types -DCC_HAVE_ASM_GOTO
> -I/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/common/inc
> -I/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel -Wall
> -MD -Wsign-compare -Wno-cast-qual -Wno-error -D__KERNEL__ -DMODULE
> -DNVRM -DNV_VERSION_STRING=\"378.13\" -Wno-unused-function
> -Wuninitialized -fno-strict-aliasing -mno-red-zone -mcmodel=kernel
> -DNV_UVM_ENABLE -Wno-sign-compare -Wno-format-extra-args -Werror=undef
> -I/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia
> -DNV_BUILD_MODULE_INSTANCES=0 -UDEBUG -U_DEBUG -DNDEBUG  -DMODULE
> -DKBUILD_BASENAME='"nv_pat"'  -DKBUILD_MODNAME='"nvidia"' -c -o
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.o
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:
> In function ‘nvidia_cpu_callback’:
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:213:14:
> error: ‘CPU_DOWN_FAILED’ undeclared (first use in this function)
>  case CPU_DOWN_FAILED:
>   ^
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:213:14:
> note: each undeclared identifier is reported only once for each function
> it appears in
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:220:14:
> error: ‘CPU_DOWN_PREPARE’ undeclared (first use in this function)
>  case CPU_DOWN_PREPARE:
>   ^
> In file included from
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:15:0:
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:
> In function ‘nv_init_pat_support’:
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/common/inc/nv-linux.h:391:34:
> error: implicit declaration of function ‘register_cpu_notifier’
> [-Werror=implicit-function-declaration]
>  #define register_hotcpu_notifier register_cpu_notifier
>   ^
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:258:17:
> note: in expansion of macro ‘register_hotcpu_notifier’
>  if (register_hotcpu_notifier(_hotcpu_nfb) != 0)
>  

Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

[David Haller]

Hello Meino,

On Sat, 30 Jul 2016, meino.cra...@gmx.de wrote:
[..]
>WHOW! Thanks a lot for the patch!

As this issue has just come up on gentoo-dev as well, has the patch
worked for you (so far)? Please give a report if it worked or not.

I've been unable to run/test my system with that patch for longer to
really have an opinion (no idea when that code actually gets called
while running the driver).

TIA,
-dnh

-- 
Ugga Ugga ! Nognog! Dadadadada! [Woko° in dag°]

Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

[David Haller]

Hello,

On Sat, 30 Jul 2016, meino.cra...@gmx.de wrote:
>David Haller  [16-07-30 13:24]:
[..]
>> I've got it working with the attached patch in
>> /etc/portage/patches/x11-drivers/nvidia-drivers-367.35/
[..]
>Short qyestion: How can I apply it...I mean...as soon as I do an
>emerge, either the original source will be unpacked or my package
>will be rejected for being modified an different from the one, which
>does not compile...

In this case: just create the dir

mkdir -p /etc/portage/patches/x11-drivers/nvidia-drivers-367.35/

and save the patch there. The rest works "as if by magic" thanks to
the epatch-user in the ebuild. The version in the directory-name makes
it only get applied to that version of the driver.

HTH,
-dnh

-- 
  If you fall and break your legs, don't come running to me.
-- Samuel Goldwyn

Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

[Meino . Cramer]

james  [16-07-30 20:52]:
> On 07/30/2016 01:15 PM, meino.cra...@gmx.de wrote:
> 
> >>>Short qyestion: How can I apply it...I mean...as soon as I do an
> >>>emerge, either the original source will be unpacked or my package
> >>>will be rejected for being modified an different from the one, which
> >>>does not compile...
> 
> >>http://tinyurl.com/jur3t8v
> 
> >Meino
> 
> I think that is true for EAPI-5. EAPI-6 or later ebuilds should only 
> require the patch be located in the dir with the sources 
> (/usr/portage  or /usr/local/portage/, I think.
> (epatch-users is good to google on. There might be a bit more to it, 
> but just google. Also, there are some eclasses that help this out a bit 
> for more complicated hacks. [1]
> 
> 1] https://devmanual.gentoo.org/eclass-reference/
> 
> 
> Usually, the best thing to do is put (your) patches and a full copy of 
> the ebuild into /usr/local/portage, for a guy like you who is hacking
> at ebuilds for embedded  boards anyway.
> 
> 
> proxy-maint folks are the best to answer these question and help you,
> cause there are always twists and bumps along the way, like 
> dependencies slightly changed and thus requiring a tweak. Unfortunately 
> they are only available on the irc channel.  Hopefully on of the devs 
> will clear this up even further, as last time I looked, this is a 
> subject that the devManual has not fully documented, or anyone compiled 
> a few examples for user to look at. It's a moving target depending on 
> the EAPI-level of the ebuild.
> 
> 
> hth,
> James
> 
> 
Hi James,

thanks for your help ! :)
Will check that... ;)

Best regards,
Meino

Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

[james]

On 07/30/2016 01:15 PM, meino.cra...@gmx.de wrote:


Short qyestion: How can I apply it...I mean...as soon as I do an
emerge, either the original source will be unpacked or my package
will be rejected for being modified an different from the one, which
does not compile...



http://tinyurl.com/jur3t8v



Meino


I think that is true for EAPI-5. EAPI-6 or later ebuilds should only 
require the patch be located in the dir with the sources 
(/usr/portage  or /usr/local/portage/, I think.
(epatch-users is good to google on. There might be a bit more to it, but 
just google. Also, there are some eclasses that help this out a bit for 
more complicated hacks. [1]


1] https://devmanual.gentoo.org/eclass-reference/


Usually, the best thing to do is put (your) patches and a full copy of 
the ebuild into /usr/local/portage, for a guy like you who is hacking

at ebuilds for embedded  boards anyway.


proxy-maint folks are the best to answer these question and help you,
cause there are always twists and bumps along the way, like dependencies 
slightly changed and thus requiring a tweak. Unfortunately they are only 
available on the irc channel.  Hopefully on of the devs will clear this 
up even further, as last time I looked, this is a subject that the 
devManual has not fully documented, or anyone compiled a few examples 
for user to look at. It's a moving target depending on the EAPI-level of 
the ebuild.



hth,
James

Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

[Meino . Cramer]

Andrew Lowe  [16-07-30 20:12]:
> On 31/07/2016 1:54 AM, meino.cra...@gmx.de wrote:
> >David Haller  [16-07-30 13:24]:
> >>Hello,
> >>
> >>On Sat, 30 Jul 2016, meino.cra...@gmx.de wrote:
> >>>trying the new kernel linux-4.7 (vanilla, downloaded from
> 
> [snip]
> 
> >
> >Short qyestion: How can I apply it...I mean...as soon as I do an
> >emerge, either the original source will be unpacked or my package
> >will be rejected for being modified an different from the one, which
> >does not compile...
> >
> >?
> >
> >Best regards,
> >Meino
> 
>   It's currently 2am Perth time and I've been staring at a screen for 
> too long trying to get a portable Win32 dev environmet for Uni students 
> working. I've consumed a fair amount of chocolate so the usual grain of 
> salt proviso applies. If I've understood the question correctly, this 
> link may be of help:
> 
> http://tinyurl.com/jur3t8v
> 
>   Andrew
> 
> 

Hi Andrew,

:)

Thanks a lot for your help!
Best
Meino

Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

[Andrew Lowe]

On 31/07/2016 1:54 AM, meino.cra...@gmx.de wrote:

David Haller  [16-07-30 13:24]:

Hello,

On Sat, 30 Jul 2016, meino.cra...@gmx.de wrote:

trying the new kernel linux-4.7 (vanilla, downloaded from


[snip]



Short qyestion: How can I apply it...I mean...as soon as I do an
emerge, either the original source will be unpacked or my package
will be rejected for being modified an different from the one, which
does not compile...

?

Best regards,
Meino


	It's currently 2am Perth time and I've been staring at a screen for too 
long trying to get a portable Win32 dev environmet for Uni students 
working. I've consumed a fair amount of chocolate so the usual grain of 
salt proviso applies. If I've understood the question correctly, this 
link may be of help:


http://tinyurl.com/jur3t8v

Andrew

Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

[Meino . Cramer]

David Haller  [16-07-30 13:24]:
> Hello,
> 
> On Sat, 30 Jul 2016, meino.cra...@gmx.de wrote:
> >trying the new kernel linux-4.7 (vanilla, downloaded from
> >ftp.kernel.org) with nvidia drivers 
> >(Installed versions:  367.35-r1^md(03:00:46 07/30/16)(X driver kms
> >multilib uvm -acpi -compat -gtk3 -pax_kernel -static-libs -tools
> >-wayland KERNEL="linux -FreeBSD")).
> >The kernel compiled fine, the nvidia-drivers does not.
> >
> >Anuone else with the same problem (read: This has to be
> >fixed by nvidia/Linus) or am I the only one (so it is
> >my problem...which does not neccessarily imply that I
> >know how to fix that ... ;) ???
> 
> I've got it working with the attached patch in
> /etc/portage/patches/x11-drivers/nvidia-drivers-367.35/
> 
> I've no idea though, if I hit that codepath yet. Should work though,
> as the patch makes the module use the kernel function and what I read
> about radix_tree_gang_lookup() it should be ok this way.
> 
> But do not expect anything to work ;)
> 
> I'm courious what the official patch will be ;) The first part
> (patching kernel/nvidia-drm/nvidia-drm-{fb,gem}.c) I've found online.
> 
> HTH,
> -dnh
> 
> -- 
> Please do not think so much about licenses, it will just make your head
> explode if not carefully studied over the years ;)
>   -- Marcus Meissner

Content-Description: 
/etc/portage/patches/x11-drivers/nvidia-drivers-367.35/nvidia-drivers-367.35-kernel-4.7.0.patch
> diff -purN a/kernel/nvidia-drm/nvidia-drm-fb.c 
> b/kernel/nvidia-drm/nvidia-drm-fb.c
> --- a/kernel/nvidia-drm/nvidia-drm-fb.c   2016-07-12 06:53:45.0 
> +0200
> +++ b/kernel/nvidia-drm/nvidia-drm-fb.c   2016-07-28 09:43:11.494515158 
> +0200
> @@ -32,6 +32,8 @@
>  
>  #include 
>  
> +#include 
> +
>  static void nvidia_framebuffer_destroy(struct drm_framebuffer *fb)
>  {
>  struct nvidia_drm_device *nv_dev = fb->dev->dev_private;
> @@ -114,7 +116,11 @@ static struct drm_framebuffer *internal_
>   * We don't support any planar format, pick up first buffer only.
>   */
>  
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,7,0)
> +gem = drm_gem_object_lookup(file, cmd->handles[0]);
> +#else
>  gem = drm_gem_object_lookup(dev, file, cmd->handles[0]);
> +#endif
>  
>  if (gem == NULL)
>  {
> diff -purN a/kernel/nvidia-drm/nvidia-drm-gem.c 
> b/kernel/nvidia-drm/nvidia-drm-gem.c
> --- a/kernel/nvidia-drm/nvidia-drm-gem.c  2016-07-12 06:53:45.0 
> +0200
> +++ b/kernel/nvidia-drm/nvidia-drm-gem.c  2016-07-28 09:27:24.610637573 
> +0200
> @@ -28,6 +28,8 @@
>  #include "nvidia-drm-ioctl.h"
>  #include "nvidia-drm-gem.h"
>  
> +#include 
> +
>  static struct nvidia_drm_gem_object *nvidia_drm_gem_new
>  (
>  struct drm_file *file_priv,
> @@ -408,7 +410,11 @@ int nvidia_drm_dumb_map_offset
>  
>  mutex_lock(>struct_mutex);
>  
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,7,0)
> +gem = drm_gem_object_lookup(file, handle);
> +#else
>  gem = drm_gem_object_lookup(dev, file, handle);
> +#endif
>  
>  if (gem == NULL)
>  {
> diff -purN a/kernel/nvidia-uvm/uvm_linux.h b/kernel/nvidia-uvm/uvm_linux.h
> --- a/kernel/nvidia-uvm/uvm_linux.h   2016-07-12 06:52:17.0 +0200
> +++ b/kernel/nvidia-uvm/uvm_linux.h   2016-07-28 09:29:21.096322608 +0200
> @@ -554,11 +554,13 @@ static void uvm_init_radix_tree_preloada
>  INIT_RADIX_TREE(tree, GFP_NOWAIT);
>  }
>  
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(4,7,0)
>  static bool radix_tree_empty(struct radix_tree_root *tree)
>  {
>  void *dummy;
>  return radix_tree_gang_lookup(tree, , 0, 1) == 0;
>  }
> +#endif
>  
>  
>  #if !defined(NV_USLEEP_RANGE_PRESENT)


Hi David,

WHOW! Thanks a lot for the patch!

Short qyestion: How can I apply it...I mean...as soon as I do an
emerge, either the original source will be unpacked or my package
will be rejected for being modified an different from the one, which
does not compile...

?

Best regards,
Meino

Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

[David Haller]

Hello,

On Sat, 30 Jul 2016, meino.cra...@gmx.de wrote:
>trying the new kernel linux-4.7 (vanilla, downloaded from
>ftp.kernel.org) with nvidia drivers 
>(Installed versions:  367.35-r1^md(03:00:46 07/30/16)(X driver kms
>multilib uvm -acpi -compat -gtk3 -pax_kernel -static-libs -tools
>-wayland KERNEL="linux -FreeBSD")).
>The kernel compiled fine, the nvidia-drivers does not.
>
>Anuone else with the same problem (read: This has to be
>fixed by nvidia/Linus) or am I the only one (so it is
>my problem...which does not neccessarily imply that I
>know how to fix that ... ;) ???

I've got it working with the attached patch in
/etc/portage/patches/x11-drivers/nvidia-drivers-367.35/

I've no idea though, if I hit that codepath yet. Should work though,
as the patch makes the module use the kernel function and what I read
about radix_tree_gang_lookup() it should be ok this way.

But do not expect anything to work ;)

I'm courious what the official patch will be ;) The first part
(patching kernel/nvidia-drm/nvidia-drm-{fb,gem}.c) I've found online.

HTH,
-dnh

-- 
Please do not think so much about licenses, it will just make your head
explode if not carefully studied over the years ;)
  -- Marcus Meissnerdiff -purN a/kernel/nvidia-drm/nvidia-drm-fb.c b/kernel/nvidia-drm/nvidia-drm-fb.c
--- a/kernel/nvidia-drm/nvidia-drm-fb.c	2016-07-12 06:53:45.0 +0200
+++ b/kernel/nvidia-drm/nvidia-drm-fb.c	2016-07-28 09:43:11.494515158 +0200
@@ -32,6 +32,8 @@
 
 #include 
 
+#include 
+
 static void nvidia_framebuffer_destroy(struct drm_framebuffer *fb)
 {
 struct nvidia_drm_device *nv_dev = fb->dev->dev_private;
@@ -114,7 +116,11 @@ static struct drm_framebuffer *internal_
  * We don't support any planar format, pick up first buffer only.
  */
 
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,7,0)
+gem = drm_gem_object_lookup(file, cmd->handles[0]);
+#else
 gem = drm_gem_object_lookup(dev, file, cmd->handles[0]);
+#endif
 
 if (gem == NULL)
 {
diff -purN a/kernel/nvidia-drm/nvidia-drm-gem.c b/kernel/nvidia-drm/nvidia-drm-gem.c
--- a/kernel/nvidia-drm/nvidia-drm-gem.c	2016-07-12 06:53:45.0 +0200
+++ b/kernel/nvidia-drm/nvidia-drm-gem.c	2016-07-28 09:27:24.610637573 +0200
@@ -28,6 +28,8 @@
 #include "nvidia-drm-ioctl.h"
 #include "nvidia-drm-gem.h"
 
+#include 
+
 static struct nvidia_drm_gem_object *nvidia_drm_gem_new
 (
 struct drm_file *file_priv,
@@ -408,7 +410,11 @@ int nvidia_drm_dumb_map_offset
 
 mutex_lock(>struct_mutex);
 
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,7,0)
+gem = drm_gem_object_lookup(file, handle);
+#else
 gem = drm_gem_object_lookup(dev, file, handle);
+#endif
 
 if (gem == NULL)
 {
diff -purN a/kernel/nvidia-uvm/uvm_linux.h b/kernel/nvidia-uvm/uvm_linux.h
--- a/kernel/nvidia-uvm/uvm_linux.h	2016-07-12 06:52:17.0 +0200
+++ b/kernel/nvidia-uvm/uvm_linux.h	2016-07-28 09:29:21.096322608 +0200
@@ -554,11 +554,13 @@ static void uvm_init_radix_tree_preloada
 INIT_RADIX_TREE(tree, GFP_NOWAIT);
 }
 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,7,0)
 static bool radix_tree_empty(struct radix_tree_root *tree)
 {
 void *dummy;
 return radix_tree_gang_lookup(tree, , 0, 1) == 0;
 }
+#endif
 
 
 #if !defined(NV_USLEEP_RANGE_PRESENT)

Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

[Meino . Cramer]

Andrew Lowe  [16-07-30 08:44]:
> On 30/07/16 14:09, meino.cra...@gmx.de wrote:
> >Hi,
> >
> >thank you for your reply ! :)
> >I have to use the nvidia drivers, because I am using Blender, which
> >renders via CUDA on the GPU...
> >
> >Best regards
> >Meino
> >
> >
> >
> >
> >Jigme Datse Yli-RAsku  [16-07-30 
> >08:04]:
> >>I have an earlier version of the x11-drivers/nvidia-drivers installed 
> >>(361.28), but if I recall, I couldn't get x11 to use them.  Or maybe 
> >>they are already using them, but I don't know it (but I believe I 
> >>couldn't get the tools to recognize that they were being used).  My 
> >>understanding is that using the correct framebuffer drivers is as 
> >>good, if not better than using the official nvidia ones.  But as I 
> >>don't believe I have had the opportunity to do so, I can't really 
> >>say.
> >>
> >>Jigme Datse Yli-Rasku
> >>
> >>On 2016-07-29 22:36, meino.cra...@gmx.de wrote:
> >>>Hi,
> >>>
> >>>trying the new kernel linux-4.7 (vanilla, downloaded from
> >>>ftp.kernel.org) with nvidia drivers
> >>>(Installed versions:  367.35-r1^md(03:00:46 07/30/16)(X driver kms
> >>>multilib uvm -acpi -compat -gtk3 -pax_kernel -static-libs -tools
> >>>-wayland KERNEL="linux -FreeBSD")).
> >>>The kernel compiled fine, the nvidia-drivers does not.
> >>>
> >>>Anuone else with the same problem (read: This has to be
> >>>fixed by nvidia/Linus) or am I the only one (so it is
> >>>my problem...which does not neccessarily imply that I
> >>>know how to fix that ... ;) ???
> >>>
> >>>Best regards
> >>>Meino
> 
>   There is a duplicate definition of a function[1], the kernel 
> apparently has a function and a certain parameter list and then someone 
> at nVidia managed to use the same name but a different parameter list - 
> hence the duplicate definition.
> 
>   I hit this last night, went back one kernel but the latest nvidia 
> driver only works with the 4.7 series kernel so had to go one back with 
> the drivers as well. It's known so just hang tight a day or two and all 
> should be well.
> 
>   Andrew
> 
> [1] From memory at 2am and after a lot of chocolate so could be 
> slightly wrong here
>

Hi,

thanks a lot for the good news!
Fingers crossed...waiting in front of my monitor, compiler engines
started and ready to accelerate...
The compiler will go where no men has ever compiled before...

;)

Best regards,
Meino



 

Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

[Andrew Lowe]

On 30/07/16 14:09, meino.cra...@gmx.de wrote:

Hi,

thank you for your reply ! :)
I have to use the nvidia drivers, because I am using Blender, which
renders via CUDA on the GPU...

Best regards
Meino




Jigme Datse Yli-RAsku  [16-07-30 08:04]:

I have an earlier version of the x11-drivers/nvidia-drivers installed (361.28), 
but if I recall, I couldn't get x11 to use them.  Or maybe they are already 
using them, but I don't know it (but I believe I couldn't get the tools to 
recognize that they were being used).  My understanding is that using the 
correct framebuffer drivers is as good, if not better than using the official 
nvidia ones.  But as I don't believe I have had the opportunity to do so, I 
can't really say.

Jigme Datse Yli-Rasku

On 2016-07-29 22:36, meino.cra...@gmx.de wrote:

Hi,

trying the new kernel linux-4.7 (vanilla, downloaded from
ftp.kernel.org) with nvidia drivers
(Installed versions:  367.35-r1^md(03:00:46 07/30/16)(X driver kms
multilib uvm -acpi -compat -gtk3 -pax_kernel -static-libs -tools
-wayland KERNEL="linux -FreeBSD")).
The kernel compiled fine, the nvidia-drivers does not.

Anuone else with the same problem (read: This has to be
fixed by nvidia/Linus) or am I the only one (so it is
my problem...which does not neccessarily imply that I
know how to fix that ... ;) ???

Best regards
Meino


	There is a duplicate definition of a function[1], the kernel apparently 
has a function and a certain parameter list and then someone at nVidia 
managed to use the same name but a different parameter list - hence the 
duplicate definition.


	I hit this last night, went back one kernel but the latest nvidia 
driver only works with the 4.7 series kernel so had to go one back with 
the drivers as well. It's known so just hang tight a day or two and all 
should be well.


Andrew

[1] From memory at 2am and after a lot of chocolate so could be slightly 
wrong here

Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

[Meino . Cramer]

Hi,

thank you for your reply ! :)
I have to use the nvidia drivers, because I am using Blender, which
renders via CUDA on the GPU...

Best regards
Meino




Jigme Datse Yli-RAsku  [16-07-30 08:04]:
> I have an earlier version of the x11-drivers/nvidia-drivers installed 
> (361.28), but if I recall, I couldn't get x11 to use them.  Or maybe they are 
> already using them, but I don't know it (but I believe I couldn't get the 
> tools to recognize that they were being used).  My understanding is that 
> using the correct framebuffer drivers is as good, if not better than using 
> the official nvidia ones.  But as I don't believe I have had the opportunity 
> to do so, I can't really say.
> 
> Jigme Datse Yli-Rasku
> 
> On 2016-07-29 22:36, meino.cra...@gmx.de wrote:
> > Hi,
> >
> > trying the new kernel linux-4.7 (vanilla, downloaded from
> > ftp.kernel.org) with nvidia drivers
> > (Installed versions:  367.35-r1^md(03:00:46 07/30/16)(X driver kms
> > multilib uvm -acpi -compat -gtk3 -pax_kernel -static-libs -tools
> > -wayland KERNEL="linux -FreeBSD")).
> > The kernel compiled fine, the nvidia-drivers does not.
> >
> > Anuone else with the same problem (read: This has to be
> > fixed by nvidia/Linus) or am I the only one (so it is
> > my problem...which does not neccessarily imply that I
> > know how to fix that ... ;) ???
> >
> > Best regards
> > Meino
> >
> >
> >
> >
> 
> -- 
> Jigme Datse Yli-Rasku
> jigme.da...@datsemultimedia.com (Preferred address for new messages)
> 250-505-6117
> 
> Jigme Datse Yli-Rasku
> PO Box 270
> Rossland, BC V0G 1Y0
> Canada
> 
> ...
> ... This message should be electronically signed, and if the sender ...
> ... has your public key, may also be encrypted. ...
> ... If you have any questions about this, please email, or call. ...
> ... ...
> ... Note, unknown calls likely will go to voicemail. ...
> ... Please leave a message if you get voicemail. ...
> ...
> 
> 
> 
> 

Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

[Jigme Datse Yli-RAsku]

I have an earlier version of the x11-drivers/nvidia-drivers installed (361.28), 
but if I recall, I couldn't get x11 to use them.  Or maybe they are already 
using them, but I don't know it (but I believe I couldn't get the tools to 
recognize that they were being used).  My understanding is that using the 
correct framebuffer drivers is as good, if not better than using the official 
nvidia ones.  But as I don't believe I have had the opportunity to do so, I 
can't really say.

Jigme Datse Yli-Rasku

On 2016-07-29 22:36, meino.cra...@gmx.de wrote:
> Hi,
>
> trying the new kernel linux-4.7 (vanilla, downloaded from
> ftp.kernel.org) with nvidia drivers
> (Installed versions:  367.35-r1^md(03:00:46 07/30/16)(X driver kms
> multilib uvm -acpi -compat -gtk3 -pax_kernel -static-libs -tools
> -wayland KERNEL="linux -FreeBSD")).
> The kernel compiled fine, the nvidia-drivers does not.
>
> Anuone else with the same problem (read: This has to be
> fixed by nvidia/Linus) or am I the only one (so it is
> my problem...which does not neccessarily imply that I
> know how to fix that ... ;) ???
>
> Best regards
> Meino
>
>
>
>

-- 
Jigme Datse Yli-Rasku
jigme.da...@datsemultimedia.com (Preferred address for new messages)
250-505-6117

Jigme Datse Yli-Rasku
PO Box 270
Rossland, BC V0G 1Y0
Canada

...
... This message should be electronically signed, and if the sender ...
... has your public key, may also be encrypted. ...
... If you have any questions about this, please email, or call. ...
... ...
... Note, unknown calls likely will go to voicemail. ...
... Please leave a message if you get voicemail. ...
...

[Solved] Re: [gentoo-user] Nvidia-drivers does not compile anymore

[Jacques Montier]

2016-04-30 17:41 GMT+02:00 Jacques Montier :

> 2016-04-30 15:25 GMT+02:00 Neil Bothwick :
>
>> On Sat, 30 Apr 2016 14:01:12 +0200, Jacques Montier wrote:
>>
>> > You can get the complete log in the attached file
>> > x11-drivers:nvidia-drivers-340.76:20160430-104727.log
>>
>> Which ends with
>>
>>  !!! User patches were applied to this build!
>>
>> Are you applying your own patches? Do you have anything
>> in /etc/portage/patches/x11-drivers?
>>
>> I've been caught by this one before, adding a patch that was necessary
>> for the current version, which then causes newer versions to fail.
>>
>>
>> --
>> Neil Bothwick
>>
>> If I want your opinion, I'll ask you to fill out the necessary form.
>>
>
>
> Thank you Neil,
>
> Yes, i applied the nvidia-drivers-340-76-kernel-4.0.patch (attached file).
> So i tried compiling nvidia-drivers without any patch and it fails with
> the errors :
>
> make[3]: ***
> [/var/tmp/portage/x11-drivers/nvidia-drivers-340.76/work/kernel/nv-pat.o]
> Error 1
> /var/tmp/portage/x11-drivers/nvidia-drivers-340.76/work/kernel/nv-procfs.o]
> Error 1
>
> Complete log in attached file.
>
> Best regards,
>
>
> *--*
> *Jacques*
>

Hello again,

I've found a working nvidia-drivers-340-96 (instead of 340-76) which
compiles fine with the 4.4.6 kernel and without any patch !
So it's solved !

Thanks a lot for your responses.

Best regards,

*--*
*Jacques*

Re: [gentoo-user] Nvidia-drivers does not compile anymore

[Neil Bothwick]

On Sat, 30 Apr 2016 14:01:12 +0200, Jacques Montier wrote:

> You can get the complete log in the attached file
> x11-drivers:nvidia-drivers-340.76:20160430-104727.log

Which ends with

 !!! User patches were applied to this build!

Are you applying your own patches? Do you have anything
in /etc/portage/patches/x11-drivers?

I've been caught by this one before, adding a patch that was necessary
for the current version, which then causes newer versions to fail.


-- 
Neil Bothwick

If I want your opinion, I'll ask you to fill out the necessary form.


pgpT_FpM2jSBF.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Nvidia-drivers does not compile anymore

[Alan McKinnon]

On 30/04/2016 12:52, Jacques Montier wrote:
> Hello all,
> 
> I need nvidia-drivers-340.76 for my Nvidia GeForce GT240 graphic card.
> I use nvidia-drivers-340.76 from a local overlay with the
> nvidia-drivers-340-76-kernel-4.0.patch which works fine with
> gentoo-sources-4.1.15-r1.
> I would like to upgrade to the 4.4.6 kernel.
> Unfortunately, nvidia-drivers-340.76 does not compile anymore.
> I get the errors :
> 
> 3410:make[3]: ***
> [/var/tmp/portage/x11-drivers/nvidia-drivers-340.76/work/kernel/nv-procfs.o]
> Error 1
> 3651:make[2]: ***
> [_module_/var/tmp/portage/x11-drivers/nvidia-drivers-340.76/work/kernel]
> Error 2
> 3654:make[1]: *** [sub-make] Error 2
> 3659:make: *** [nvidia.ko] Error 1
> 
> Any idea ? New patch ?
> 
> Thanks a lot,
> 
> Regards,
> 
> /--/
> /Jacques/


The real error is higher up in the output. Please post it.

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] nvidia-drivers using deprecated...

[Andrew Savchenko]

On Mon, 1 Feb 2016 10:00:40 + Neil Bothwick wrote:
> On Mon, 1 Feb 2016 12:38:45 +0300, Andrew Savchenko wrote:
> 
> > > It's nothing to worry about, deprecated only mean is will be broken at
> > > some time in the future, it still works for now. IMO ebuild QA
> > > messages like this should not be shown to users.  
> > 
> > The idea is that users should ping developers with appropriate bug
> > reports.
> 
> Instead, they ask in here or on the forums. Shouldn't the devs see such
> messages anyway and already be aware of the need to update the ebuild?

They see them, but only when they build packages, e.g. when making
version bump. Eclass may become deprecated after last update of a
package, in such case devs may not see such warning because they
have no need to rebuild the package.

Best regards,
Andrew Savchenko


pgpAB9hzw17ZR.pgp
Description: PGP signature

Re: [gentoo-user] nvidia-drivers using deprecated...

[Neil Bothwick]

On Tue, 9 Feb 2016 11:00:07 +0300, Andrew Savchenko wrote:

> > > The idea is that users should ping developers with appropriate bug
> > > reports.  
> > 
> > Instead, they ask in here or on the forums. Shouldn't the devs see
> > such messages anyway and already be aware of the need to update the
> > ebuild?  
> 
> They see them, but only when they build packages, e.g. when making
> version bump. Eclass may become deprecated after last update of a
> package, in such case devs may not see such warning because they
> have no need to rebuild the package.

It still seems an awfully noisy and inefficient way of doing things.
Can't the developer deprecating the eclass parse the tree for ebuilds
still using it an d ping the developers, this sort of QA stuff should be
automated , not rely on users seeing the messages and reporting rather
than ignoring them.

Anyway, the eclass has only been deprecated, the ebuild devs should be
aware of this long before it is obsoleted.


-- 
Neil Bothwick

"There are no stupid questions, just too many inquisitive idiots."


pgpgOxa7r6HQ3.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] nvidia-drivers using deprecated...

[Andrew Savchenko]

On Mon, 1 Feb 2016 05:04:14 -0500 Philip Webb wrote:
> 160201 Andrew Savchenko wrote:
> > On Mon, 1 Feb 2016 09:03:50 + Neil Bothwick wrote:
> >> On Mon, 1 Feb 2016 05:56:37 +0100, meino.cra...@gmx.de wrote:
> >>> Switching to nvidia OpenCL interface... done
> >>>  * x11-drivers/nvidia-drivers is using the deprecated
> >>> readme.gentoo.eclass.<<>>
> >>>  * Please use readme.gentoo-r1 instead.
> >>> What does the marked line implies? This is an outdated readme?
> >> It's a QA message stating that the ebuild should be updated
> >> to use a newer eclass. The readme.gentoo eclass is used
> >> to generate messages specific to installing the package on Gentoo.
> >> IMO ebuild QA messages like this should not be shown to users.
> > The idea is that users should ping developers
> > with appropriate bug reports.
> 
> However are users supposed to know that ?
> How would they know whether such a bug report really was "appropriate" ?
> 
> Really, Portage output needs a serious re-think (smile).

If emerge outputs something strange for ebuild, this should be
reported as bug, as well as any other weird package behaviour. 

Of course, no one _must_ report this, this is a matter of a good
will.

Best regards,
Andrew Savchenko


pgpHqJ2igRnLX.pgp
Description: PGP signature

Re: [gentoo-user] nvidia-drivers using deprecated...

[Neil Bothwick]

On Mon, 1 Feb 2016 05:56:37 +0100, meino.cra...@gmx.de wrote:

> Switching to nvidia OpenCL interface... done
>  * x11-drivers/nvidia-drivers is using the deprecated
> readme.gentoo.eclass.<<>>
>  * Please use readme.gentoo-r1 instead.

> What does the marked line implies? This is an outdated readme?

It's a QA message stating thst the ebuild should be updated to use a
newer eclass. The readme.gentoo eclass is used to generate messages
specific to installing the package on Gentoo.

It's nothing to worry about, deprecated only mean is will be broken at
some time in the future, it still works for now. IMO ebuild QA messages
like this should not be shown to users.


-- 
Neil Bothwick

Top Oxymorons Number 13: Computer jock


pgpX9a4m0BR3_.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] nvidia-drivers using deprecated...

[Neil Bothwick]

On Mon, 1 Feb 2016 12:38:45 +0300, Andrew Savchenko wrote:

> > It's nothing to worry about, deprecated only mean is will be broken at
> > some time in the future, it still works for now. IMO ebuild QA
> > messages like this should not be shown to users.  
> 
> The idea is that users should ping developers with appropriate bug
> reports.

Instead, they ask in here or on the forums. Shouldn't the devs see such
messages anyway and already be aware of the need to update the ebuild?


-- 
Neil Bothwick

Voting Democrat or Republican is like choosing a cabin in the Titanic.


pgpDFyjAJHRdJ.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] nvidia-drivers using deprecated...

[Philip Webb]

160201 Andrew Savchenko wrote:
> On Mon, 1 Feb 2016 09:03:50 + Neil Bothwick wrote:
>> On Mon, 1 Feb 2016 05:56:37 +0100, meino.cra...@gmx.de wrote:
>>> Switching to nvidia OpenCL interface... done
>>>  * x11-drivers/nvidia-drivers is using the deprecated
>>> readme.gentoo.eclass.<<>>
>>>  * Please use readme.gentoo-r1 instead.
>>> What does the marked line implies? This is an outdated readme?
>> It's a QA message stating that the ebuild should be updated
>> to use a newer eclass. The readme.gentoo eclass is used
>> to generate messages specific to installing the package on Gentoo.
>> IMO ebuild QA messages like this should not be shown to users.
> The idea is that users should ping developers
> with appropriate bug reports.

However are users supposed to know that ?
How would they know whether such a bug report really was "appropriate" ?

Really, Portage output needs a serious re-think (smile).

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

Re: [gentoo-user] nvidia-drivers using deprecated...

[Andrew Savchenko]

On Mon, 1 Feb 2016 09:03:50 + Neil Bothwick wrote:
> On Mon, 1 Feb 2016 05:56:37 +0100, meino.cra...@gmx.de wrote:
> 
> > Switching to nvidia OpenCL interface... done
> >  * x11-drivers/nvidia-drivers is using the deprecated
> > readme.gentoo.eclass.<<>>
> >  * Please use readme.gentoo-r1 instead.
> 
> > What does the marked line implies? This is an outdated readme?
> 
> It's a QA message stating thst the ebuild should be updated to use a
> newer eclass. The readme.gentoo eclass is used to generate messages
> specific to installing the package on Gentoo.
> 
> It's nothing to worry about, deprecated only mean is will be broken at
> some time in the future, it still works for now. IMO ebuild QA messages
> like this should not be shown to users.

The idea is that users should ping developers with appropriate bug
reports.

Best regards,
Andrew Savchenko


pgpBnYPzAwv9I.pgp
Description: PGP signature

Re: [gentoo-user] nvidia-drivers 325.15 removal

[Philip Webb]

131214 »Q« wrote:
 It looks to me as if the removal of nvidia-drivers-325.15 was a mistake
 I run mostly stable amd64.
 I *think* 325.15 was the latest stable

  [I] x11-drivers/nvidia-drivers
 Available versions:  96.43.23^msd 173.14.39^msd 304.116^msd ~304.117^msd 
319.76^msd 331.20^msd {+X acpi custom-cflags gtk multilib pax_kernel (+)tools 
KERNEL=FreeBSD linux}
 Installed versions:  331.20^msd([2013-11-23 15:26:19])(X multilib -acpi 
-pax_kernel -tools KERNEL=linux -FreeBSD)

No problems here.  Have you sync'ed recently ?

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

Re: [gentoo-user] Nvidia drivers and KDE problem

[Paul Hartman]

On Sun, May 26, 2013 at 4:12 AM, Dale rdalek1...@gmail.com wrote:
 The problem.  After I am logged into KDE for a good while, like several
 hours to maybe a day or so, the kicker thingy at the bottom locks up
 tight.  I can't switch desktops, clock stops working, can't click the K
 menu thingy either.  Everything in the kicker thingy is dead as a door
 nail.  I can switch desktops with the keyboard and everything else works
 in KDE just fine.  I can also switch to a console too.  Killing X and
 restarting it fixes it, xdm restart in my case.  I don't have to reload
 drivers or restart the system.  I do go back and downgrade the drivers
 after testing it.

I recently started having trouble where KDE becomes unresponsive at
login and logout for about 20 seconds or more. In my case it was
because of pulseaudio and KDE not getting along together for some
reason. The facts are a bit more nuanced but the work-around that
makes everything normal for me again was to edit
/etc/xdg/autostart/pulseaudio.desktop and add a line which says:
NotShowIn=KDE

Maybe unrelated to your problem but I thought I would mention it just in case.

Re: [gentoo-user] Nvidia drivers and KDE problem

[Dale]

Paul Hartman wrote:
 On Sun, May 26, 2013 at 4:12 AM, Dale rdalek1...@gmail.com wrote:
 The problem.  After I am logged into KDE for a good while, like several
 hours to maybe a day or so, the kicker thingy at the bottom locks up
 tight.  I can't switch desktops, clock stops working, can't click the K
 menu thingy either.  Everything in the kicker thingy is dead as a door
 nail.  I can switch desktops with the keyboard and everything else works
 in KDE just fine.  I can also switch to a console too.  Killing X and
 restarting it fixes it, xdm restart in my case.  I don't have to reload
 drivers or restart the system.  I do go back and downgrade the drivers
 after testing it.
 I recently started having trouble where KDE becomes unresponsive at
 login and logout for about 20 seconds or more. In my case it was
 because of pulseaudio and KDE not getting along together for some
 reason. The facts are a bit more nuanced but the work-around that
 makes everything normal for me again was to edit
 /etc/xdg/autostart/pulseaudio.desktop and add a line which says:
 NotShowIn=KDE

 Maybe unrelated to your problem but I thought I would mention it just in case.




I don't use pulseaudio but thanks for the post tho.  If I did, could
have helped.  :-) 

Also, I still have two posts I have not replied to because it hasn't
locked up yet.  I haven't been able to test the things yet.  If it locks
up again, will reply with the results.

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how 
you interpreted my words!

Re: [gentoo-user] Nvidia drivers and KDE problem

[Fast Turtle]

On Sun, 26 May 2013 07:10:53 -0500
Dale rdalek1...@gmail.com wrote:

 Alan McKinnon wrote:
  On 26/05/2013 13:03, Dale wrote:
  Alan McKinnon wrote:
  On 26/05/2013 11:51, Dale wrote:
 
  What package provides the kicker thingy?  I think in KDE3 it was called
  kicker but it appears to have changed to something else.  Is that
  krunner that has it now?
  Maybe it's time you used the thingy suffix a little less and the real
  names of things a little more :-)
 
  What thing are you asking about? The panel that is usually at the bottom
  and holds the plasma widgets? Or the thin popup you get with Alt-F2?
 
  The panel is called plasma-desktop and comes from 
  kde-base/plasma-workspace
  The popup is krunner and comes from kde-base/krunner
 
  I doubt very much it's a real bug as such in either KDE app (although
  the fix might go in there). It looks much more to me like a side-effect
  of IO blocking - two or more apps are trying to get something done and
  unexpectedly are not getting answers, so they hang around waiting in the
  doorway and get get in the way of everything else. And just for fun,
  video drivers are also trying to get in on the act as they have to deal
  with mouse pointer repaints...
 
  Debugging this one is going to be fun (for peculiar definitions of fun)
 
 
  The thingy is the thing at the bottom where I can switch desktops, click
  the K menu and where my clock is.  I think it was called Kicker in
  KDE3.  KDE4 seems to have changed it but not sure what the new name is. 
  It's a plasma widget called a panel, the only useful thing it does is to
  be a container for other widgets that do useful stuff.
 
  The panel is started by plasma-desktop as one of the standard widgets it
  manages. The idea is to give you stuff on the screen that looks more or
  less like a familiar desktop. Plasma can do other things and give you
  completely different layouts; like for instance not giving you a panel
  at all. This would be useful on a phone with small screen
 
  The whole thing is heavily event based and has to react to a bucket load
  of system events being generated such as what the mouse is doing.
  There's a fantastic number of ways this could go wrong, some might be
  plasma's fault, some might be faults that happen to plasma
 
 
 I'll try to remember to call it a panel thingy then.  ROFL 
 
 
  I hope they fix this thing soon.  If they remove the driver from the
  tree, I'm in a bit of a pickle. 
  No, you won't be. You have the ebuild right now, copy it to your overlay
  and remove becomes something that will not happen
 
 
 
 
 Last time I did that, it didn't work out well.  Actually, it just plain
 didn't work.  May as well tell it like it is.  ;-)  I'll save a copy
 just in case. 
 
 Cross that bridge when I get there I guess. 
 
 Dale
 
 :-)  :-) 
 
 -- 
 I am only responsible for what I said ... Not for what you understood or how 
 you interpreted my words!
 
 
I suspect it's the fact your using the ~arch version of kde (4.10.3) is not 
fully stable yet and yes there be bugs in them valleys. 

Re: [gentoo-user] Nvidia drivers and KDE problem

[Alan McKinnon]

On 26/05/2013 11:12, Dale wrote:
 Howdy,
 
 I been letting portage upgrade nvidia drivers as usual.  Thing is, the
 last two or three drivers seems to cause a issue.  First, versions that
 cause the issue:
 
 =x11-drivers/nvidia-drivers-319.12
 =x11-drivers/nvidia-drivers-319.17
 =x11-drivers/nvidia-drivers-319.23
 
 I'm currently using this one which works fine:
 
 x11-drivers/nvidia-drivers-313.30
 
 This is KDE info:
 
 [IP-] [  ] kde-base/kdelibs-4.10.3-r2
 
 Video card info:
 
 01:00.0 VGA compatible controller: NVIDIA Corporation GT216 [GeForce GT
 220] (rev a2) (prog-if 00 [VGA controller])
 Subsystem: NVIDIA Corporation Device 069a
 Flags: bus master, fast devsel, latency 0, IRQ 18
 Memory at fb00 (32-bit, non-prefetchable) [size=16M]
 Memory at c000 (64-bit, prefetchable) [size=256M]
 Memory at de00 (64-bit, prefetchable) [size=32M]
 I/O ports at ef00 [size=128]
 [virtual] Expansion ROM at d000 [disabled] [size=512K]
 Capabilities: [60] Power Management version 3
 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
 Capabilities: [78] Express Endpoint, MSI 00
 Capabilities: [b4] Vendor Specific Information: Len=14 ?
 Capabilities: [100] Virtual Channel
 Capabilities: [128] Power Budgeting ?
 Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1
 Len=024 ?
 Kernel driver in use: nvidia
 Kernel modules: nvidia
 
 
 The problem.  After I am logged into KDE for a good while, like several
 hours to maybe a day or so, the kicker thingy at the bottom locks up
 tight.  I can't switch desktops, clock stops working, can't click the K
 menu thingy either.  Everything in the kicker thingy is dead as a door
 nail.  I can switch desktops with the keyboard and everything else works
 in KDE just fine.  I can also switch to a console too.  Killing X and
 restarting it fixes it, xdm restart in my case.  I don't have to reload
 drivers or restart the system.  I do go back and downgrade the drivers
 after testing it.
 
 So, is this a nvidia bug, KDE bug or is it something else?  Since it
 works when I go back a version of nvidia, it looks like nvidia.  Think
 is, it only affects KDE and nothing else.  Is it possible that my card
 is not supposed to use the 319.* series of drivers?  The versions that
 don't work are all 319.* series. 


I get a similar issue, my video card is an ATI and I use the radeon drivers.

Same symptom as you - plasma stops updating it's widgets like clocks and
stops responding to the mouse. Keyboard works.

In my case, it's usually linked to nfs and smb mounts that went away
(eg, if I forget to umount my NFS media server at home and go to work)
which indicates a blocking issue somehow. I've read many reports on the
internet that krunner is somehow involved, so that might be a good
starting point for investigation. krunner is the thing you get in KDE
when typing Alt-F2


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Nvidia drivers and KDE problem

[Dale]

Alan McKinnon wrote:
 I get a similar issue, my video card is an ATI and I use the radeon
 drivers. Same symptom as you - plasma stops updating it's widgets like
 clocks and stops responding to the mouse. Keyboard works. In my case,
 it's usually linked to nfs and smb mounts that went away (eg, if I
 forget to umount my NFS media server at home and go to work) which
 indicates a blocking issue somehow. I've read many reports on the
 internet that krunner is somehow involved, so that might be a good
 starting point for investigation. krunner is the thing you get in KDE
 when typing Alt-F2 

So this may not be a nvidia issue at all since you get the same with a
ATI card.  Right? 

What package provides the kicker thingy?  I think in KDE3 it was called
kicker but it appears to have changed to something else.  Is that
krunner that has it now?

Thanks.

Dale 

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how 
you interpreted my words!

Re: [gentoo-user] Nvidia drivers and KDE problem

[Alan McKinnon]

On 26/05/2013 11:51, Dale wrote:
 Alan McKinnon wrote:
 I get a similar issue, my video card is an ATI and I use the radeon
 drivers. Same symptom as you - plasma stops updating it's widgets like
 clocks and stops responding to the mouse. Keyboard works. In my case,
 it's usually linked to nfs and smb mounts that went away (eg, if I
 forget to umount my NFS media server at home and go to work) which
 indicates a blocking issue somehow. I've read many reports on the
 internet that krunner is somehow involved, so that might be a good
 starting point for investigation. krunner is the thing you get in KDE
 when typing Alt-F2 
 
 So this may not be a nvidia issue at all since you get the same with a
 ATI card.  Right? 

yes


 
 What package provides the kicker thingy?  I think in KDE3 it was called
 kicker but it appears to have changed to something else.  Is that
 krunner that has it now?

Maybe it's time you used the thingy suffix a little less and the real
names of things a little more :-)

What thing are you asking about? The panel that is usually at the bottom
and holds the plasma widgets? Or the thin popup you get with Alt-F2?

The panel is called plasma-desktop and comes from kde-base/plasma-workspace
The popup is krunner and comes from kde-base/krunner

I doubt very much it's a real bug as such in either KDE app (although
the fix might go in there). It looks much more to me like a side-effect
of IO blocking - two or more apps are trying to get something done and
unexpectedly are not getting answers, so they hang around waiting in the
doorway and get get in the way of everything else. And just for fun,
video drivers are also trying to get in on the act as they have to deal
with mouse pointer repaints...

Debugging this one is going to be fun (for peculiar definitions of fun)


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Nvidia drivers and KDE problem

[Dale]

Alan McKinnon wrote:
 On 26/05/2013 11:51, Dale wrote:

 What package provides the kicker thingy?  I think in KDE3 it was called
 kicker but it appears to have changed to something else.  Is that
 krunner that has it now?
 Maybe it's time you used the thingy suffix a little less and the real
 names of things a little more :-)

 What thing are you asking about? The panel that is usually at the bottom
 and holds the plasma widgets? Or the thin popup you get with Alt-F2?

 The panel is called plasma-desktop and comes from kde-base/plasma-workspace
 The popup is krunner and comes from kde-base/krunner

 I doubt very much it's a real bug as such in either KDE app (although
 the fix might go in there). It looks much more to me like a side-effect
 of IO blocking - two or more apps are trying to get something done and
 unexpectedly are not getting answers, so they hang around waiting in the
 doorway and get get in the way of everything else. And just for fun,
 video drivers are also trying to get in on the act as they have to deal
 with mouse pointer repaints...

 Debugging this one is going to be fun (for peculiar definitions of fun)



The thingy is the thing at the bottom where I can switch desktops, click
the K menu and where my clock is.  I think it was called Kicker in
KDE3.  KDE4 seems to have changed it but not sure what the new name is. 

I hope they fix this thing soon.  If they remove the driver from the
tree, I'm in a bit of a pickle. 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how 
you interpreted my words!

Re: [gentoo-user] Nvidia drivers and KDE problem

[Alan McKinnon]

On 26/05/2013 13:03, Dale wrote:
 Alan McKinnon wrote:
 On 26/05/2013 11:51, Dale wrote:

 What package provides the kicker thingy?  I think in KDE3 it was called
 kicker but it appears to have changed to something else.  Is that
 krunner that has it now?
 Maybe it's time you used the thingy suffix a little less and the real
 names of things a little more :-)

 What thing are you asking about? The panel that is usually at the bottom
 and holds the plasma widgets? Or the thin popup you get with Alt-F2?

 The panel is called plasma-desktop and comes from kde-base/plasma-workspace
 The popup is krunner and comes from kde-base/krunner

 I doubt very much it's a real bug as such in either KDE app (although
 the fix might go in there). It looks much more to me like a side-effect
 of IO blocking - two or more apps are trying to get something done and
 unexpectedly are not getting answers, so they hang around waiting in the
 doorway and get get in the way of everything else. And just for fun,
 video drivers are also trying to get in on the act as they have to deal
 with mouse pointer repaints...

 Debugging this one is going to be fun (for peculiar definitions of fun)


 
 The thingy is the thing at the bottom where I can switch desktops, click
 the K menu and where my clock is.  I think it was called Kicker in
 KDE3.  KDE4 seems to have changed it but not sure what the new name is. 

It's a plasma widget called a panel, the only useful thing it does is to
be a container for other widgets that do useful stuff.

The panel is started by plasma-desktop as one of the standard widgets it
manages. The idea is to give you stuff on the screen that looks more or
less like a familiar desktop. Plasma can do other things and give you
completely different layouts; like for instance not giving you a panel
at all. This would be useful on a phone with small screen

The whole thing is heavily event based and has to react to a bucket load
of system events being generated such as what the mouse is doing.
There's a fantastic number of ways this could go wrong, some might be
plasma's fault, some might be faults that happen to plasma

 
 I hope they fix this thing soon.  If they remove the driver from the
 tree, I'm in a bit of a pickle. 

No, you won't be. You have the ebuild right now, copy it to your overlay
and remove becomes something that will not happen



-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Nvidia drivers and KDE problem

[Dale]

Alan McKinnon wrote:
 On 26/05/2013 13:03, Dale wrote:
 Alan McKinnon wrote:
 On 26/05/2013 11:51, Dale wrote:

 What package provides the kicker thingy?  I think in KDE3 it was called
 kicker but it appears to have changed to something else.  Is that
 krunner that has it now?
 Maybe it's time you used the thingy suffix a little less and the real
 names of things a little more :-)

 What thing are you asking about? The panel that is usually at the bottom
 and holds the plasma widgets? Or the thin popup you get with Alt-F2?

 The panel is called plasma-desktop and comes from kde-base/plasma-workspace
 The popup is krunner and comes from kde-base/krunner

 I doubt very much it's a real bug as such in either KDE app (although
 the fix might go in there). It looks much more to me like a side-effect
 of IO blocking - two or more apps are trying to get something done and
 unexpectedly are not getting answers, so they hang around waiting in the
 doorway and get get in the way of everything else. And just for fun,
 video drivers are also trying to get in on the act as they have to deal
 with mouse pointer repaints...

 Debugging this one is going to be fun (for peculiar definitions of fun)


 The thingy is the thing at the bottom where I can switch desktops, click
 the K menu and where my clock is.  I think it was called Kicker in
 KDE3.  KDE4 seems to have changed it but not sure what the new name is. 
 It's a plasma widget called a panel, the only useful thing it does is to
 be a container for other widgets that do useful stuff.

 The panel is started by plasma-desktop as one of the standard widgets it
 manages. The idea is to give you stuff on the screen that looks more or
 less like a familiar desktop. Plasma can do other things and give you
 completely different layouts; like for instance not giving you a panel
 at all. This would be useful on a phone with small screen

 The whole thing is heavily event based and has to react to a bucket load
 of system events being generated such as what the mouse is doing.
 There's a fantastic number of ways this could go wrong, some might be
 plasma's fault, some might be faults that happen to plasma


I'll try to remember to call it a panel thingy then.  ROFL 


 I hope they fix this thing soon.  If they remove the driver from the
 tree, I'm in a bit of a pickle. 
 No, you won't be. You have the ebuild right now, copy it to your overlay
 and remove becomes something that will not happen




Last time I did that, it didn't work out well.  Actually, it just plain
didn't work.  May as well tell it like it is.  ;-)  I'll save a copy
just in case. 

Cross that bridge when I get there I guess. 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how 
you interpreted my words!

Re: [gentoo-user] Nvidia drivers and KDE problem

[Volker Armin Hemmann]

Am 26.05.2013 11:12, schrieb Dale:
 Howdy,

 I been letting portage upgrade nvidia drivers as usual.  Thing is, the
 last two or three drivers seems to cause a issue.  First, versions that
 cause the issue:

 =x11-drivers/nvidia-drivers-319.12
 =x11-drivers/nvidia-drivers-319.17
 =x11-drivers/nvidia-drivers-319.23

 I'm currently using this one which works fine:

 x11-drivers/nvidia-drivers-313.30

 This is KDE info:

 [IP-] [  ] kde-base/kdelibs-4.10.3-r2

 Video card info:

 01:00.0 VGA compatible controller: NVIDIA Corporation GT216 [GeForce GT
 220] (rev a2) (prog-if 00 [VGA controller])
 Subsystem: NVIDIA Corporation Device 069a
 Flags: bus master, fast devsel, latency 0, IRQ 18
 Memory at fb00 (32-bit, non-prefetchable) [size=16M]
 Memory at c000 (64-bit, prefetchable) [size=256M]
 Memory at de00 (64-bit, prefetchable) [size=32M]
 I/O ports at ef00 [size=128]
 [virtual] Expansion ROM at d000 [disabled] [size=512K]
 Capabilities: [60] Power Management version 3
 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
 Capabilities: [78] Express Endpoint, MSI 00
 Capabilities: [b4] Vendor Specific Information: Len=14 ?
 Capabilities: [100] Virtual Channel
 Capabilities: [128] Power Budgeting ?
 Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1
 Len=024 ?
 Kernel driver in use: nvidia
 Kernel modules: nvidia


 The problem.  After I am logged into KDE for a good while, like several
 hours to maybe a day or so, the kicker thingy at the bottom locks up
 tight.  I can't switch desktops, clock stops working, can't click the K
 menu thingy either.  Everything in the kicker thingy is dead as a door
 nail.  I can switch desktops with the keyboard and everything else works
 in KDE just fine.  I can also switch to a console too.  Killing X and
 restarting it fixes it, xdm restart in my case.  I don't have to reload
 drivers or restart the system.  I do go back and downgrade the drivers
 after testing it.

 So, is this a nvidia bug, KDE bug or is it something else?  Since it
 works when I go back a version of nvidia, it looks like nvidia.  Think
 is, it only affects KDE and nothing else.  Is it possible that my card
 is not supposed to use the 319.* series of drivers?  The versions that
 don't work are all 319.* series. 

 Thoughts? 

 Dale

 :-)  :-) 


next time as root do:
killall -9 krunner
killall -9 plasma-desktop

Re: [gentoo-user] nvidia-drivers fail to determine kernel version

[Alexandre Domi]

Note sure it's something wrong that you did, but that sure is strange... It
usually happens when switching from 3.x to 3.y kernel version...
When you're trying to emerge nvidia-drivers, are you running the recently
compiled kernel?


2013/2/5 meino.cra...@gmx.de

 Hi,

 when using vanilla kernel 3.7.5 (appropiate kernel headers installed)
 emergeing nvidia-drivers 313.18 works fine.
 As soon vanilla kernel 3.7.6 are installed the emerge process fails
 because the kernel version couldnt be determined.

 Both times /usr/src/linux symlinks to the according kernel sources.

 What did I wrong? How can I fix that?

 Thank you very much in advance for any help!
 Best regards,
 mcc

Re: [gentoo-user] nvidia-drivers fail to determine kernel version

[meino . cramer]

Hi Alexandre,

thanks for your reply! :)

Both kernels were compiled the same way prior to emergeing the
nvidia-drivers. In both cases the symlink /usr/src/linux points to
the correct kernel sources...
I also to booted into the kernel for which I want to emerge the
drivers which doesnt make a difference...

What else may be the reason for that?

Best regards,
mcc






Alexandre Domi crok.r...@gmail.com [13-02-05 16:04]:
 Note sure it's something wrong that you did, but that sure is strange... It
 usually happens when switching from 3.x to 3.y kernel version...
 When you're trying to emerge nvidia-drivers, are you running the recently
 compiled kernel?
 
 
 2013/2/5 meino.cra...@gmx.de
 
  Hi,
 
  when using vanilla kernel 3.7.5 (appropiate kernel headers installed)
  emergeing nvidia-drivers 313.18 works fine.
  As soon vanilla kernel 3.7.6 are installed the emerge process fails
  because the kernel version couldnt be determined.
 
  Both times /usr/src/linux symlinks to the according kernel sources.
 
  What did I wrong? How can I fix that?
 
  Thank you very much in advance for any help!
  Best regards,
  mcc
 
 
 
 
 

Re: [gentoo-user] nvidia-drivers fail to determine kernel version

[Dale]

meino.cra...@gmx.de wrote:
 Hi Alexandre,

 thanks for your reply! :)

 Both kernels were compiled the same way prior to emergeing the
 nvidia-drivers. In both cases the symlink /usr/src/linux points to
 the correct kernel sources...
 I also to booted into the kernel for which I want to emerge the
 drivers which doesnt make a difference...

 What else may be the reason for that?

 Best regards,
 mcc



Bug maybe?  I would search the forums then B.G.O. and see if it has been
reported there. 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how 
you interpreted my words!

Re: [gentoo-user] nvidia-drivers fail to determine kernel version

[Alexandre Domi]

Hi,

It could be because it's hard coded in the nvidia sh script...
It used to be like that, don't know if it's still the case...
Le 5 févr. 2013 16:32, meino.cra...@gmx.de a écrit :

 Hi Alexandre,

 thanks for your reply! :)

 Both kernels were compiled the same way prior to emergeing the
 nvidia-drivers. In both cases the symlink /usr/src/linux points to
 the correct kernel sources...
 I also to booted into the kernel for which I want to emerge the
 drivers which doesnt make a difference...

 What else may be the reason for that?

 Best regards,
 mcc






 Alexandre Domi crok.r...@gmail.com [13-02-05 16:04]:
  Note sure it's something wrong that you did, but that sure is strange...
 It
  usually happens when switching from 3.x to 3.y kernel version...
  When you're trying to emerge nvidia-drivers, are you running the recently
  compiled kernel?
 
 
  2013/2/5 meino.cra...@gmx.de
 
   Hi,
  
   when using vanilla kernel 3.7.5 (appropiate kernel headers installed)
   emergeing nvidia-drivers 313.18 works fine.
   As soon vanilla kernel 3.7.6 are installed the emerge process fails
   because the kernel version couldnt be determined.
  
   Both times /usr/src/linux symlinks to the according kernel sources.
  
   What did I wrong? How can I fix that?
  
   Thank you very much in advance for any help!
   Best regards,
   mcc
  
  
  
  
  

Re: [gentoo-user] nvidia-drivers-304.64 build failure against vanilla linux-3.7.4

[Raffaele BELARDI]

On 01/27/2013 01:06 AM, staticsafe wrote:
 I just grabbed vanilla 3.7.4 from kernel.org, the kernel build itself
 went fine but when I did a modules-rebuild, the nvidia module failed to
 build. As requested by the error message:

I had the same problem, I had success with this:

https://devtalk.nvidia.com/default/topic/525699/linux/nvidia-linux-3-7-patch-fix/

I applied the patch and also had to create the link to version.h as
suggested towards the end of the page.
That was with gentoo-sources-3.7.4-something and nvidia-drivers-304.64
on ~amd64.

raf

Re: [gentoo-user] Nvidia-drivers + kernel 3.4

[microcai]

don't, use 295.59 :)

2012/6/15 Philip Webb purs...@ca.inter.net

 I haven't seen any mention of the problem here,
 but after installing Kernel 3.4 , Nvidia-drivers 295.49 wouldn't compile.
 The solution (via Google + Launchpad bugzilla) is to copy  4  header files
 from  /usr/src/linux/arch/arm/include/asm  to  -/-/-/-/x86/include/asm :
  system.h compiler.h system_info.h system_misc.h .

 Also the Ethernet kernel config lines have changed a bit
  I had to ask explicitly for my mobo's version with 'r8169'.

 HTH others

 --
 ,,
 SUPPORT ___//___,   Philip Webb
 ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
 TRANSIT`-O--O---'   purslowatchassdotutorontodotca

Re: [gentoo-user] Nvidia-drivers + kernel 3.4

[Philip Webb]

120615 microcai wrote:
 2012/6/15 Philip Webb purs...@ca.inter.net
 after installing Kernel 3.4 , Nvidia-drivers 295.49 wouldn't compile.
 The solution (via Google + Launchpad bugzilla) is to copy  4  header files
 from  /usr/src/linux/arch/arm/include/asm  to  -/-/-/-/x86/include/asm :
  system.h compiler.h system_info.h system_misc.h .
 Also the Ethernet kernel config lines have changed a bit
  I had to ask explicitly for my mobo's version with 'r8169'.
 don't, use 295.59 :)

Do you mean Don't use 295.59 or Don't use 295.49, use 295.59 ?
In any case, do you mean '295.49' or '295.53', the only versions available ?

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

Re: [gentoo-user] nvidia-drivers vs. nouveau

[Canek Peláez Valdés]

On Wed, Apr 11, 2012 at 4:36 PM, Canek Peláez Valdés can...@gmail.com wrote:
 On Wed, Apr 11, 2012 at 4:30 PM, Stefan G. Weichinger li...@xunil.at wrote:
 Am 11.04.2012 23:16, schrieb ny6...@gmail.com:

 I use the nouveau drivers because they update themselves when you update the
 kernel, and there's less work involved in keeping everything up to date. But
 I can't comment on the nvidia drivers since I've never tried them. Nouveau
 works well enough for me.

 See my other reply: Nikos hit the point.

 I actually changed to nouveau because the desktop performance of
 nvidia-drivers sucked at the time. I still use nvidia-drivers in my
 media center (because of VDPAU), but in my desktop I changed about
 year and a half ago, and I'm pretty happy with it.

 Before that, I used nvidia-drivers for many years, and it was always
 full of ups and downs; some versions worked great, others were barely
 usable. The nouveau drivers have been consistently good, even for
 small 3D use (things like Blender).

 If you don't use (modern) games, I highly recommend the nouveau
 drivers. For a modern desktop they work great.

Relevant to the thread, I believe:

Open-Source NVIDIA Driver Approaches Stable State
http://www.phoronix.com/scan.php?page=articleitem=nouveau_linux_stablenum=1

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] nvidia-drivers vs. nouveau

[Alan McKinnon]

On Wed, 11 Apr 2012 16:36:06 -0500
Canek Peláez Valdés can...@gmail.com wrote:

 On Wed, Apr 11, 2012 at 4:30 PM, Stefan G. Weichinger
 li...@xunil.at wrote:
  Am 11.04.2012 23:16, schrieb ny6...@gmail.com:
 
  I use the nouveau drivers because they update themselves when you
  update the kernel, and there's less work involved in keeping
  everything up to date. But I can't comment on the nvidia drivers
  since I've never tried them. Nouveau works well enough for me.
 
  See my other reply: Nikos hit the point.
 
 I actually changed to nouveau because the desktop performance of
 nvidia-drivers sucked at the time. I still use nvidia-drivers in my
 media center (because of VDPAU), but in my desktop I changed about
 year and a half ago, and I'm pretty happy with it.
 
 Before that, I used nvidia-drivers for many years, and it was always
 full of ups and downs; some versions worked great, others were barely
 usable. The nouveau drivers have been consistently good, even for
 small 3D use (things like Blender).
 
 If you don't use (modern) games, I highly recommend the nouveau
 drivers. For a modern desktop they work great.

I'll second that. I don't need blazing fast 3D performance, I do need
stable drivers that keep pace with kernel releases. I got tired of
having to remember to fully test nvidia-drivers every time I did a
kernel upgrade so switched to nouveau.

That was the previous laptop. This current one has an ATI card and I
use ati drivers rather than fglrx for the same reason.

The other killer was that I could never get nvidia-drivers to deal with
a multi-monitor setup in any kind of sane fashion. nVidia does do
multi-monitor, it just wants to present it in a way that made no sense
to me at all. Even something as simple as unplugging my desk monitor
and going to a meeting room to do a presentation on the projector
required an X restart.

-- 
Alan McKinnnon
alan.mckin...@gmail.com

Re: [gentoo-user] nvidia-drivers vs. nouveau

[Helmut Jarausch]

On 04/12/2012 09:09:16 AM, Alan McKinnon wrote:

That was the previous laptop. This current one has an ATI card and I
use ati drivers rather than fglrx for the same reason.


What's the difference (in performance) between fglrx and xf86-video-ati  
?

Do both of them support GPU usage?

Thanks for some info,
Helmut.

Re: [gentoo-user] nvidia-drivers vs. nouveau

[Alan McKinnon]

On Thu, 12 Apr 2012 10:06:17 +0200
Helmut Jarausch jarau...@igpm.rwth-aachen.de wrote:

 On 04/12/2012 09:09:16 AM, Alan McKinnon wrote:
  That was the previous laptop. This current one has an ATI card and I
  use ati drivers rather than fglrx for the same reason.
 
 What's the difference (in performance) between fglrx and
 xf86-video-ati ?
 Do both of them support GPU usage?

To be truthful, I really don't know the details.

My major overriding need is for the video driver to be in sync with the
rest of my software at all times so that portage can just do the right
thing (exactly like all the other drivers I use).

As long as the right pixels light up at the right time on the screen
and X does not crash, then I do not care about super video performance.

The open source ATI drivers completely fulfil my needs.


-- 
Alan McKinnnon
alan.mckin...@gmail.com

Re: [gentoo-user] nvidia-drivers vs. nouveau

[ny6p01]

On Thu, Apr 12, 2012 at 09:09:16AM +0200, Alan McKinnon wrote:
 On Wed, 11 Apr 2012 16:36:06 -0500
 Canek Pel?ez Vald?s can...@gmail.com wrote:
 
  On Wed, Apr 11, 2012 at 4:30 PM, Stefan G. Weichinger
  li...@xunil.at wrote:
   Am 11.04.2012 23:16, schrieb ny6...@gmail.com:
  
   I use the nouveau drivers because they update themselves when you
   update the kernel, and there's less work involved in keeping
   everything up to date. But I can't comment on the nvidia drivers
   since I've never tried them. Nouveau works well enough for me.
  
   See my other reply: Nikos hit the point.
  
  I actually changed to nouveau because the desktop performance of
  nvidia-drivers sucked at the time. I still use nvidia-drivers in my
  media center (because of VDPAU), but in my desktop I changed about
  year and a half ago, and I'm pretty happy with it.
  
  Before that, I used nvidia-drivers for many years, and it was always
  full of ups and downs; some versions worked great, others were barely
  usable. The nouveau drivers have been consistently good, even for
  small 3D use (things like Blender).
  
  If you don't use (modern) games, I highly recommend the nouveau
  drivers. For a modern desktop they work great.
 
 I'll second that. I don't need blazing fast 3D performance, I do need
 stable drivers that keep pace with kernel releases. I got tired of
 having to remember to fully test nvidia-drivers every time I did a
 kernel upgrade so switched to nouveau.
 
 That was the previous laptop. This current one has an ATI card and I
 use ati drivers rather than fglrx for the same reason.
 
 The other killer was that I could never get nvidia-drivers to deal with
 a multi-monitor setup in any kind of sane fashion. nVidia does do
 multi-monitor, it just wants to present it in a way that made no sense
 to me at all. Even something as simple as unplugging my desk monitor
 and going to a meeting room to do a presentation on the projector
 required an X restart.

Yes, nouveau is very adept at juggling monitors. 

Terry

Re: [gentoo-user] nvidia-drivers vs. nouveau

[Paul Hartman]

On Thu, Apr 12, 2012 at 3:06 AM, Helmut Jarausch
jarau...@igpm.rwth-aachen.de wrote:
 What's the difference (in performance) between fglrx and xf86-video-ati ?

My experience with my first and only ATI video card (a Mobility Radeon
9700), is that the opensource drivers for my chipset are basically
useless for anything 3D. Slow, corrupt graphics, freezing the
computer. The ati-drivers/fglrx was several times faster and much more
stable.

Unfortunately, ATI removed support for my card from their drivers in
2009, leaving me no choice but to use the OSS driver unless I want to
downgrade my system to use kernel 2.6.28 or earlier.

Re: [gentoo-user] nvidia-drivers vs. nouveau

[ny6p01]

On Wed, Apr 11, 2012 at 10:38:50PM +0200, Stefan G. Weichinger wrote:
 
 Just being curious:
 
 I use my main workstation primarily for work.
 
 Ok, gnome3 needs some graphic acceleration, aside from that I can only
 think of the occasional mythfrontend running on my desktop.
 
 I consider to chose nouveau drivers instead of the nvidia-drivers-package.
 
 What are your recommendations?
 
 Thanks, Stefan
 

I use the nouveau drivers because they update themselves when you update the
kernel, and there's less work involved in keeping everything up to date. But
I can't comment on the nvidia drivers since I've never tried them. Nouveau
works well enough for me.

Terry

Re: [gentoo-user] nvidia-drivers vs. nouveau

[Alecks Gates]

The only reason I really use nvidia-drivers is because of VDPAU.  Otherwise
I can't watch HD videos on my media center.  VDPAU works great, and I hope
nouveau supports it or something equivalent eventually.  Mythtv probably
uses it, though that's just a guess.

Alecks Gates, sent from Android on an HTC G2
On Apr 11, 2012 5:17 PM, ny6...@gmail.com wrote:

 On Wed, Apr 11, 2012 at 10:38:50PM +0200, Stefan G. Weichinger wrote:
 
  Just being curious:
 
  I use my main workstation primarily for work.
 
  Ok, gnome3 needs some graphic acceleration, aside from that I can only
  think of the occasional mythfrontend running on my desktop.
 
  I consider to chose nouveau drivers instead of the
 nvidia-drivers-package.
 
  What are your recommendations?
 
  Thanks, Stefan
 

 I use the nouveau drivers because they update themselves when you update
 the
 kernel, and there's less work involved in keeping everything up to date.
 But
 I can't comment on the nvidia drivers since I've never tried them. Nouveau
 works well enough for me.

 Terry

Re: [gentoo-user] nvidia-drivers vs. nouveau

[Stefan G. Weichinger]

Am 11.04.2012 23:16, schrieb ny6...@gmail.com:

 I use the nouveau drivers because they update themselves when you update the
 kernel, and there's less work involved in keeping everything up to date. But
 I can't comment on the nvidia drivers since I've never tried them. Nouveau
 works well enough for me.

See my other reply: Nikos hit the point.

S

Re: [gentoo-user] nvidia-drivers vs. nouveau

[Canek Peláez Valdés]

On Wed, Apr 11, 2012 at 4:30 PM, Stefan G. Weichinger li...@xunil.at wrote:
 Am 11.04.2012 23:16, schrieb ny6...@gmail.com:

 I use the nouveau drivers because they update themselves when you update the
 kernel, and there's less work involved in keeping everything up to date. But
 I can't comment on the nvidia drivers since I've never tried them. Nouveau
 works well enough for me.

 See my other reply: Nikos hit the point.

I actually changed to nouveau because the desktop performance of
nvidia-drivers sucked at the time. I still use nvidia-drivers in my
media center (because of VDPAU), but in my desktop I changed about
year and a half ago, and I'm pretty happy with it.

Before that, I used nvidia-drivers for many years, and it was always
full of ups and downs; some versions worked great, others were barely
usable. The nouveau drivers have been consistently good, even for
small 3D use (things like Blender).

If you don't use (modern) games, I highly recommend the nouveau
drivers. For a modern desktop they work great.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] NVidia-drivers: Sync problem ???

[Dale]

meino.cra...@gmx.de wrote:

Hi,

For my MSI GT430 (nvidia) graphics card I am using
the x11-drivers/nvidia-drivers-260.19.29.

But there seems to be something wrong:
When playing videos with faster movements
I see heavy distortions around these parts
of the screen.

Previously I fixed this for another nvidia
card by enabling different sync options
in the nvidia-setting dialog and was happy
that these distortion dont come back, when
I switched to this newer card.

Now: There're back despite my hopes...

I started glxgears and got this output
on the console:

 Running synchronized to the vertical refresh.  The framerate should be
 approximately the same as the monitor refresh rate.
 74062 frames in 5.0 seconds = 14812.268 FPS
 77502 frames in 5.0 seconds = 15500.350 FPS
 XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server 
:0.0
 after 57 requests (57 known processed) with 0 events remaining.


The second sentence say, that there is a syncing active and will get
the refresh rate of the monitor (a LCD screen) back. This wouild be
around 60Hz as far as I know.

And then, the measurements show 15500.350 FPS...

Which slightl above 60 Hz

To sync or not to sync, that seems to be the question...

By the way: Distortion can be watched as when using mplayer
as with vlc. I recompiled both just to get sure, but it does
not help. The machine is definetly fast enough to play videos
(AMD Phenom II X6 1090T)

How can I get back the undistorted screen?

Thank you very much in advance for any help !
Best regards,
mcc

   


I would check the log files and see if they shed some light on this.  I 
would check dmesg, messages and Xorg.0.log as well.  The last one may 
show the best clues.  If nothing there points to anything good, I would 
post the xorg.conf and Xorg.0.log as attachments.


I have a CPU like yours except 4 core and a little GT-220 card, wimpy 
compared to yours.  What you see about the refresh rates is displayed on 
my machine too.  The last part appears because you hit the close window 
X instead of doing a ctrl c to stop glxgears.  If you start glxgears and 
do a ctrl c to stop it, the last part won't be there.   I mention this 
because that *may* have nothing to do with the problem you are having.  
This is what happens when I run glxgears:


fireball ~ # glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
27770 frames in 5.0 seconds = 5553.918 FPS
9783 frames in 5.0 seconds = 1955.847 FPS
3084 frames in 5.0 seconds = 616.716 FPS
3085 frames in 5.0 seconds = 616.942 FPS
3105 frames in 5.0 seconds = 620.981 FPS
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server 
:0.0

  after 42 requests (42 known processed) with 0 events remaining.
fireball ~ # glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
14932 frames in 5.0 seconds = 2985.639 FPS
3011 frames in 5.0 seconds = 602.125 FPS
^C
fireball ~ #

The last one was stopped with a ctrl c as you can see.  The first was 
closed by hitting the close window button.


If this doesn't help, at least you know to post the files so we can look 
them over.  Maybe someone will notice something out of place.


Dale

:-)  :-)

Re: [gentoo-user] NVidia-drivers: Sync problem ???

[meino . cramer]

Dale rdalek1...@gmail.com [10-12-18 09:52]:
 meino.cra...@gmx.de wrote:
 Hi,
 
 For my MSI GT430 (nvidia) graphics card I am using
 the x11-drivers/nvidia-drivers-260.19.29.
 
 But there seems to be something wrong:
 When playing videos with faster movements
 I see heavy distortions around these parts
 of the screen.
 
 Previously I fixed this for another nvidia
 card by enabling different sync options
 in the nvidia-setting dialog and was happy
 that these distortion dont come back, when
 I switched to this newer card.
 
 Now: There're back despite my hopes...
 
 I started glxgears and got this output
 on the console:
 
  Running synchronized to the vertical refresh.  The framerate 
 should be
  approximately the same as the monitor refresh rate.
  74062 frames in 5.0 seconds = 14812.268 FPS
  77502 frames in 5.0 seconds = 15500.350 FPS
  XIO:  fatal IO error 11 (Resource temporarily unavailable) on X 
 server :0.0
  after 57 requests (57 known processed) with 0 events 
 remaining.
 
 
 The second sentence say, that there is a syncing active and will get
 the refresh rate of the monitor (a LCD screen) back. This wouild be
 around 60Hz as far as I know.
 
 And then, the measurements show 15500.350 FPS...
 
 Which slightl above 60 Hz
 
 To sync or not to sync, that seems to be the question...
 
 By the way: Distortion can be watched as when using mplayer
 as with vlc. I recompiled both just to get sure, but it does
 not help. The machine is definetly fast enough to play videos
 (AMD Phenom II X6 1090T)
 
 How can I get back the undistorted screen?
 
 Thank you very much in advance for any help !
 Best regards,
 mcc
 

 
 I would check the log files and see if they shed some light on this.  I 
 would check dmesg, messages and Xorg.0.log as well.  The last one may 
 show the best clues.  If nothing there points to anything good, I would 
 post the xorg.conf and Xorg.0.log as attachments.
 
 I have a CPU like yours except 4 core and a little GT-220 card, wimpy 
 compared to yours.  What you see about the refresh rates is displayed 
 on my machine too.  The last part appears because you hit the close 
 window X instead of doing a ctrl c to stop glxgears.  If you start 
 glxgears and do a ctrl c to stop it, the last part won't be there.   I 
 mention this because that *may* have nothing to do with the problem you 
 are having.  This is what happens when I run glxgears:
 
 fireball ~ # glxgears
 Running synchronized to the vertical refresh.  The framerate should be
 approximately the same as the monitor refresh rate.
 27770 frames in 5.0 seconds = 5553.918 FPS
 9783 frames in 5.0 seconds = 1955.847 FPS
 3084 frames in 5.0 seconds = 616.716 FPS
 3085 frames in 5.0 seconds = 616.942 FPS
 3105 frames in 5.0 seconds = 620.981 FPS
 XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server 
 :0.0
   after 42 requests (42 known processed) with 0 events remaining.
 fireball ~ # glxgears
 Running synchronized to the vertical refresh.  The framerate should be
 approximately the same as the monitor refresh rate.
 14932 frames in 5.0 seconds = 2985.639 FPS
 3011 frames in 5.0 seconds = 602.125 FPS
 ^C
 fireball ~ #
 
 The last one was stopped with a ctrl c as you can see.  The first was 
 closed by hitting the close window button.
 
 If this doesn't help, at least you know to post the files so we can 
 look them over.  Maybe someone will notice something out of place.
 
 Dale
 
 :-)  :-)
 

Hi Dale,

thank you for your in deep explanations ! :)

The distortions I saw on my screen look identical to
those I recognizeed with my old nvidia card before using
the sync settings...so i /thought/ (read: dont know for sure ;) )
it would by a syncing problem again.

But it wan't.

For reasons I dont know in the nvidia-settings there was GPU scaling
activate. May be someone sitting in front of my computer the same time
I use to has fiddled with this setting without informing me... ;)

The trick is: When watching a video in its native resolution, the
problem does not occur.

When watching the video full screen, the GPU was instructed to scale
it up (instead of mplayer or vlc doing this job in software).
Problem with this is (I thinkt), that there is one-pixel-border around
the full-screen window of mplayer/vlc so the GPU is instructed to
scale it to 1918x1199 pixel. Then this is thrown into my LCD monitor
and  rubish...

First I deatcivated GPU scaling and then spoke some serious words
to this guy, who uses my computer always the same I do and ... I am
happy again to have a clean video playing.

Thanks a lot for your explanations! (will store them for later use...
who knows what things I will encounter next;)

Have a nice weekend!
Best regards
mcc

Re: [gentoo-user] NVidia-drivers: Sync problem ???

[Dale]

meino.cra...@gmx.de wrote:

Hi Dale,

thank you for your in deep explanations ! :)

The distortions I saw on my screen look identical to
those I recognizeed with my old nvidia card before using
the sync settings...so i /thought/ (read: dont know for sure ;) )
it would by a syncing problem again.

But it wan't.

For reasons I dont know in the nvidia-settings there was GPU scaling
activate. May be someone sitting in front of my computer the same time
I use to has fiddled with this setting without informing me... ;)

The trick is: When watching a video in its native resolution, the
problem does not occur.

When watching the video full screen, the GPU was instructed to scale
it up (instead of mplayer or vlc doing this job in software).
Problem with this is (I thinkt), that there is one-pixel-border around
the full-screen window of mplayer/vlc so the GPU is instructed to
scale it to 1918x1199 pixel. Then this is thrown into my LCD monitor
and  rubish...

First I deatcivated GPU scaling and then spoke some serious words
to this guy, who uses my computer always the same I do and ... I am
happy again to have a clean video playing.

Thanks a lot for your explanations! (will store them for later use...
who knows what things I will encounter next;)

Have a nice weekend!
Best regards
mcc

   


Glad to have helped.  I find myself in a situation sometimes of not 
knowing where to start looking.  Of course, sometimes knowing where to 
look doesn't always help either but it is worth a try at least.  I 
recently had video issues and knew where to look but the solution was 
not so obvious to me but someone with better googling skills found a 
solution.


Dale

:-)  :-)

Re: [gentoo-user] nvidia-drivers conflicts

[Peter Humphrey]

On Saturday 24 April 2010 12:56:13 Peter Humphrey wrote:

 Let's hope the upgrade is a simple one for the Gentoo devs to
 incorporate into an ebuild. With any luck we'll have it in the next
 week.

Indeed, it has appeared today:

$ equery l nvidia-drivers
 * Searching for nvidiadrivers ...
[IP-] [  ] x11-drivers/nvidia-drivers-195.36.24:0

Installed happily.

-- 
Rgds
Peter.

Re: [gentoo-user] nvidia-drivers conflicts

[Alan McKinnon]

On Saturday 24 April 2010 01:22:53 Peter Ruskin wrote:
 On Saturday 24 April 2010 00:08:46 meino.cra...@gmx.de wrote:
  Hi,
  
  before getting into too much trouble better I aask:
  
  While updateing I got the following message:
  ('ebuild', '/', 'x11-base/xorg-server-1.8.0', 'merge')
  
  conflicts with x11-base/xorg-server-1.7.99 required by
  ('installed', '/', 'x11-drivers/nvidia-drivers-195.36.15',
  'nomerge')
  
  !!! The following update(s) have been skipped due to
  
  unsatisfied dependencies !!! triggered by backtracking:
  x11-apps/xinit:0
  
  The first one I understand what I wants to say, but: Is the
  conflict based on the limition of the nvidia-driver not to run
  with xorg-server-1.8.0 even when recompiled after the new
  xorg-server is reinstalled or does the latter help to circumvent
  the problem?
  
  What the second message wants to tell me is far beyond my
  knowledge ... :)
 
 You don't need to do a thing.  Until nvidia comes out with a driver
 compatible with xorg-server-1.8, portage will keep you with 1.7.
 Portage is also telling you that, because it's keeping xorg-server
 at 1.7 it won't upgrade xinit.
 
 See Bug http://bugs.gentoo.org/show_bug.cgi?id=315141


The happy news is that nvidia released a driver with xorg-1.8 support on 23 
Apr:

http://www.nvnews.net/vbulletin/showthread.php?t=150325


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] nvidia-drivers conflicts

[Peter Humphrey]

On Saturday 24 April 2010 10:46:17 Alan McKinnon wrote:

 The happy news is that nvidia released a driver with xorg-1.8 support
 on 23 Apr:
 
 http://www.nvnews.net/vbulletin/showthread.php?t=150325

Good news! Let's hope the upgrade is a simple one for the Gentoo devs to 
incorporate into an ebuild. With any luck we'll have it in the next 
week.

-- 
Rgds
Peter.

Re: [gentoo-user] nvidia-drivers conflicts

[Alan McKinnon]

On Saturday 24 April 2010 01:08:46 meino.cra...@gmx.de wrote:
 Hi,
 
 before getting into too much trouble better I aask:
 While updateing I got the following message:
 
 ('ebuild', '/', 'x11-base/xorg-server-1.8.0', 'merge') conflicts
 with x11-base/xorg-server-1.7.99 required by ('installed', '/',
 'x11-drivers/nvidia-drivers-195.36.15', 'nomerge')
 
 
 !!! The following update(s) have been skipped due to unsatisfied
 dependencies !!! triggered by backtracking:
 x11-apps/xinit:0
 
 
 The first one I understand what I wants to say, but: Is the conflict
 based on the limition of the nvidia-driver not to run with
 xorg-server-1.8.0 even when recompiled after the new xorg-server
 is reinstalled or does the latter help to circumvent the problem?

The former:

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

 
 What the second message wants to tell me is far beyond my knowledge ... :)

It's portage trying to tell you how those incompatible versions are in the 
list to be emerged. A backtrack is simply that - start with what you have, 
find out what pulled it in, and what pulled that in, till you come to the end 
(usually something in your world file).

Without digging into ebuilds, it looks like xinit pulls in xorg-x11 which 
pulls in xorg-server which conflicts with nvidia-drivers,.

This is a classic case of rule #1 of program output: never expose the 
underlying implementation in your output. That info is completely useless to 
most users and needs re-thinking. Decent programming practice says that output 
shout only be given if the user asks for it like that, with say a --debug 
option for example.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] nvidia-drivers problem on xorg 1.6.3.901-r2

[Arnau Bria]

On Fri, 13 Nov 2009 08:29:09 +0930
Iain Buchanan wrote:

Hi,

 In my experience, various nvidia-drivers just seem to not work with
 my system, no matter how many times I rebuild and recheck things.  I
 have a whole bunch of versions masked.  Looking back, I never seemed
 to have a problem with 180.60 - I ran it for about 4-6 weeks.
 
 You could try adding this to /etc/portage/package.mask:
 =x11-drivers/nvidia-drivers-180.60

I did upgrade...

 Then decide whether you want to downgrade to the previous stable, or
 upgrade to the latest unstable.  I'm running unstable 190.42-r2 and so
 far it's quite stable, but as we've seen, every system is different!
 (I'm on ~x86, so quite a bit of my system will differ from yours).
here I'm... same version as you but diff revision .

[I] x11-drivers/nvidia-drivers
 Installed versions:  190.42-r3!s(12:51:20 PM 11/16/2009)(acpi gtk kernel_li

X starts fine (I see NVidia logo for only half second) I can change
between workspaces fine, but when I open an application it hangs... I'm
lucky cause I can change to virtual console with Ctrl+Alt+F1 and no
reboot needed, but I'm really tired about this issue... 
nv does not work neither and I don't know what else I can try... Vesa
sucks (well, at least I can see things in my screen if I take off my
glasses) and I see no other people with same problem.

 HTH,
Thanks for your reply,

-- 
Arnau Bria
http://blog.emergetux.net
Bombing for peace is like fucking for virginity

Re: [gentoo-user] nvidia-drivers problem on xorg 1.6.3.901-r2

[Alex Schuster]

Arnau Bria writes:

 I've rebuild my xorg-server with no hal support, I've upgraded my
  kernel to 2.6.30-r8 and rebuild all xf86 drivers/libs/proto
  packages:
[...]
 Then, I use nvidia-xconf for geenrating my xorg.conf file and looks
 like:

[...]

 Section Device
 Identifier VGA
 Driver vesa
 VendorName Unknown
 BoardName  Unknown
 EndSection
 
 and when I start X, system goes really slow and I see some
 errors/warnings in X log file:

I would expect vesa to be quite slow. I don't know about nvidia-xconf and 
where it comes from, probably because I do not have a nvidia card any 
more. Does it really place vesa into the config?
What happens when you replace the vesa driver with nvidia? emerge 
nvidia-drivers if not already done. If this fails, try nv instead, this 
is the slower open source driver, which should be okay for 2D acceleration 
at least.

 # grep EE Xorg.0.log
  to load module freetype (module does not exist, 0)
  to load module dri (module does not exist, 0)
  to load module dri2 (module does not exist, 0)

I read something here about dri and dri2 some days ago, but don't 
remember. I think they are not needed with nvidia-drivers or something 
like that.

There is also X -configure which creates a new xorg.conf, but that 
segfaults for some years on my machine.
And you could try with hal and no xorg.conf.

Wonko

Re: [gentoo-user] nvidia-drivers problem on xorg 1.6.3.901-r2

[Alan McKinnon]

On Thursday 12 November 2009 14:34:00 Arnau Bria wrote:
 Hi all,
 
 I've rebuild my xorg-server with no hal support, I've upgraded my kernel
 to 2.6.30-r8 and rebuild all xf86 drivers/libs/proto packages:
 
 # eix xf86|grep ^\[I\]
 [I] x11-apps/xf86dga
 [I] x11-drivers/xf86-input-evdev
 [I] x11-drivers/xf86-input-keyboard
 [I] x11-drivers/xf86-input-mouse
 [I] x11-drivers/xf86-video-nv
 [I] x11-drivers/xf86-video-vesa
 [I] x11-libs/libXxf86dga
 [I] x11-libs/libXxf86misc
 [I] x11-libs/libXxf86vm
 [I] x11-proto/xf86bigfontproto
 [I] x11-proto/xf86dgaproto
 [I] x11-proto/xf86driproto
 [I] x11-proto/xf86miscproto
 [I] x11-proto/xf86rushproto
 [I] x11-proto/xf86vidmodeproto

According to this, you did not rebuild nvidia-drivers. Either

emerge nvidia-drivers
module-rebuild rebuild

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] nvidia-drivers problem on xorg 1.6.3.901-r2

[Alan McKinnon]

On Thursday 12 November 2009 14:33:22 Alex Schuster wrote:
  # grep EE Xorg.0.log
   to load module freetype (module does not exist, 0)
   to load module dri (module does not exist, 0)
   to load module dri2 (module does not exist, 0)
 
 I read something here about dri and dri2 some days ago, but don't 
 remember. I think they are not needed with nvidia-drivers or something 
 like that.
 

Yes, dri and dri2 are not used by nvidia-drivers, they implement them itself.

But X will still try and look for them.

Best way to set up nvidia drivers from scratch is to install and run nvidia-
settings


-- 
alan dot mckinnon at gmail dot com