Bug 49149

Summary:	mouseconfig no longer allows scroll wheel to work
Product:	[Retired] Red Hat Linux	Reporter:	William M. Quarles <walrus>
Component:	mouseconfig	Assignee:	Brent Fox <bfox>
Status:	CLOSED WONTFIX	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.1
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-02-21 18:48:03 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description William M. Quarles 2001-07-15 21:16:31 UTC

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.

Comment 1 William M. Quarles 2001-07-17 19:30:07 UTC

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.

Comment 2 William M. Quarles 2001-07-24 22:25:00 UTC

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.

Comment 3 Brent Fox 2002-10-10 18:15:27 UTC

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'.

Comment 4 Red Hat Bugzilla 2006-02-21 18:48:03 UTC

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.