Comment 5 for bug 532047

I've been progressively disabling the input devices to discover if one of them may be the culprit via "/lib/udev/rules.d/65-xorg-evdev.rules" until everything but the GlidePad was disabled:

$ egrep '(Adding input device|PreInit)' /var/log/Xorg.0.log
(II) config/udev: Adding input device "AlpsPS/2 ALPS GlidePoint" (/dev/input/event8)

Using the GlidePad I clicked on the user-name to log-in, then began typing the password ("my2pennies4"). No password input markers show up (since the keyboard is not driven by evdev) *BUT* as soon as I press the "2" xserver crashes.

This seems to confirm that *something* is attached to tty7 and is processing the input instead of evdev - and then quitting (the SIGQUIT [signal 3] reports seem to confirm that).

This is the hacked udev rules file used at this point.

----- /lib/udev/rules.d/65-xorg-evdev.rules -----
ACTION!="add|change", GOTO="xorg_evdev_end"

# By default, we use the -evdev driver for every mouse, keyboard, touchscreen
# or touchpad; later rules can then change the driver for specific input
# devices.
ENV{ID_INPUT}=="", GOTO="xorg_evdev_end"
ENV{ID_INPUT}!="", GOTO="xorg_evdev_end"

ATTRS{name}=="Video Bus", GOTO="xorg_evdev_end"
ATTRS{name}=="Macintosh mouse button emulation", GOTO="xorg_evdev_end"
ATTRS{name}=="PS/2 Mouse", GOTO="xorg_evdev_end"
ATTRS{name}=="Sony Vaio Keys", GOTO="xorg_evdev_end"
ATTRS{name}=="Power Button", GOTO="xorg_evdev_end"
ATTRS{name}=="AlpsPS/2 ALPS GlidePoint", KERNEL=="mouse*", GOTO="xorg_evdev_end"
ENV{ID_INPUT_MOUSE}=="?*", ENV{x11_driver}="evdev"
ENV{ID_INPUT_KEY}=="?*", ENV{x11_driver}="evdev"
ENV{ID_INPUT_TOUCHSCREEN}=="?*", ENV{x11_driver}="evdev"
ENV{ID_INPUT_TOUCHPAD}=="?*", ENV{x11_driver}="evdev"

LABEL="xorg_evdev_end"