solved? Re: [gdm-list] Keyboard becoming unresponsive?

[Simon Bowden <simonb cse unsw EDU AU>]

Hi,

Just a follow up. Some additional hunting around for this (and obviously 
getting the right search terms) gave a hint. I needed to change this line:

0=Standard

to this:

0=Standard vt7

If you don't explicitly specify the VT, then it starts anywhere?

Probably be good to note that if VTAllocation=false, then one really ought 
to specify an explicit vt, otherwise it'll probably take one that a getty 
has, and consequenlty lose keyboard.

Cheers,

 - Simon

On Fri, 23 Sep 2005, Simon Bowden wrote:

> Hi There,
>
> I'm currently testing GDM on a lab of 19 computers, and am finding that about 
> 5-6 per day have their keyboards lock up in the GDM login screen. If I 
> kill/restart gdm remotely, then the keyboard comes back to life and works in 
> the subsequent GDM session.
>
> We're running 2.6.0.8 from Debian sarge (Xfree86 X server), is anyone aware 
> of a problem like this being fixed in the interim? Or perhaps of things that 
> might cause it?
>
> I fiddled around with options etc, and couldn't easily reproduce it.
> I have a suspicion that it is likely to happen on boot, but not subsequently.
>
> The keybaord is very dead - the capslock/numlock etc lights are off and do 
> not toggle when pressing keys. Replugging it in (PS/2) does not help - only 
> restarting gdm (or rebooting) helps.
>
> Maybe worth noting is that I have:
> FirstVT=7
> VTAllocation=false
>
> in the config file. I want it to use vt7, but sometimes it seems to use VT8, 
> no idea why.
>
> Cheers,
>
> - Simon
> _______________________________________________
> gdm-list mailing list
> gdm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gdm-list