From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-12 i686; en-US; 0.7) Gecko/20010316 Description of problem: We recently upgraded to nearly all of the rpms available for i686 system (including i386 packages) from the updates directory for Linux 7.1 on the RedHat FTP. Among these upgrades, a few of them were: Kernel-2.4.3-12 headers and sources (then compile and install) mouseconfig-4.22-1 Xconfigurator-4.9.29-1 Since linuxconf would not work on our system after our 6.2 - 7.1 upgrade, we also obtained the following from the linuxconf.org site: linuxconf-1.25r7-1 linuxconf-lib-1.25r7-1 linuxconf-gui-1.25r7-1 linuxconf-devel-1.25r7-1 gnome-linuxconf-0.65-1 I am not sure which is relevant here, but my guess is that the problem is with mouseconfig or Xconfigurator. There were also many other updates that were installed, but I seriously doubt there relevance at all. If necessary, I can leter list those in an update to this bug. We have a Microsoft IntelliMouse 1.2A PS/2 Compatible mouse. There is a specific driver for it listed in the It features a middle button which is also a roller that allows easy scrolling. It used to work very well in terminal windows, Midnight Commander, and Mozilla, as a few examples that I can recall off the top of my head that supported the feature. After the upgrade, they no longer worked. Upgrading to the older packages of mouseconfig and Xconfigurator found on the RedHat 7.1 CD using rpm -U --oldpackage [pkgs] causes erratic behavior in the mouse that completely disables any use of it in X-Windows. Upgrading back to the newer packages reinstates all mouse functions, except for the scroll roller. rpm -e --nodeps and rpm -i of the mouseconfig and Xconfigurator packages also fails to resolve this issue. How reproducible: Sometimes Steps to Reproduce: I say that it is not always reproducible because the steps to FULLY reproduce my situation are complicated. What's listed below is simple yet still difficult to do. Repetition has only been preformed on step 4,and that has failed show any results that differ from what I listed above. 1. Upgrade from RedHat Linux 6.2 to 7.1 2. Install 2.4.3 kernel from headers and sources 3. Install other updates for RedHat 7.1 from the ftp Updates directory. 4. Try reverting to the old rpms, erasing and installing the new rpms, etc. See Additional Information as well. Actual Results: Scroll roller failed to work on X-windows restart, or on reboot. Expected Results: Scroll roller should have worked. Additional info: The situation was more complicated than described actually. See bug # 47788 about the kernel issue. After the kernel problem was resolved and the other updates installed, for some reason, X-windows refused to load, and the output was unobtainable because it ran off of our screen. This led to: 1. a complicated re-upgrade from the CDs (twice actually) 2. noticing the erratic and completely unusable mouse problem on starting X-windows 3. carefully analyzing and upgrading the updates in stages rather than all at once, 4. experimenting with the mouseconfig and Xconfigurator upgrades to try to fix the mouse problem 5. reinstalling the kernel since the re-upgrade from CDs replaced our 2.4.3 headers and sources with version 2.4.2.
I am changing the status on this update from low to normal, as this is now defintitely a bug that should be fixed. As of this update, we are now having the erratic mouse problem in X-Windows while using the new mouseconfig and XConfigurator as well. It is intermittent but happens at least once a day. The mouse shoots up into the top right corner of the screen and resists moving back, and behaves as if buttons on the mouse are being pressed while we are trying to move it back. When we press CTRL-ALT-BACKSPACE to kill X-Windows, and end up back at the txt terminal mode, the mouse function is again restored. startx again, and the mouse continues working until the next attack of erratic behavior.
We have confirmed that our problem was caused by a combination of hardware and software problems. However, it is still, in my opinion, a software bug. I obtained another, similar mouse (different harware version, but same brand and model), and tried both mice on a Windoes 98 machine running the latest version of the Microsoft IntelliPoint driver software, available for free download. The scroll wheels on both mice worked perfectly. However, it was noticed that the mouse for our Linux machine would occasionally stop working. This was determined to be caused by a frayed cable, so our mouse must be replaced (or, we can build a new cable, but it's under warranty). When the test mouse that was lent to our group was tried on the Linux machine, no erratic behavior has been observed during normal use for two days. However, it was observed if the mouse was unplugged and then replugged during an X session, and the scroll wheel still failed to work, which was our original complaint. I decided to open up Xconfigurator and try changing our screen resolution. Once I did that, it worked. I changed the resolution back, and it still worked. My theory is that: 1. Our mouse somehow got changed to another type, which might have originally caused our erratic behavior problem. 2. When we tried to change our mouse back using mouseconfig, the configuration files for the X server or Xconfigurator or whereever they are stored for this needed to be reloaded, and mouseconfig does not do that appropriately force these files to be reloaded. Not even a reboot seemed to reload these files, but directly making changes to the video settings using Xconfigurator did. I am not sure what appropriate action must be taken to repair this, but the trouble definitely seems to lie somewhere between Xconfigurator and mouseconf. As a suggestion for an improvement, I think that it should be made possible for a user to at least accidentally unplug their mouse and have the ability to plug it back in and continue to use X-windows without having to kill it first to reobtain control of the mouse.
I have just completed a text mode interface for redhat-config-mouse, which means that mouseconfig will be deprecated in the next release of Red Hat Linux. Therefore, I will not be putting any development time towards fixing mouseconfig bugs, so I'm closing this as 'wontfix'.
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.