+++ 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 Fedora/3.0-0.54.beta5.fc9 Firefox/3.0b5 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): kdebase-workspace-4.0.3-16.fc9.x86_64 How reproducible: Always Steps to Reproduce: 1. Log into KDE 2. Log out from KDE 3. Try to login again Actual Results: Kdm didn't accept any keystrokes, so I can't enter my password. Expected Results: Kdm should accept input from keyboard. Additional info: -- 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: https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01473.html 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 isn't reacting.
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... Now, at localhost login: I press enter, and see: "^M" printed, and then: [root@localhost /]# type a few commands, like ls, and see output, and after a bit, I again see login: 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: http://bugs.kde.org/161152 which sounds relevant, will test.
Adding "Patch" keyword because an xorg-x11-server patch by Bernhard Rosenkränzer is available: http://bugs.kde.org/show_bug.cgi?id=161152#c2
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: TerminateServer=true 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 same thing.
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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 [1], also reported as 15645 [2] 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 soon. Removing Patch keyword, the patch to kde bug 161152 doesn't work, this code was the original cause for X.Org bug 14418. [1] https://bugs.freedesktop.org/show_bug.cgi?id=14418 [2] https://bugs.freedesktop.org/show_bug.cgi?id=15645
Fixed by now with xorg-x11-server-1.5.0-1. Please reopen if this is still an issue.