Hello. 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 lockups. 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? Nikita
pgpuuKige4TW4.pgp
Description: PGP signature
