Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 4672

Summary: mouse problem after switching between text and graphic display screens
Product: [Retired] Red Hat Linux Reporter: Vlado Potisk <reg.bugs>
Component: XFree86Assignee: David Lawrence <dkl>
Status: CLOSED WORKSFORME QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-09-09 09:32:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Vlado Potisk 1999-08-23 17:57:01 UTC
I'm using two-button mouse manufactured by Microsoft and
Mach64 graphics adapter. I'm running KDE.

I have X display on console screen #12; the bug can be
triggered by switching to the text console on screen #1 by
pressing Ctrl-Alt-F1 and then returning back by pressing
Ctrl-Alt-F12. It happens less frequently also in other
situations that I can't duplicate for now.

The most visible symptoms are:
- the mouse pointer doesn't change when moving it over
  various parts of the screen
- mouse clicks (left or right button) are ignored
These problems go away after clicking both buttons
simultaneously (which pastes some unwanted input to the
active window), but there are still other problems
that persist:
- unable to change focus by clicking on the window,
  must click on the window frame
- some menus are unusable, notably the menus in
  ghostview and menus in xterm which are invoked by
  pressing Ctrl + some mouse button. The menu
  is there, but no item can be chosen.

I haven't found any way to reset the mouse behavior
back to normal except restarting X.

Comment 1 Preston Brown 1999-09-01 01:01:59 UTC
I was having the *exact* same problem myself!  The problem appears
solved with the forthcoming XFree86 3.3.5 errata release.  If it is
not solved for you after you obtain and upgrade to the 3.3.5 errata,
please re-open this bug.

Comment 2 Vlado Potisk 1999-09-15 08:20:59 UTC
I do reopen this bug as instructed. Nothing changed after
upgrading to XFree 3.3.5 from Updates or from RawHide.

Comment 3 Preston Brown 1999-09-23 20:08:59 UTC
this was fixed by the XFree86 3.3.5 errata release.

Comment 4 Vlado Potisk 2000-03-18 00:03:59 UTC
Neither 3.3.5-errata nor 3.3.6 helped me. I considered this bug quite
annoying and found finally a workaround.

I realized that X server closes and reopens the serial port /dev/mouse
when doing VT switching. In order to prevent resets of this port I run
a process which keeps it open (e.g. sleep 100000 > /dev/mouse). Since
then I have no problems.

Note: I am not using gpm daemon.

Comment 5 SharpFang 2000-09-09 09:31:57 UTC
I had similar problems and I found the reason: This is a conflict between GPM
and X - GPM doesn't give back the control over the mouse. 
Workaround: Before getting back to X kill GPM using 'gpm -k' command. You may
want to remove GPM from inittab, start it manually when you need it and kill it
when going back to X.

Comment 6 openshift-github-bot 2017-07-25 01:47:17 UTC
Commits pushed to master at https://github.com/openshift/openshift-docs

https://github.com/openshift/openshift-docs/commit/2afa4dc9980ad65edf0493aa902c3152384fcef8
Changed recycle policies to reclaim policies, fixed issue 4672

https://github.com/openshift/openshift-docs/commit/bb29d6deee30bba0d97fd13fe470e1c8ec778d45
Merge pull request #4760 from gaurav-nelson/ForIssue4672

Changed recycle policies to reclaim policies, fixed issue 4672