|Summary:||mouse problem after switching between text and graphic display screens|
|Product:||[Retired] Red Hat Linux||Reporter:||Vlado Potisk <reg.bugs>|
|Component:||XFree86||Assignee:||David Lawrence <dkl>|
|Status:||CLOSED WORKSFORME||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2000-09-09 09:32:02 UTC||Type:||---|
|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