[kde-linux] Re: Loosing keyboard in KDE

[Duncan]

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