Thanks for the quick response. [Eric Van Buggenhaut] > Option "Protocol" "auto" > Option "ZAxisMapping" "4 5" > Option "Device" "/dev/psaux"
Aha. Your configuration is difficult to support properly, and probably results in a short delay when switching between X and console, since doing so involves reinitialising the mouse. That's because, with both gpm and X having direct control of the mouse, they defensively have to make sure the mouse is in a known state, every time. This approach does work, modulo bugs in XFree86 or gpm; I've just never been comfortable with it. > > The other thing to check, if possible - did gpm 1.19.6-19 pick up your > > /etc/gpm.conf settings and write them back correctly? > > No, it didn't. More specifically, it added 2 lines: > > repeat_type=ms3 > append='' Yeah, repeat_type is the culprit. The upgrade noticed that it was not set, so it used the default. In your case you're relying on gpm's behavior when the repeater is disabled. Fix / workaround: repeat_type=none You can either edit gpm.conf directly, or via 'dpkg-reconfigure gpm'. Please let us know whether this fixes your problem. (repeat_type='' would work too, but that would cause the same problem on the next upgrade, until we figure out the right way to handle this case.) Incidentally, the other workaround is to boot any kernel 2.6, whose input layer prevents this type of problem from occurring in the first place, by virtualising /dev/psaux entirely. If you do that, you'll need to ensure that the 'mousedev' and 'psmouse' kernel modules get loaded. Thanks again, Peter
signature.asc
Description: Digital signature
