[kde-linux] Re: Loosing keyboard in KDE
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Date: Wed, 8 Jun 2011 12:56:01 +0000 (UTC)
Klaus Vink Slott posted on Wed, 08 Jun 2011 12:17:47 +0200 as excerpted:
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
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.
More info: http://www.kde.org/faq.html.
- [kde-linux] Loosing keyboard in KDE
- From: Klaus Vink Slott
- [kde-linux] Loosing keyboard in KDE
- Prev by Date: [kde-linux] Re: Loosing keyboard in KDE
- Next by Date: [kde-linux] Re: Loosing keyboard in KDE
- Previous by thread: [kde-linux] Re: Loosing keyboard in KDE
- Next by thread: [kde-linux] Re: Loosing keyboard in KDE