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.
