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.
