no mouse/keyboard when using evdev and autologin in gdm

[Fabien Tassin]

Binary package hint: gdm

When using automatic login in gdm, X starts but the mouse and the keyboard are frozen (as in ignored by X), yet they are alive (leds are fine). If I ssh-in from a remote computer and kill Xorg, I'm back in gdm, I can login manually and it's all fine.
I'm using evdev.

this is 100% reproducible here.

Attached my Xorg.0.log just before I killed Xorg.

ii xserver-xorg 1:7.4~1ubuntu1
ii xserver-xorg-core 2:1.4.99.906-2ubuntu5
ii xserver-xorg-input-all 1:7.4~1ubuntu1
ii xserver-xorg-input-evdev 1:2.0.3-2
ii xserver-xorg-input-kbd 1:1.3.1-1ubuntu2
ii xserver-xorg-input-mouse 1:1.3.0-1build1
ii gdm 2.20.8-0ubuntu1

Linux ix 2.6.27-2-generic #1 SMP Thu Aug 28 17:20:02 UTC 2008 i686 GNU/Linux

[Sebastien Bacher (seb128)]

the issue is not a gdm one, gdm only starts the session

[Amael (amael)]

Hello,

I nearly have the same problem, but I don't use autologin. No mouse/keyboard support, and I use evdev. I also first tried to kill Xorg, but then I noticed that I have two GDM launched ! Thus, by typing "sudo /etc/init.d/gdm restart", my gdm reloads and keyboard+mouse are fully functionnal.

I'm searching for two days now on Ubuntu forums to see if other people have the same problem, and it's possible that yes but nearly no one tested how many gdm instances they have. Haven't found a permanently solution for now.

Amael

[Bryce Harrington (bryce)]

[This is an automated message]

Hi fta,

Please attach the output of `lspci -vvnn` too.

[Fabien Tassin (fta)]

still happening in jaunty, autologin or not.

[Albert Damen (albrt)]

Fabien, the error message in your X log "(EE) config/hal: couldn't initialise context: (null) ((null))" looks similar to bug 264256. It seems gdm may be started before hal for you as well. That would also explain why a gdm restart works fine.

Can you please check the sequence numbers of the symlinks Sxxgdm and Syyhal in /etc/rc2.d?
If the sequence number for gdm is lower then for hal, can you try if correcting the sequence numbers solves your problem? On my Jaunty system gdm uses S30gdm and hal uses S24hal.

[Fabien Tassin (fta)]

Albert, indeed, gdm is lower than hal.

fta@ix:~ $ ls -l /etc/rc2.d | grep -E '(gdm|dbus|hal)'
lrwxrwxrwx 1 root root 14 2008-02-29 15:02 S12dbus -> ../init.d/dbus*
lrwxrwxrwx 1 root root 13 2007-02-06 04:27 S14gdm -> ../init.d/gdm*
lrwxrwxrwx 1 root root 13 2008-05-09 14:34 S24hal -> ../init.d/hal*

so it seems my gdm link hasn't been updated at some point.

on another box (recent), I have:
fta@cube:~ $ ls -l /etc/rc2.d | grep -E '(gdm|dbus|hal)'
lrwxrwxrwx 1 root root 14 2008-11-17 14:05 S12dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root 13 2008-11-17 14:05 S24hal -> ../init.d/hal
lrwxrwxrwx 1 root root 13 2008-11-17 14:05 S30gdm -> ../init.d/gdm

now that I remember it, i touched those files a long time ago for bug 164365.

[Albert Damen (albrt)]

GDM will only update the symlink for specific combinations of sequence number / old gdm version, so it knows the symlink was not updated by the system administrator. In this case, you changed the symlink yourself, so gdm is not supposed to update it.

[Fabien Tassin (fta)]

@Albert, I know enough about packaging, trust me.

btw, it seems I'm not alone in that case. I just found out it's even documented:

https://wiki.ubuntu.com/X/Config/Input#Troubleshooting

gdm should do better here.