Bug 443320
Summary: | Cannot enter keyboard input into kdm after logout | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Rex Dieter <rdieter> |
Component: | xorg-x11-server | Assignee: | Peter Hutterer <peter.hutterer> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | alain.portal, alain.portal, fedora, hippodriver, kevin, ltinkl, mefoster, pertusus, rdieter, tuju, wtogami, xgl-maint |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
URL: | https://bugs.freedesktop.org/show_bug.cgi?id=15645 | ||
Whiteboard: | |||
Fixed In Version: | 1.5.0-1 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-09-17 01:29:17 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 235705 | ||
Attachments: |
Description
Rex Dieter
2008-04-20 16:38:43 UTC
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. |