Image 01
profile-image

north

Lars Bj√∂rklund
Nvidia cursor shadow

KDE 3.x Splash Screens by north 18 comments

While I in no way wish to defend poor binary drivers (although the nvidia ones have always worked flawlessly for me 'cept when I ran an 800x600 fbcons), it should be noted that Nvidia don't have a lot of choice in whether or not they want to release their drivers as binaries or source. A lot of third-party copyrighted material is in there -- releasing the source for that would be violating the rights of those third-party vendors/companies.

It might be plausible for Nvidia to release the source -only- for those parts that aren't restricted by third-party licensing, but question is how usable such drivers would be and how much work would be needed to add the functionality of the existing binary drivers back into the source ones.

While your system might be 'vanilla', there's nothing that says that everything in it is oerfect. Instability such as this might be caused by bad memory, by odd bios configurations etc. You said you have had several GeForce-class cards -- does this problem occur with all of them? If it does, I would suspect that you have some other hardware that is acting up.

Well, I can't really do more than suggest what might be wrong -- I hope you'll be able to find and fix the troubles you've had.

-- Lars - Apr 10 2002
Nvidia cursor shadow

KDE 3.x Splash Screens by north 18 comments

Sorry, but you need a GeForce2-class card or higher for the cursorshadow trick to work. I personally have no idea why Nvidia made the decision not to support anything below GeForce2 - the TNT2 is more than powerful enough to support this kind of thing.

My suggestion is that you mail Nvidia and ask why it's not supported. - Apr 10 2002
Nvidia cursor shadow

KDE 3.x Splash Screens by north 18 comments

I'm glad you found this useful - now we just need to bugger Nvidia so they implement a 'transparent-gradient' cursorshadow ala XP/Win2k.

I can at least dream about it. *g* - Apr 09 2002
I don't quite like the current ratio of screenshots on the site as opposed to other content, but I must also, at the same time, say that a lot of the screenshots I've seen here, though most aren't very original, do look quite good. Moving them from the frontpage could render them 'invisible' for most poeple -- couldn't it instead be a good idea to list the latest three screenshots or so last on the page... that way, they are still there and updated, but they don't interfere as heavily with the 'adaptable' content that does show up on the site.

Furthermore, couldn't a 'Tutorial' section be a good thing to see in the future? There have been four or so tutorials as far as I can see in the last few days and I'm certain more will be written as new questions are asked. I like helping out, but I also realize that tutorials are currently listed as regular items, while they might only be interesting to a small or specific group of people (as is the case with my Nvidia Cursor Shadow text).

I'm really just thinking aloud here. Feel free to dismiss my ramblings if they're too far-fetced. :') - Apr 09 2002
Nvidia cursor shadow

KDE 3.x Splash Screens by north 18 comments

Fixed. I seriously need to proofread the stuff I write. :) - Apr 09 2002
Highly Optimized KDE3 w/ objprelink

Various Stuff by thelocust 18 comments

I got a similar error when trying to use the objprelink binary for Slackware under Gentoo (where I couldn't compile it myself, for whatever odd reason). Have you tried to run the moc binary just 'as-is'? If it still segfaults, you might want to run it in gdb and see if that will output anything useful.

I know this in itself might not be mouch help, but it could provide a pointer to what is going wrong, and help others provide more useful feedback. - Apr 09 2002
Highly Optimized KDE3 w/ objprelink

Various Stuff by thelocust 18 comments

Technically, it is already in KDE, you just need to compile the kde packages with the --enable-objprelink configure option. That it's not turned on by default is because it *might* cause problems on various distros/configurations, and because it's so far only really been tasted on x86/linux. Since KDE is targeted at more than just Linux, having it this way makes way more sense.

With the coming possibility of system-integrated prelinking, this will become a moot operation. objprelink is only there as a temporary solution, until the system-level replacement is ready, as far as I can tell. (Look at the objprelink page for more information).

I managed to compile and get objprelink to run without using the provided binary on the second run I tried, but it really didn't make a whole lot of difference to me, like I previously stated. Objprelink or not, KDE 3 is -very- fast on my system, which I of course see as a very good thing. :') - Apr 09 2002
Highly Optimized KDE3 w/ objprelink

Various Stuff by thelocust 18 comments

The homepage is located at http://leon.bottou.com/objprelink/

Note that it might or might not compile under Slackware 8 and even if it does compile it might not work. If it does work, fine, if it doesn't, read up on the objprelink homepage to find a link to a binary of objprelink for slackware users.

I also suggest setting, for P3/P4 and equivalent/better users, the CXXFLAGS and CFLAGS variables to '-march=i686 -mcpu=i686 -O3' for optimized, speedy packages. If any ./configure fails to run because of this, setting -O2 instead of -O3 might help to get things going. The difference between -O2 and -O3 isn't that great, anyway.

On my system, I don't really get a great increase in speed between KDE 3.0 w/ objprelink and KDE 3.0 without (bot compiled with the above CFLAGS and CXXFLAGS); both installs were quick and responsive. I have seen it make a major difference, however, so I recommend giving it a try.

Before you do this, you might want to ask your distribution makers if their KDE 3 packages aren't already compiled against objprelink - it just might save you some time. :)

Happy KDE:ing. - Apr 09 2002
Nvidia cursor shadow

KDE 3.x Splash Screens by north 18 comments

A lot of the instability with the Nvidia drivers seem to rise from how the kernel and the system is configured overal. Things such as framebuffer resolution at the console and what patches are applied to the kernel do make a lot of difference. With my current Slackware setup, I haven't had any crashes yet, but with my previous Mandrake setup, I did have quite a few crashes... but only when I didn't run 1024x768 in the framebuffer console or when certain services were running (lm_sensors was one, don't quite remember the others).

I don't know if that's your issue, but like I said, the framebuffer might interfere with X. Also, if you have an odd motherboard like me, Bios versions do matter. I've got an Aopen AX3S with an Award Bios, and going above bios version 1.20 means instability for me in anything but windows, which I don't run. :')

Furthermore, according to the Nvidia driver documentation, you may want to try giving the NVAGP option a try. If you don't have a motherboard with one of the chipsets listed in appendix F of http://download.nvidia.com/XFree86_40/1.0-2880/README.txt,
you might want to forcefully set it to use the AGPGart linux interface. If you have one of the chipsets listed there, tho, you might want to give the Nvidia AGP driver a try.

I hope this helps -- It sucks a lot to have a crashing system. - Apr 09 2002