Version: (using KDE KDE 3.3.0) Installed from: Debian testing/unstable Packages Compiler: gcc 3.3.5 OS: Linux After a reboot, kdm does not accept any keyboard input. To get the keyboard back, I have to use the mouse to open a console session and restart the X-Server. after I close that session, kdm comes back with full keyboard input capability. I switched to gdm for the opening screen as a test, and gdm starts up fine - all keyboard input available. The problem seems specific to kdm.
i guess that the ServerVTs option in kdmrc is set incorrectly.
I just looked at the configuration. ServerVTs is set to -7 by the Debian configuration. What should it be?
hmm, that seems right. how many ttys do you have configured in inittab? do you have a vt7 etc. in Xservers? does removing it help? does adding a different one help?
I'm going to have to get some help here. I'm not sure of these configuration areas. I'm going to copy what I *THINK* is the relevant section of inittab at the bottom. I'm not sure where to look in the Xservers definition. I'll be glad to test with anything you want, but I'm not sure what you're asking. I think I have 6 tty's configured in inittab. Here's the lines I think are relevant; if I'm wrong, I'll be glad to get whatever you want # Note that on most Debian systems tty7 is used by the X Window System, # so if you want to add more getty's go ahead but skip tty7 if you run X. # 1:2345:respawn:/sbin/getty 38400 tty1 2:23:respawn:/sbin/getty 38400 tty2 3:23:respawn:/sbin/getty 38400 tty3 4:23:respawn:/sbin/getty 38400 tty4 5:23:respawn:/sbin/getty 38400 tty5 6:23:respawn:/sbin/getty 38400 tty6
that seems normal. please look at the X server log of such a failed start attempt. maybe it reveals something unusual.
What failed start attempt? Those lines were from inittab.
> What failed start attempt? > the one resulting in no keyboard, obviously. > Those lines were from inittab. > noooo, really!?!? ;) > I'm not sure where to look in the Xservers definition. > just paste all non-empty non-comment lines. it won't be that many.
I've had the same problem with kde 3.3.1. The problem disappeared when I removed the getty tty7 from inittab. But I think the problem is still there. kdm uses an used tty, even when the configuration file says: # VTs to allocate to X-servers. A negative number means that the VT will be # used only if it is free. If all VTs in this list are used up, the next free # one greater than the last one in this list will be allocated. # Default is "" ServerVTs=-7 And there are more free ttys. Regards.
Sorry for the delay in update, but I had some family problems that intervened. I don't have a tty7 in my inittab, so that's not the issue. As to the failed start of X, there are no messages in my log file that indicate a failed start. Note that if I enable "gdm" instead of "kdm", gdm works perfectly. It's only "kdm" that fails at startup.
On Fri, Nov 12, 2004 at 05:42:52PM -0000, Michael Satterwhite wrote: > As to the failed start of X, > there are no messages in my log file that indicate a failed start. > i didn't tell you to look for indications of failure, only for something unusual. ;) try "diff -u"ing the logs of a "good" and a "bad" xserver run. > Note that if I enable "gdm" instead of "kdm", gdm works perfectly. > It's only "kdm" that fails at startup. > that doesn't mean anything. kdm (and xdm) has an amazing track record of triggering x server problems which go unnoticed with gdm. don't ask me why.
On Friday 12 November 2004 11:53 am, Oswald Buddenhagen wrote: > On Fri, Nov 12, 2004 at 05:42:52PM -0000, Michael Satterwhite wrote: > > As to the failed start of X, > > there are no messages in my log file that indicate a failed start. > > i didn't tell you to look for indications of failure, only for something > unusual. ;) > try "diff -u"ing the logs of a "good" and a "bad" xserver run. As X apparently fails on first start anytime kdm is the manager, I see two possibilities to get the data: (1) I can boot with gdm and use that start of X or (2) I can use the log of the restart of X (which works). Which one of these would best get you the information you need? Can you think of another way that would be better?
> I can use the log of the restart of X (which works). > that's obviously better, because the rest of the environment is the same. as Xfree/org automatically backs up the log, you only need to start the machine, restart the server and do the diff on the two X logs in /var/log.
> ------- Additional Comments From ossi kde org 2004-11-12 19:43 ------- > > > I can use the log of the restart of X (which works). > > that's obviously better, because the rest of the environment is the same. > as Xfree/org automatically backs up the log, you only need to start the > machine, restart the server and do the diff on the two X logs in /var/log. Here's the output: diff XFree86.Err.log XFree86.0.log 20c20 < (==) Log file: "/var/log/XFree86.0.log", Time: Sat Nov 13 09:18:37 2004 --- > (==) Log file: "/var/log/XFree86.0.log", Time: Sat Nov 13 09:24:18 2004 48c48 < (++) using VT number 4 --- > (++) using VT number 7 72c72 < (II) PCI: stages = 0x03, oldVal1 = 0x8003593c, mode1Res1 = 0x80000000 --- > (II) PCI: stages = 0x03, oldVal1 = 0x00000000, mode1Res1 = 0x80000000 693,695c693 < drmOpenDevice: open result is -1, (Unknown error 999) < drmOpenDevice: open result is -1, (Unknown error 999) < drmOpenDevice: Open failed --- > drmOpenDevice: open result is 5, (OK) 698,700c696 < drmOpenDevice: open result is -1, (Unknown error 999) < drmOpenDevice: open result is -1, (Unknown error 999) < drmOpenDevice: Open failed --- > drmOpenDevice: open result is 5, (OK) 705d700 < (II) RADEON(0): [drm] loaded kernel module for "radeon" driver 810,812c805 < (II) RADEON(0): [drm] removed 1 reserved context for kernel < (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xd0f64000 at 0x44278000 < (II) RADEON(0): Wrote: rd=12, fd=101, pd=3 --- > SetClientVersion: 0 8
> < (++) using VT number 4 > > (++) using VT number 7 > this is what i expected - i can't explain why it is that way, though. please mail me your complete kdmrc in private.
against your claim, there is no ServerVT line in that config file. maybe you saw a commented out entry before?
On Sunday 14 November 2004 02:16 am, Oswald Buddenhagen wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=91395 > ossi kde org changed: > > What |Removed |Added > --------------------------------------------------------------------------- >- Status|UNCONFIRMED |RESOLVED > Resolution| |INVALID > > > > ------- Additional Comments From ossi kde org 2004-11-14 09:16 ------- > against your claim, there is no ServerVT line in that config file. maybe > you saw a commented out entry before? I'm afraid I sent you the wrong file. The correct one is on its way to you. Debian splits out its configuration. I sent you the one you asked for instead of the corresponding file from Debian. My fault. The line is there.
learn2quote ;) On Sun, Nov 14, 2004 at 01:55:07PM -0000, Michael Satterwhite wrote: > I'm afraid I sent you the wrong file. The correct one is on its way to you. > Debian splits out its configuration. I sent you the one you asked for instead > of the corresponding file from Debian. My fault. The line is there. > this poses the question, which file is _actually_ used. run kdm with -debug 2 and read the daemon.debug syslog.
Why is this invalid? I don't see that the reported got some solution here. I don't see one. I am having the problem described here on SuSE 9.1 and KDE 3.2.1. It began only after recent online updates. This seems to be the same as bug 29067 and bug 45478. I would like my kdm to work right again.
*** Bug 98961 has been marked as a duplicate of this bug. ***
*** Bug 87906 has been marked as a duplicate of this bug. ***
*** Bug 99026 has been marked as a duplicate of this bug. ***
I am having this problem with KDE 3.4 beta2. Everthing was working normal with beta1, but now my keyboard dosen't work on KDM after reboot. Can someone please post a workaround/fix here or reopen the bug please?
The workaround is to boot into runlevel 3 (type 3 in GRUB) and then log in as root and execute init 5. Another way is to move your /etc/opt/kde3...config/kdm/kdmrc. Yet bare in mind that after you used SuSEconfig, the file will be regenerated and you will have to delete it again. It is not acceptable that this issue remains for 3.4 final as it will attract a lot of anger to KDE, although it is not KDE's fault. So I think that as there are some SuSE developers within the KDE community, they should be contacted, assigned to the bug and solve it. If it is not only a SuSE issue, then devels of the other distros could help too.
According to the log this has been solved for Debian but I upgraded last week and its doing exaclty as described.
Still present in 3.5, 3 years later. I see S. Burmeister's comment on it, but to be completely honest I have no idea what typing "exec init 5" really does. All it does for me is close my terminal window, or if I'm in terminal mode log me out. I'm getting very similar symptoms on my install of KDE 3.5. I'll be using it, sometimes for days or possibly only a couple of hours, and at random the keyboard will just stop working. Oddly, holding *down* a key will cause it to register after a delay and begin repeating itself, but touching the keys as in normal typing has no effect. I have to log out of KDE with the mouse, and than type "startx" again to get it to come back, and then it's fine for another random amount of time. Can anyone explain how to fix this, in very very simple terms? I'm still new to linux. I can get around, and I know how to use Vi, but that's pretty much it.
comment #25 refers to a completely different problem. i saw it discussed somewhere, but i don't remember exactly any more. kded, khotkeys or even the x server might have played a role. in any case, don't discuss this issue here.