This problem did not exist in 2.4. It only showed up with I switched to
kernel 2.6. And because of the restarts of GPM and X not fixing it, I
suspect it is a kernel issue. But there are sufficient things about how
the mouse works that I have never been able to find documentation for to
really understand just what the cause could be.

I run gpm as follows:
/usr/sbin/gpm -t ps/2 -3 -r 8 -R

Xorg has the following section of the config file:

Section "InputDevice"
Identifier "Mouse1"
Driver "mouse"
Option "Protocol" "mousesystems"
Option "Device" "/dev/gpmdata"

And XFree86, which I used when I transitioned from 2.4 to 2.6, had the
same thing.

Everything runs fine until the mouse is unplugged or switched. When I
switch back, GPM no longer works. That seems silly, but I suppose that
aspect could be blamed on GPM. I kill and restart GPM and then I can
see mouse movements again. However, everything is _much_ slower even
though I use the same rate option (-r 8). Repeated kills and restarts
don't improve things. In rare instances, many kill/restart cycles will
cause the mouse to be permanently dead until a reboot.

If I restart GPM with -r 24 or -r 32 then I get back to about the same
movement rate as I had before the first unplug with -r 8, as seen on
the text console. However, under X, the speed gets quite radical even
though with -r 8 it was too slow under X as on the console. It seems
that setting the rate to 3x what it was has less effect on the console
and more effect on X. Additionally, there is another effect on X which
is that the cursor now jumps around backwares a lot. I suspect this
could be due to the rate now being so high the mouse indexing overflows
before X can seen enough events to know it didn't move the other way.

Rebooting the kernel always fixes it. Changing the -r options only
awkwardly compensates for it ... no -r level can achieve the original

I'm now at 2.6.18 and there's no change in the problem.

When I unplug the mouse and/or keyboard from Windows 98 and plug them
back in, they work just fine. It seems there is something in this case
that Microsoft actually got right, although I don't know if that is
still the case in recent versions of Windows.

As a side note, I have found that Intel, a company that supposedly would
have a lot of technically smart people on staff, makes motherboards that
have serious issues with PS/2 mice. I've noticed this on every motherboard
made by Intel that I have tried (3 different ones). I even reached someone
at Intel tech support about this and they simply said it is not supported.
The issue is, when I boot up any OS on an Intel motherboard with the mouse
and keyboard both not plugged in, then try to plug them in later while the
OS is running, the mouse causes a flood of strange keyboard activity, while
the keyboard is entirely non-functional. It's like the roles of the two
PS/2 connections got reversed, even though I'm plugging them in correctly
(I checked this so many times to be sure). I then tried to reverse them
in this scenario to see what would happen, but then both did not work at
all. Intel's position is that they don't support them being unplugged,
either before booting, or after (altough if done afterwards, the only
issue I have is the once with the Linux kernel described above). With
motherboards from ASUS, there has never been any such problem; they work
fine with the mouse and keyboard only plugged in after the system is up,
aside from the Linux kernel issue above.

It seems the mouse, and perhaps the keyboard, too, is a technology that
is very hard to get right. Anyone know what's so hard about it?

Would a USB mouse and USB keyboard work any better if plugged in after
the system is booted, or unplugged and replugged, or otherwise switched
with a KVM switch? At this point, all my machines now do have a USB
port or 2, so I could switch to USB ones (if I could find a keyboard with
nice solid keys like the Keytronic one I have now for PS/2 which has
served me well for 10 years).

And anyone know what's up with mouse support in the kernel? Would a USB
mouse get around it? Could it be that the driver in the kernel messes
with the serial baud rates the wrong way and will never reset to initial

| Phil Howard KA9WGN ( / Do not send to the address below |
| first name lower case at / |