[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Keyboard lockup after X startup; possible cause


Several people probably faced the problem that after initial system bootup, 
and startup of *dm, keyboard does not work.
Suggested workaround was to add implicit 'vtX' parameter to X server 
command line in Xservers file.

I've never seen an explanation of what is actually hapenning, and why that 
workaround helps.

Recently I've installed kde 3.4 packages from experimental on one of my 
systems, and faced that keyboard problem again. And the suggested 
workaround was not possible, because it seems that newer kdm does not use 
Xservers file. After logging into system remotely, I found that X was 
started with 'vt2' parameter.

While trying to fix the situation, I probably guessed what is causing 

Unlike some other distributions, Debian treats *dm similar to other 
services, and starts it from /etc/init.d script while syste, startup. So 
*dm is started *before* getty's start for consoles.

Then *dm starts X server which may scan for a free vt (or, in case of 
recent kdm, it scans for a free vt itself).

At this point, there is a race. Either getty's fo vt2-vt6 are already 
started, and search result into "really free" vt, and everything goes ok. 
Or getty is not yet started, and X is started on vt on which later getty 
is started. In this case, getty "initializes" vt *after* X, and into some 
state incompatable with X, and keyboard no longer works.

I don't know which is the correct way to fix it.
Possible ways:

*) ensure that X is never started on vt on which getty is going to be 
started - in this case, having default Xservers files to set explicit vtN 
is enough, and kdm 3.4 should provide some way to ensure that it will not 
choose vt on which getty will be started later,

*) debian should not treat *dm like other services, and start it after 
getty's, not before them

*) some other way?


Attachment: pgpytfWTVPa0v.pgp
Description: PGP signature

Reply to: