Hi! This bug may be related to bugs #139066 and maybe #129793 in some way. After upgrading to the modular X.Org X11 X7.0 (stable, x86) my keyboard doesn't do anything after boot-up into KDM. The mouse works though. The following experiences might be of interest: 1. I use the open source radeon driver from xorg. 2. After boot-up into KDM with no keyboard working and me stupidly pressing everything and nothing (includeing Ctrl-Alt-Backspace which is also not working) - after some time some numbers are working: 2, 3 and 4, and after some time they repeat themselves endlessly. 3. I can reboot the machine with the mouse in KDM. 4. On the next reboot I was able to stop KDM from loading with Ctrl-C (which didn't work I guess) and Ctrl-Alt-Backspace (I could already see the X-cursor). This was reproducable several times. 5. After stopping X from starting I get a console login - and the keyboard is working. 6. Logging in as root I could stop /etc/init.d/xdm (which was marked started) and start it again. SURPRISE - KDM fires up and the keyboard works. 7. Something else that is strange: on the second console (Alt-F2) I have three Eights ("888") on the login prompt and the keyboard does not respond - until after some time the message "login failed" pops up and a second login prompt thereafter works well, with the keyboard working in perfect order. I now have "rc-update del xdm" and fire up /etc/init.d/xdm manually. No problems so far with the keyboard in X and KDE - works prefectly! What's wrong here? Another thing - I now compiled X (R7.0) with the hardened gcc, whereas the old X (R6.8) I had to use the vanilla gcc... (there were no errors when compiling, but the X wouldn't want to load).
Created attachment 90949 [details] emerge --info My emerge --info
I'd say that's cause by the "fix" for Bug 70689.
Edit /etc/conf.d/xdm and change XSTATICVT -- does that "fix" your problem? If it does, please change it back and instead look in /etc/init.d/xdm for the line "after bootmisc readahead-list" and add consolefont to the end of the line. Try the same for keymaps.
Thanks, this worked. I changed in /etc/conf.d/xdm the XSTATICVT variable to "no". So it is now dynamically allocating the vt to use, right? What's the difference? In the meantime I found out that it really was using vt2 instead of vt7. I managed to restart KDM and X (by pressing as many keys as I could) and it suddenly worked. I logged in and looked at the Xorg.0.log and there it was: "(++) using VT number 2"... It seems to be "fixed" now - because it works. Although it seems to start up a little bit longer (about 2 seconds). BTW, my /etc/X11/xdm/Xservers file has lines like this: :0 local /usr/bin/X -nolisten tcp :0 vt7 :1 local /usr/bin/X -nolisten tcp :1 vt8 :2 local /usr/bin/X -nolisten tcp :2 vt9 for KDE (with X11 R6.8) I always used: :0 local@tty1 reserve /usr/bin/X -nolisten tcp :0 vt7 :1 local@tty2 reserve /usr/bin/X -nolisten tcp :1 vt8 :2 local@tty3 reserve /usr/bin/X -nolisten tcp :2 vt9 What is the right version here?
Ok, I changed in /etc/conf.d/xdm XSTATICVT back to "yes" and added the after statement in /etc/init.d/xdm and /etc/init.d/keymaps. /etc/init.d/xdm now looks like: after bootmisc readahead-list consolefont /etc/init.d/keymaps looks like: after consolefont (I had to add this line) This doesn't solve the problem, X still starts as vt2, the keyboad input doesn't work. My /etc/X11/xdm/Xservers: :0 local@tty1 /usr/bin/X -nolisten tcp :0 vt7 :1 local@tty2 reserve /usr/bin/X -nolisten tcp :1 vt8 :2 local@tty3 reserve /usr/bin/X -nolisten tcp :2 vt9 Now I changed back to dynamic VTs as this "works" for the time. Any suggestions? Should I re-emerge world or something?
I just noticed for the first time that you are using kdm, not xdm. Look around the kdm config files for a way to hardcode the VT it starts on.
I think this is a duplicate of bug #130916 (which is the exact same problem, but with wdm and gdm).
(In reply to comment #7) > I think this is a duplicate of bug #130916 (which is the exact same problem, > but with wdm and gdm). I've read through bug #130916 and I guess you're right. I've been lazy on this bug because after doing as described in my comment #5 everything is working so I'm not bothering with it any longer. If you tell me what I CAN do I can try to help to find out what this bug really is all about. Any suggestions?
No, I was wrong, this is not a duplicate. It seems that every login manager in existence has to be separately fixed to work with XSTATICVT=yes, and the fixes are different for each *dm.
*** Bug 144282 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > Thanks, this worked. I changed in /etc/conf.d/xdm the XSTATICVT variable to > "no". So it is now dynamically allocating the vt to use, right? What's the > difference? Also works for me with "wdm".
I've put xdm in the boot runlevel here with xorg-server-1.2.0-r3 and kdm-3.5.6 and I had no problem with the keyboard.
(In reply to comment #12) > I've put xdm in the boot runlevel here with xorg-server-1.2.0-r3 and kdm-3.5.6 > and I had no problem with the keyboard. If this service makes trouble in the future and you have it in runlevel boot, you cannot interactively disable this service (by pressing I for "interactive startup" when INIT is starting) and hence you have to repair you system from outside, e.g. with a Knoppix boot CD or similar. If your system root and all other partitions are encrypted (like mine are) then you have a lot - and I mean really A LOT - of work to do. So this might not be such a good idea, depending on your system configuration. Greetings, Andreas.
Okay, so here we are again. Recent update: x11-apps/xinit-1.0.4 with a new /etc/init.d/xdm and a new /etc/conf.d/xdm. The variable XVTSTATIC is gone, CHECKVT=7 is the new way of doing it. Probelm: It starts kdm on vt2 again, resulting in no keyboard being available. Only this time I wasn't able to do anything with the keyboard - it was and stayed DEAD. (refer to comment #0/desciption) Symptoms: If I take /etc/init.d/xdm out of the runlevels and start it manually from any console (vt1-6) it works correctly. Cheers, Andreas.
(In reply to comment #14) > Recent update: > x11-apps/xinit-1.0.4 with a new /etc/init.d/xdm and a new /etc/conf.d/xdm. > The variable XVTSTATIC is gone, CHECKVT=7 is the new way of doing it. > > Probelm: > It starts kdm on vt2 again, resulting in no keyboard being available. > Only this time I wasn't able to do anything with the keyboard - it was and > stayed DEAD. Roy, I believe this is your stuff.
Yes, it just checks that the defined VT is available on the system as "non statically in use". So if CHECKVT=7 but the DM is configured to use VT2 it's hardly going to work is it? The actual VT used depends on the DM itself, so if there is any error it is with the DM and/or it's config.
(In reply to comment #16) > Yes, it just checks that the defined VT is available on the system as "non > statically in use". So if CHECKVT=7 but the DM is configured to use VT2 it's > hardly going to work is it? > > The actual VT used depends on the DM itself, so if there is any error it is > with the DM and/or it's config. You are right. It works now. I'm sorry to have occupied your time. Explanation: My /usr/kde/3.5/share/config/kdm/kdmrc was very old (ConfigVersion=2.1) and there wasn't any VT set in it at all. Strange enought thath it used to work with the old xinit and with XSTATICVT set. I added: [General] ConfigVersion=2.3 StaticServers=:0 ReserveServers=:1,:2,:3 ServerVTs=-7 ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6 Now it works. Just like Roy Marples said, it has nothing to do with xinit and everything depends on the DM one uses. Thanks! FIXED
