Bug 14092 - kudzu kicks in when nothing changed with mouse
Summary: kudzu kicks in when nothing changed with mouse
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kudzu
Version: 7.1
Hardware: i386
OS: Linux
low
low
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-07-17 08:23 UTC by Telsa Gwynne
Modified: 2014-03-17 02:14 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2000-07-18 16:28:01 UTC
Embargoed:


Attachments (Terms of Use)

Description Telsa Gwynne 2000-07-17 08:23:19 UTC
Installed Winston beta 3. During install process, told it I
had a mousesystems mouse. .Started X, realised I hadn't 
toggled the little switch on the bottom of the mouse, toggled
that, it then worked properly. Then later crashed machine.
Following fsck, kudzu popped up, complaining about  a
vanished mouse. I don't know whether this was due
to X crash, or to toggling the whatever-it-is underneath
the mouse. Suggestion from husband: "probably trying to
be too clever: this is a mousesystems mouse with no 
plug and play identifiers on it".  The mouse was definitely
still there. Really.

Subsequent crashes and fscks didn't produce kudzu so
whether this a one-off, because I fiddled with the button
beneath, or what, I dunno.

Comment 1 Bill Nottingham 2000-07-18 16:28:00 UTC
Um, changing the button on the mouse will most likely change how it responds
to the probes.

Did it actually reprobe as something else ("Generic Serial Mouse", for example?)

Comment 2 Bill Nottingham 2000-08-16 02:31:07 UTC
Closed; lack of input. Also, if the mouse changed protocols,
it probably will reprobe as something different, and
there's not much I can do about it.


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