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 How Reproducible: 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. 1. 2. 3. Actual Results: Expected Results: Additional Information:
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 other device. Mike
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. Thanks.
Thank you for your suggestion. Unfortunately, IMPS/2 does not work with the IBM trackpoint either. The mouse displays the same problems. Mike
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, Mike
ok, I tried the following protocols: "auto" "MouseManPluxPS/2" "PS/2" "IntelliMouse" "GlidePoint" "GlidePointPS/2" "IMPS/2" "ExplorerPS/2" "ThinkingMouse" "ThinkingMousePS/2" "NetMousePS/2" 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, Mike
Does it behave better if gpm is turned off?
no, disabling gpm did not seem to make a difference. Mike
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: xpert and xfree86 with full details of the problem.