Wow, finally found the culprit! It turned out I had this variable set in my ~/.bashrc
export __GL_FSAA_MODE=7 According to nvidia documentation it should be equivalent to: nvidia-settings --assign FSAA=7 but it seems it isn't. After commenting out the offending line my system runs completely smooth. Thanks! Juan Pablo El día 7 de mayo de 2011 14:41, Juan Pablo Romero Méndez <jpablo.rom...@gmail.com> escribió: > Thanks for your response Duncan, > > The upgrade is not an issue anymore because in a moment of desperation > I formated the root partition and reinstalled opensuse. The version > of kde shipped with it is 4.6.0. > > Also I tried deleting the ~/.kde4 folder and nothing happened. > > Deleting ~/.local caused something interesting to occur: the first > few seconds after loading the desktop, the system was very responsive > (I thought the issue was resolved), but after some more seconds the > problem begun again. > > Examining a newly created ~/.local, the only interesting thing I see > is akonadi's folder in ~/.local/share/akonadi. Within it there are > several files and folders that appears to belong to mysql. > > Regards, > > Juan Pablo > > > 2011/5/6 Duncan <1i5t5.dun...@cox.net>: >> Juan Pablo Romero Méndez posted on Fri, 06 May 2011 21:17:43 -0500 as >> excerpted: >> >>> Hello, >>> >>> I've just upgraded to opensuse 11.4, which came with kde 4.6 >>> >>> The problem is that the keyboard input is so slow that renders the >>> system virtually unusable. >>> >>> I've been monitoring the system with top but can't find something >>> obvious. >>> >>> The weird thing is that on another account I made just to test, kde runs >>> fine. It is something with my account that kde doesn't like. >>> Perhaps its size (300G), perhaps some config file from another version. >>> >>> Also, the linux console works fine. >>> >>> What do you guys think? >> >> You include some good info, but there's some potentially critical info >> missing, too. >> >> 1) You say you just upgraded to OpenSuSE 11.4, which comes with KDE 4.6, >> but you don't mention /which/ 4.6. There's now 4.6.0, 4.6.1, 4.6.2, and >> the /just/ released 4.6.3. >> >> 2) What did you upgrade /from/, both distribution-wise and presuming you >> ran kde on it, what version of kde? >> >> Just upgrading from an old kde-3.5.x installation could yield far >> different results than just upgrading from, say 4.3 or 4.4, which could be >> rather different than upgrading from 4.5.x, which is different again from >> upgrading from last month's 4.6.2 to the just released 4.6.3 (the upgrade >> I just did here, Gentoo, FWIW). >> >> 3) *VERY* good thinking trying a test user account, and putting the >> results in your post! =:^) That it doesn't occur there does indeed >> indicate, as you suggested, that it's a user config issue. The problem is >> now finding out what/where. That's where the above info may come in >> handy, since upgrading from 3.5.x is really quite different indeed from >> upgrading from 4.5.5, and if an upgrade between 4.6 versions is causing >> issues, it's quite interesting as those should be bug-fix-only upgrades >> (not that the 4.6 series has been as smooth as in theory bug-fix-only >> upgrades should be, there's unfortunately been some notable regressions). >> >> Meanwhile, continuing from the new-user test, do you know what bisecting a >> problem is? Since we know it's in your user config, that's how I'd >> approach it. >> >> Briefly, the idea behind bisecting is that once you have a known problem >> space (in this case, your user config), one can iteratively narrow the >> problem down to successively smaller parts of that problem space, at each >> iteration figuring out which half of the remaining problem space it's in, >> until one finds the problem. >> >> To shortcut the process by a couple iterations, nearly all kde's config is >> found in $KDEHOME, normally ~/.kde, or possibly ~/.kde4, depending on >> distribution. So that's the config directory we'll assume it's in, and >> the first step is confirming that. Without kde running (so from a CLI >> login or from gnome or whatever), rename your problem user's ~/.kde (or >> kde4) directory to something like .kde.bak. >> >> Now start kde as your problem user. Is the problem gone? If so, we've >> confirmed that the problem is in $KDEHOME. >> >> Assuming it is, the next step is to split that in half. Again taking a >> shortcut, nearly all kde settings are in the $KDEHOME/share, in one of two >> subdirs, config or apps. So again with kde not running, delete the stub >> $KDEHOME our first test created and copy back all of the dir from the >> backup BUT $KDEHOME/share/config. >> >> Rerun the test. If the problem is still gone, we know the problem file is >> one of those in config. If the problem is there again, we can assume >> config is fine and that the problem is in one of the apps subdirs, instead. >> Delete the stub config dir created by the test. >> >> If the problem was in config (didn't appear in the test above), copy half >> the files from the config dir in your backup to the operating location, >> and retest. >> >> If the problem was NOT in config (it did appear in the test above), go >> ahead and copy all your config files back from the backup, and delete the >> apps subdir instead. Retest to confirm that it's in apps. >> >> Repeat until you've isolated the problem file. At this point, you have a >> choice. You can either stop, delete that file and reconfigure anything >> that its settings controlled as necessary, OR switch to a text editor >> instead of the file manager for testing, and continue, first with sections >> within the file until you figure out which section it's in, then with >> individual lines in that section. FWIW, I like to figure out exactly what >> has caused me all this hassle, so generally do continue down to the >> individual line level. But people with less patience or less >> customization than I have may be fine stopping at the file level, or even >> higher, if they decide the hassle of testing further is greater than the >> hassle of reconfiguring the customizations remaining in whatever number of >> files will be deleted. >> >> For the type of problem you've indicated, a bisect, while being somewhat >> boring and requiring quite some patience, tends to be very effective, >> resolving the problem nearly every time. Unfortunately it doesn't work so >> well on problems that aren't easily replicated, thus making testing each >> bisect level far more difficult as you never know for sure whether you're >> on the good half or if the problem simply hasn't triggered yet. >> Similarly, if there's two separate causes for the problem, bisecting >> doesn't work well if at all, because it's difficult to find both of them >> at once. So bisecting certainly does have its limits, but for easily >> replicated problems in a known to be limited problem space and likely >> having only one cause, as is your case, it tends to work pretty well... as >> long as you have enough patience to carry thru with the repetitive testing. >> >> Good luck! =:^) >> >> -- >> Duncan - List replies preferred. No HTML msgs. >> "Every nonfree program has a lord, a master -- >> and if you use the program, he is your master." Richard Stallman >> >> ___________________________________________________ >> This message is from the kde-linux mailing list. >> Account management: https://mail.kde.org/mailman/listinfo/kde-linux. >> Archives: http://lists.kde.org/. >> More info: http://www.kde.org/faq.html. > ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
