Bug 12179 - X config "Test" button locks interface
Summary: X config "Test" button locks interface
Status: CLOSED DUPLICATE of bug 15084
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
high
high
Target Milestone: ---
Assignee: Matt Wilson
QA Contact: Brock Organ
URL:
Whiteboard: beta5
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-06-13 02:32 UTC by Chris Adams
Modified: 2005-10-31 22:00 UTC (History)
3 users (show)

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


Attachments (Terms of Use)

Description Chris Adams 2000-06-13 02:32:33 UTC
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 17:33:34 UTC
Greetings-
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 22:06:05 UTC
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 04:10:53 UTC
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 21:57:32 UTC
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 18:36:39 UTC
This defect is considered MUST-FIX for Winston Beta-5

Comment 6 Glen Foster 2000-07-21 18:39:18 UTC
Does this defect still exist with (on) Winston beta-4?

Comment 7 Matt Wilson 2000-07-25 01:41:32 UTC
A fix is in CVS, needs verification


Comment 8 Hans de Goede 2000-07-27 19:31:25 UTC
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 22:31:29 UTC
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 23:37:29 UTC
What kind of video card please?


Comment 11 Chris Evans 2000-07-31 23:54:14 UTC
3dfx Voodoo3 2000 PCI
(Mouse is Logitech M-C48)

Comment 12 Matt Wilson 2000-08-01 00:49:27 UTC
It's the voodoo that's causing the problem now, I'm almost positive (I've seen
this).


Comment 13 Chris Adams 2000-08-01 01:50:53 UTC
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 18:40:31 UTC
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 21:22:32 UTC

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