Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 12179 - X config "Test" button locks interface
X config "Test" button locks interface
Status: CLOSED DUPLICATE of bug 15084
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Matt Wilson
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2000-06-12 22:32 EDT by Chris Adams
Modified: 2005-10-31 17:00 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-08-17 17:22:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Chris Adams 2000-06-12 22:32:33 EDT
When I clicked the "Test this configuration" button during the X config
(graphical install), I got the test screen.  However, after I clicked that
the display was okay and I got the installer back, the "Test" button was
still depressed.  I could not click on anything else (nothing happened when
I did).

I could get to other consoles with Ctrl-Alt-Fn.  I went back to the
installer console.  It was still the same (clicks did nothing), except that
when I clicked on the (still depressed) "Test" button, it did the X test
again.  I again clicked the okay button, and after I got back to the
installer I could not do anything else.  The mouse cursor moved around, but
clicking did nothing, and the keyboard wouldn't either.

I suspect the problem is that I have a Logitech MouseMan+.  The installer
uses it as a generic PS/2 mouse (since you don't get the option to select
your mouse until after you are in X).  When the X configuration is tested,
it probably uses the selected mouse protocol.  The MouseMan+ protocol is
incompatible with the regular PS/2 protocol as I understand it, so I guess
the problem is that once the mouse is switched into MouseMan+ mode it
doesn't automatically go back to PS/2 protocol (this is just from my
experience: I know you cannot use gpm on a console talking PS/2 proto and X
on another VC talking MM+).

A couple of solutions come to mind:
1) Restart X if a different mouse type is selected (kind of ugly, but maybe
not a bad idea if the installer guesses wrong and someone uses the keyboard
to choose a mouse type).
2) Use the same mouse protocol for the "Test this configuration" button
that is already being used by the installer.
3) Even uglier solution: try to probe for mouse type _before_ starting X
and allow the user to override.
Comment 1 Chris Evans 2000-06-17 13:33:34 EDT
I, too, hit this bug.
I also have a Logitch mouse. Not sure of the exact type. Says M-C48 underneath.

The installer autodetected the mouse as a PS/2, which is fine. Unlike the
original filer, I did _not_ change the type of mouse because it works fine.

The installer hanging strikes me as a pretty serious bug - maybe the severity
should be bumped up to "high"?
Comment 2 Chris Evans 2000-06-26 18:06:05 EDT
Argh! I hit this again with BETA2 (version updated)
Severity updated -> it's a royal pain. Killing the installer is very serious.
Comment 3 Nitin Dahyabhai 2000-06-28 00:10:53 EDT
Doesn't kill installer for me, but mouse input becomes
erratic after X returns (cursor acts spastically along
top of screen only).  This from using a Logitech
Cordless Wheel Mouse with the Intellimouse PS/2
protocol, as usual.
Comment 4 Hans de Goede 2000-07-09 17:57:32 EDT
I believe this bug really are 2 bugs:
-some people loose mouse cotnrol after testing X, because:
 -installer X probed a mouse and uses this
 -user selected different (wheelmouse (imps/2) ) protocol
 -test X uses different protocol, works
 -return to installer X
 -mouse is in new protocol mode
 -loose mouse control
-some people see a complete hang after testing X

I belive that the first is a duplicate of bug 12084
Comment 5 Glen Foster 2000-07-18 14:36:39 EDT
This defect is considered MUST-FIX for Winston Beta-5
Comment 6 Glen Foster 2000-07-21 14:39:18 EDT
Does this defect still exist with (on) Winston beta-4?
Comment 7 Matt Wilson 2000-07-24 21:41:32 EDT
A fix is in CVS, needs verification
Comment 8 Hans de Goede 2000-07-27 15:31:25 EDT
The part of this bug, which was caused by the mouse being in wheelmouse mode
after testing is now fixed, see bug 12084
Comment 9 Chris Evans 2000-07-31 18:31:29 EDT
Still affects BETA5 - killed the installer on me :-(
To recap
- Mouse is detected as"Generic PS/2"
- I DON'T change this
- Pressing "Test X" button leads to locked interface on return to installer
- Mouse moves around OK, but no click gets any response
- "Test X" button remains depressed
Comment 10 Matt Wilson 2000-07-31 19:37:29 EDT
What kind of video card please?
Comment 11 Chris Evans 2000-07-31 19:54:14 EDT
3dfx Voodoo3 2000 PCI
(Mouse is Logitech M-C48)
Comment 12 Matt Wilson 2000-07-31 20:49:27 EDT
It's the voodoo that's causing the problem now, I'm almost positive (I've seen
Comment 13 Chris Adams 2000-07-31 21:50:53 EDT
Good chance - that's what I have too (Voodoo3 3000).  I've
also got a Logitech MouseMan+ PS/2 (M-CW47).

I haven't had a chance yet to try beta5 (just got the CDs
today), but it doesn't look like there will be any difference.
Comment 14 Aaron Brown 2000-08-04 14:40:31 EDT
Bill said the fix will not make it into this release.  The work-around is
to *not* test X during the GUI install.
Comment 15 Michael Fulbright 2000-08-17 17:22:32 EDT

*** This bug has been marked as a duplicate of 15084 ***

Note You need to log in before you can comment on or make changes to this bug.