>I have had this problem too. My solution was that I had gpm
>running along with X Windows and they did not seem to like each
>other. Removed gpm from the rc files, rebooted and it worked
>fine.
That explains the funny behaviour very well. The PS/2 mouse
driver does not interpret the stream of data coming from the
mouse at all, but hands it all over to the user space
process(es) reading the device. This it does according to the
principle "don't bloat the kernel".
The mouse typically sends movement data in packets of three
bytes. If two processes compete for the data (which wasn't even
allowed some time ago), there is a possibility that a packet is
split up, so that one process gets the start of the packet, and
the other one gets the rest. Both processes lose sync. The X11
server is supposed to have some code trying to detect this
condition, but apparently it isn't working very well. Note that
serial mice should also have this problem; maybe the heuristic
is working better with the serial protocols?
Fixing this would require the driver to start interpreting the
stream of bytes coming from the mouse, and always return data to
the reading process on packet boundaries. This could be every
third byte, or it could be something else for the latest
wheel-mouse-of-the-week. In fact, the packets could even be
of variable length, or the device connected to the PS/2 port
might not be a mouse at all.. The device driver tries to be as
generic as possible, and let's user space sort it all out.
A solution to the problem is to use gpm in server mode.
Johan Myreen
jem@iki.fi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/