Red Hat Bugzilla – Bug 62886
mouse behaviour erratic under X/GNOME on IBM Thinkpad R31
Last modified: 2007-04-18 12:41:44 EDT
Description of Problem:
Using X on a Thinkpad R31 laptop (i830 chipset, using the i810 driver in my
XF86Config), the mouse will skip erratically across the screen, jumping the
entire width of the screen and randomly popping up menus.
Version-Release number of selected component (if applicable):
default X versionfrom skipjack2
every X session
Steps to Reproduce:
startx and move some windows, try to select things off the menus, ...
The mouse skips all around the screen.
I forgot to add that the trackpoint mouse did not work in the graphical
installer. It worked for the first few screens, and then would pull all the way
to one side of the screen. I needed to do the install in text mode. This
behavior was not noticed in the RH 7.2 installer, only 7.2.93. Addtionally, the
trackpoint mouse fine under Windows XP.
/proc/interrupts shows that the mouse is on IRQ 12, which is not shared with any
This often occurs in many recent versions of Linux when you accidentally set
your non-wheel PS/2 mouse to be a wheel mouse. Your trackpad is a 2 button
PS/2 mouse. There are no options to set it as such?
This is a trackpoint mouse, not a trackpad, and it has 3 buttons, not 2. I have
tried selecting many of the PS/2 mouse devices besides the generic 3-button PS/2
device, and non of them worked.
I do not have access to this hardware, so there isn't anything I can
do about it, other than request you attach a config file that works
properly with this mouse, and we can change the configuration tools
to spit out a config that works for this mouse.
I suggest trying IMPS/2 as the mousr protocol type, and see if that works.
Please update the report ASAP, so we have time to make changes.
Thank you for your suggestion. Unfortunately, IMPS/2 does not work with the IBM
trackpoint either. The mouse displays the same problems.
The problems you are describing sound entirely like configuration problems
to me, however it isn't possible to tell without access to the hardware.
Can you manually configure the mouse by editing /etc/X11/XF86Config and
trying various different mouse protocol types as listed in the XFree86
mouse manpage? You say it worked with 7.2.. could you try using the
config file from 7.2 and see if that works? Please attach config
file from 7.2 that works, and let me know if it works with skipjack also.
yes, I will go ahead and try all of those protocols one at a time and see if any
of them work.
I said that the mouse worked fine in the graphical install program for Redhat
7.2. Unfortunately, my video chipset (Intel 830) was not supported in 7.2, so I
was unable to try it out in X under Redhat 7.2. This is why I tried 7.2.93.
The mouse did not work in the graphical installer of 7.2.93 after the first few
screens. It began exhibiting the same problems that I see with X in 7.2.93 --
erattic behavor to the point where it is unusable.
I'll let you know how the testing above goes.
Thank you for your assistance,
ok, I tried the following protocols:
some of them did not work at all. Most exhibited the same sort of problems as I
originally reported (erratic behavior, the cursor jumps across the screen
unexpectedly, random menus pop up as the cursor moves).
The most well behaved protocol seemed to be MouseManPlusPS/2, but this still
echibited problems. I also tried seeing Option "SWCursor" "on" in my
XF86Config-4, but that did not help.
I found this bug (number 62687;
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62687) that discusses very
similar behavior to what I am seeing when gpm is turned off. On my machine, gpm
is running, so this may not be directly related.
Thank you for your continued help,
Does it behave better if gpm is turned off?
no, disabling gpm did not seem to make a difference.
Without direct access to the specific hardware with which the problem is
being observed, it is rather impossible to debug/troubleshoot this further
or try to find a resolution.
Please report this bug directly to XFree86 upstream, so the mouse driver
maintainer(s) themselves can dig into the problem, determine wether or
not it is a software issue, a hardware issue, or something else, and perhaps
provide a fix in a future X release.
I recommend emailing both: firstname.lastname@example.org and email@example.com with
full details of the problem.