+++ This bug was initially created as a clone of Bug #443307 +++
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5) Gecko/2008041301
Description of problem:
It is not possible to login into kdm again after logging out from kde.
Kdm doesn't accept any keystrokes, while interaction by the mouse is still possible.
Workaround: After restarting X server, I can log in again.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Log into KDE
2. Log out from KDE
3. Try to login again
Kdm didn't accept any keystrokes, so I can't enter my password.
Kdm should accept input from keyboard.
-- Additional comment from rdieter.edu on 2008-04-20 12:12 EST --
I've seen this on occasion too, but only after I suspend->resume my laptop.
Methinks there's an X bugosity going on here.
Session->Restart X server is a quick-n-dirty workaround.
-- Additional comment from rdieter.edu on 2008-04-20 12:20 EST --
This almost certainly isn't kdm at fault here. At least for me, even
CNTL-ALT-BACKSPACE doesn't work.
What video driver are you using?
intel (945) here, dell latitude d620 (but I wouldn't have thought that the video
hardware/driver would affect keyboard input, but hey, you never know)
Well, there's at least one report on the mailing list with it happening with
the evil proprietary nvidia driver:
but as you can reproduce it with intel it can't be that. And you're probably
right that the video driver is irrelevant anyway => canceling needinfo.
I think I've also seen this. I'm using the live image so there's no keyboard
interaction needed to log in -- just double click on passwordless "fedora" user
-- but after I do log in like that, the keyboard doesn't work in KDE proper.
I discovered by accident that if I'm logged in and it's in this state, typing
"ctrl-C" seems to restart X and then KDM, and then everything's fine.
I can reproduce this, but I am guilty of the evil-of-nvidia.
I've tested a bit more, and yes, it definitely does seem that Ctrl-C restarts X
when it's in this state, both in kdm and from inside kde. Weird ......
Shouldn't that be xorg-x11-drv-keyboard, not -mouse? It's the keyboard which
I've been doing a bit more testing. It's still the case that, at least for me, I
can press ctrl-C and have X restart when things are in this state. Ctrl-Alt-F1
also works ... so I tried getting the output of ps auxww before and after
restarting X. I'll attach the two files and the diff between them shortly.
Nothing jumps out, unfortunately. Am I the only one who's seeing the Ctrl-C thing?
(NB: Intel graphics card, for what it's worth)
Created attachment 303462 [details]
Output of "ps auxww" while in KDM when I can't type
Created attachment 303463 [details]
Output of "ps auxww" while in KDM after Ctrl-C (X restarted)
Created attachment 303464 [details]
diff between the previous two attachments
Created attachment 303468 [details]
Better "before" ps
Created attachment 303469 [details]
Better "after" ps
Created attachment 303470 [details]
diff between the previous two attachments
Oops, my previous ps outputs had a rogue gamin client in them that's probably
not relevant (it times out and exits on its own if you let it).
Unfortunately, I don't see anything relevant in that diff, the list of
processes before and after is the same, only the execution times changed and of
course the PIDs of the processes which got restarted.
Switched to using gdm, gdm itself seemed to work fine.
But, some other wierd stuff started happening. Cntl-Alt-F1 to get to console.
Initially, all my keyboard input was doubled: press p -> 2 p's appear. As soon
as the input on the screen reached the bottom, and it refreshed at the top, the
doubling went away... but...
I press enter, and see: "^M" printed, and then:
type a few commands, like ls, and see output, and after a bit, I again see
freaky. Switching to anything other than VT1, things seem better.
Oh, and I can confirm the "Cntl-C" behavior as mentioned in comment #6 (only
tested when on kdm screen). Pressing it restarts X session.
egads, I can now reproduce this every time, freshly booted.
Testing logging into gnome from kdm, same problem.
mefoster found this:
which sounds relevant, will test.
Adding "Patch" keyword because an xorg-x11-server patch by Bernhard
Rosenkränzer is available:
Looks like there's a relevant freedesktop.org bug too.
*** Bug 444053 has been marked as a duplicate of this bug. ***
In the meantime, a quick-n-dirty short term hack could be to add to kdmrc:
as suggested http://bugs.kde.org/show_bug.cgi?id=161152#c3
I've got the same problem with kdebase-workspace-18.fc9.x86_64.
If you need information from me, just let me know
See bug #443307 for a test build of kde-settings that includes a (hopefully
temporary and ugly) workaround.
Given the KDE workaround, I'm moving this off the blocker.
Well, we still have the problem that the workaround doesn't get applied on
updates because kdmrc is %config(noreplace).
Trouble with these X regeneration bugs is that you can't ever be sure that
you've got rid of them entirely. They are often driver/hardware dependent.
These regeneration bugs keep coming back again and again for years, and they are
not a huge priority for X upstream to fix. For this reason gdm terminates X
every time you logout. gdm no longer has an option anymore. kdm should do the
Although it may be needed to workaround bugs, they should be fixed
where they are. And after the bug is fixed upstream and put in fedora
those workarounds should certainly be removed.
+1 to Patrice, this should really get fixed in X, not hacked around.
There is nothing wrong with fixing individual X bugs as you find them. But do
you realize how difficult it would be to confirm it is fixed on every possible
driver and chipset combination?
I do. And it is even more difficult if there are workarounds that
mask them. It makes sense to mask them in stable releases, but
in rawhide I don't think it is a good idea (except maybe when too
many users are impacted).
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Things are worse in rawhide for me (using xdm), but I don't know if it is
related with xdm, my hardware, or X. Now, after I hit Ctrl-C the computer
becomes unresponsive with a dark screen. Could people with kdm and different
setups test, please?
Problem is caused by the original fix to X.Org bug 14418 , also reported as
The follow-up fix never got cherry-picked into server-1.5-branch, hence when the
server restarted the devices configured in the configuration file weren't
re-initialised. I cherry-picked and pushed it upstream now, should trickle down
Removing Patch keyword, the patch to kde bug 161152 doesn't work, this code was
the original cause for X.Org bug 14418.
Fixed by now with xorg-x11-server-1.5.0-1.
Please reopen if this is still an issue.