Red Hat Bugzilla – Bug 12179
X config "Test" button locks interface
Last modified: 2005-10-31 17:00:50 EST
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 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.
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"?
Argh! I hit this again with BETA2 (version updated)
Severity updated -> it's a royal pain. Killing the installer is very serious.
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.
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
This defect is considered MUST-FIX for Winston Beta-5
Does this defect still exist with (on) Winston beta-4?
A fix is in CVS, needs verification
The part of this bug, which was caused by the mouse being in wheelmouse mode
after testing is now fixed, see bug 12084
Still affects BETA5 - killed the installer on me :-(
- 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
What kind of video card please?
3dfx Voodoo3 2000 PCI
(Mouse is Logitech M-C48)
It's the voodoo that's causing the problem now, I'm almost positive (I've seen
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.
Bill said the fix will not make it into this release. The work-around is
to *not* test X during the GUI install.
*** This bug has been marked as a duplicate of 15084 ***