After the XF86 server configuration is done and the XF86Config-4 file written, there is (even if a mouse is correctly configured) a section "InputDevice" with the identifier "Generic Mouse" IN ADDITION to the "Configured Mouse" entry. This leads (at least on my system) to a problem when I'm using gpm and X. The mouse works fine with gpm on any terminal until X is started. After that (when I switch to another terminal) the mouse is gone. When I delete the "Generic Mouse" entry (actually the whole Section for the is entry) everything works perfect. It is now possible to switch from X to a terminal and back and the mouse works everywhere. Possible solution for this problem: The XF86Config-4 file should not include the "Generic Mouse" Section and the correspondending InputDevice in the "Server Layout" should be deleted. Nikolaus Regnat
reassign 129215 gpm retitle 129215 "gpm: spews noise to /dev/input/mice" thanks Yes, there is another mouse section IN ADDITION. This is DELIBERATE. It is so that people can TAKE ADVANTAGE of multiple pointers attached to the system via the USB interface. This is NOT AN ACCIDENT. You might want to look into fixing your keyboard; the caps lock key appears to have some sort of intermittent problem. This sounds like a bug in gpm. I suggest dpkg-reconfiguring xserver-xfree86 to not manage the config file with debconf if this bug cannot be fixed in gpm. No, that is 100% incorrect and just makes life harder for users who want their mice to work.
Sorry for getting mad at you; I didn't realize you weren't trying to be pedantic with me. If you can reproduce this bug without gpm running, then it is a bug in the X server. You should make sure you are using gpm as a repeater if you want to keep it running while the X server is running. The two programs have a long history of non-cooperation unless special care is taken by the user.
I require the actual gpm.conf and XF86Config-4 in question. Barring this I will relabel this an obvious X bug with a known fix. Zephaniah E. Hull.
That's bullshit and you know it. If your package corrupts the protocol stream on a device node, that's its fault, not the X server's.