Klaus Vink Slott posted on Wed, 08 Jun 2011 12:17:47 +0200 as excerpted: > Hi > > After upgrading my OpenSUSE system from 11.3 to 11.4 my keyboard freezes > when I log in to KDE. Not even NumLock on/off LED reacts, Xkill or > change to console. No problem at console or at gui login (kdm4). Mouse > works and keyboard resumes as soon as I log off. > > If I move .kde4 out of the way I am able to login with a working > keyboard. So I guess that one of the upgraded kde programs dont like > some old setting. But I am really annoyed if I have to rebuild all my > kde customization. I have tried to remove .kde4/share/config/khotkeysrc > and .kde4/share/config/startupconfigkeys but that did not help. > > Does anyone have an idea on which .kde4 files may freeze my keyboard?
Speaking as a HEAVY customizer myself, and thus one who has used the following "bisect" method to ultimately pinpoint such problems before, you do NOT have to rebuild your entire customization. Fortunately, you've already done the first step of what is known as the bisect method, finding that the problem is indeed in your ~/.kde4, since if you move it out of the way, things work as they should. The logical thing to do is to simply continue from there, iteratively reducing the possible problem area at each step, until you find the specific problem file, then possibly continuing within that file (switching from a file manager to a text editor in ordered to do so) until you find the specific problem section, then the specific problem line. If you've ever played the kids game "20 questions" or used the git bisect tool (thus the bisect name, people have been doing it for years but git bisect has had the effect of finally popularizing a common name, where it was variously named and described before), you know the idea. Basically, it's to iteratively eliminate as much of the potential problem space as possible with each test. Mathematically, that means splitting it in half each time, then testing whether the half you chose is the good or the bad half, then iterating such that the next test is on the bad half. Of course in practice finding the exact half-way point generally takes more time than it is worth, with a quick approximation (emphasis on quick as opposed to accurate) generally getting the job done faster, save for the case in which it can be automated (as with git bisect). So let's take a look at the $KDE_HOME dir (for that's what you're referring to, except I'm using the generic term) and see how you might split things down. Generally speaking, nearly the entire kde config is found under $KDE_HOME/share, in one of two subdirs, apps, which in turn contains individual application subdirs, many of which have multiple files within, and config, which is a bunch of individual files, many of them *.rc files. We can thus assume with a reasonable degree of certainty that the problem is within one of those, making this actually a three-way test, testing each of the two subdirs first since we assume it's there, and only moving to everything else if both of those dirs come up clean, thus disproving our assumption. Thus, the next step is: Pick one dir to move, $KDE_HOME/share/apps/ or $KDE_HOME/share/config . Test again. If the problem disappears, you KNOW it's in the one you moved (not in the one you didn't move). If the problem remained, you know it's NOT in the one you moved, and can ASSUME it's in the other one, so delete whatever files kde built on the aborted attempt and move the tested dir back (since it should be fine, then move the other, and test that to be sure. After each step, remember to delete the default files that kde created in the missing half before moving your saved files back in place. With the assumption that you'll find the problem is in one of those dirs, move the good one back, and more or less of the bad one (keeping the other half in your backup. Again, since the test is relatively quick, don't trouble yourself to figure out what's exactly half, just so the known good part is moved back in place after each test, and the bad part is split between the backup and the normal location. Repeat until you're down to one dir (if in app) or one file or set of files obviously belonging to a single app (if in config). If at that point you're comfortable rebuilding the remaining config, you CAN call it good, or continue with the process. (FWIW, I nearly always continue, for the simple reason that I'm the curious type and want to find the single setting that caused me all this trouble! But it's up to you.) If you've narrowed it down to a dir, you can enter that dir and continue the process... until you're down to a single file. Once you're down to a single file, again, stop if you judge it more bother than it's worth to continue, but FWIW, as I said, I like to find the blasted setting that caused me all this trouble, so I nearly always continue. If you continue within a file, you switch to a text editor to do so. (Fortunately, nearly all of kde's config is stored within human readable/ editable text files. Normally they're reasonably simple to edit, flat "init style" text files divided into [sections], with setting=value lines populating the sections. Even within that general format, however, a few (see plasma-desktop-appletsrc in the config dir for an example) can get pretty complex and difficult to edit. If you end up at one of these, I recommend stopping there unless you have quite some patience and enough tech understanding to grok the section layout and can figure out the section dependencies in ordered to split at the logical break-points. (I did successfully edit that file at one point, but it's not an experience I'd like to repeat -- I keep a backup of the file now, actually, a couple generations of backup to be sure, just in case it gets screwed up again. Not that the backup would necessarily help if the problem were an upgrade, but at least then I'd be reasonably sure the problem wouldn't retrigger right away again.) But most kde config files are simple enough that it's relatively easy to narrow the problem down to a single section, and then if desired, a single line/setting. At that point, you can delete that single setting, and recreate it with the GUI if appropriate. In the event that our assumption at the top proved wrong, then with just three tests (the one you already did with $KDE_HOME and the two with the subdirs), you've eliminated most of the problem space. At that point, it's very likely to be possible to browse the remaining dirs and take a guess at what might be wrong. Perhaps you have a script set to run from your autostart dir, for instance. You probably already know if you set any of those up, and could quickly enough check whether they're the problem. Sounds, icons, wallpapers... shouldn't be a problem unless, for instance, the wallpaper you had set as the desktop wallpaper got corrupted, or the startup sound file got corrupted. But those sorts of issues would almost certainly turn up as a frozen desktop or a crashed machine or something, NOT a simple lack of keyboard/mouse, so it's pretty safe to assume they're not involved. The share/services dir might be, and service types, and... that's about it! But as you already narrowed it to $KDE_HOME (not something else in your config), there's probably a 95% chance it's in one of those two initial dirs, and if it's not, 4.8 % of the remaining 5% says it's an autostart script that you should remember setting up. That leaves only about 0.2% chance that it's somewhere else in $KDE_HOME, including the services dirs, etc. Based on my experience, at least. Maybe your problems are different than mine, tho, or a crazy exception. =:^) Meanwhile, attacking the problem from a different angle, I'm not a SuSE user and if you can't bother to mention the involved kde versions, well, I'm not going to trouble myself looking them up, either, but IF your previous kde version was 4.5 or earlier, than it was hal-based, while 4.6 (and later) are now udev(and family, /udisks/upower/...) based. It's quite conceivable that has something to do with it if indeed you're on kde 4.6 now while 4.5 or earlier before the upgrade. Unfortunately, that doesn't give me any hint at what apps/files might be the problem, but keeping it in mind might help you guess the problem earlier as you use the bisect technique above, thereby potentially shortening the process by a few test iterations. Similarly, at some point xorg itself switched from hal input-dev detection to udev-based detection, but that was some time ago, so unless SuSE is way behind or unless those are old SuSE versions, AND because such changes would have been extremely unlikely to involve anything in $KDE_HOME (with the possible exception of a script you had doing something from autostart), that's rather unlikely to be the problem here, tho it certainly triggered similar input detection issues for others, just not generally related to anything in $KDE_HOME. -- 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.
