Ok, This is for anyone having problems with their keyboard not working when xwindows/gdm etc. starts. I got this from gentoo so i'm not totally sure if it will work on all other distros.(I will tell you if the keyboard stops working again on my suse 10.1 comp.)
I don't clearly understand all of this but if actually read it(i didn't) then you should get the idea.
Code:
# This is here to serve as a note to myself, and future developers.
#
# Any Display manager (gdm,kdm,xdm) has the following problem: if
# it is started before any getty, and no vt is specified, it will
# usually run on vt2. When the getty on vt2 then starts, and the
# DM is already started, the getty will take control of the keyboard,
# leaving us with a "dead" keyboard.
#
# Resolution: add the following line to /etc/inittab
#
# x:a:once:/etc/X11/startDM.sh
#
# and have /etc/X11/startDM.sh start the DM in daemon mode if
# a lock is present (with the info of what DM should be started),
# else just fall through.
#
# How this basically works, is the "a" runlevel is a additional
# runlevel that you can use to fork processes with init, but the
# runlevel never gets changed to this runlevel. Along with the "a"
# runlevel, the "once" key word means that startDM.sh will only be
# run when we specify it to run, thus eliminating respawning
# startDM.sh when "xdm" is not added to the default runlevel, as was
# done previously.
#
# This script then just calls "telinit a", and init will run
# /etc/X11/startDM.sh after the current runlevel completes (this
# script should only be added to the actual runlevel the user is
# using).
#
# Martin Schlemmer
# aka Azarah
# 04 March 2002
note: This seems to be a fix for gdm/kdm/xdm. but i had a keyboard problem on suse where even if i changed to runlevel three and typed startx(bypassing gdm) then my keyboard still wouldn't work. I don't know if it would fix that also.