Undefined wrote:

First, a little bit of advice:  consider breaking up your messages into
discrete paragraphs.  This stuff is a bit hard to read :-)

> Okay.  Here I am, on my IIcx running 1.2 -current from late September, with
> an old Apple extended keyboard and one of those newer, rounded-off-looking
> Apple mice attached to it (I've been running MacBSD for well over a year now
> and have never had *any* problem related to ADB whatsoever). 

Can you show us the top 20 or so lines from a 'dmesg' on this machine?
Basically, I just wanted a better idea of what version of -current you
were using and what ADB driver you're using (as well as how it handles
recognizing your mouse).

> Just a few
> moments ago, I wished to select and copy some text in dt, so I hit Command-P
> to bring up the cursor and go about my business.  However, what happened was
> dt acted as though I were holding down the mouse button, when in fact
> I had yet to even touch the thing.  Odd, I thought to myself, but I assumed
> I had perhaps brushed it lightly with my finger or something, and attempted
> to finish the selection with another click.  Nothing happens.  Text still
> highlighted, following the cursor around as though the button were down.
> This is not good.  I hit some keys.  Sure enough, the keyboard is completely
> unresponsive.

This sounds _really_ odd.  Either the internal software state of the ADB
driver managed to hang somewhere (not likely, but who knows???) or else
the hardware is going a bit bad...

> Bad bad bad.  After an initial panic, I tried hitting Command-
> P again to shut the mouse off, which returned control of my keyboard to me (
> I was, however, unable to switch VT's with Command-2, etc). 

That's even more odd.  Perhaps you need to recompile dt?

> I tried going
> back into mouse mode again, and the same thing happened. 

Is this behavior entirely reproducible?  I mean, does this happen every
time you do this?

> So from that one
> VT I was left with, I killed off dt and tried every bit of voodoo I could
> think of, from catting garbage to /dev/adb

BTW, this last won't do anything useful.  /dev/adb doesn't support reading
or writing, only polling, I think (well, I know it doesn't support
writing, at least).

> to *remaking* /dev/adb to

That won't do anything useful either.  All this does it create a device
node to access the underlying software driver.

> attempting to write a little program to make use of the ioctl call to
> reset the ADB bus (I think I probably botched it, but either way it did
> nothing)

This might conceivably work (assuming it actually resets the bus), if the
internal state of the driver is also cleared out (which, coincidentally, I
don't think it is, but the ability to reset the bus will probably need to
go away once we move to a true bus-style adb with separate mouse and
keyboard drivers).

> to unplugging the damn mouse and replugging it like 30 times. 

DON'T EVER DO THIS!!!!

Older Mac's ADB transceivers are extremely sensitive to resistive load and
voltage levels and you can easily blow one this way (and the mouse, too,
actually).  Never unplug or plug-in an ADB device while the machine is on!

If you've done this in the past, it's quite conceivable that you've either
managed to partially blow your ADB transceiver or your mouse.  Have you
ever gotten screwy behavior under MacOS?

> Same
> stuff.  Then I began to think it was perhaps a dt bug, and fired up X to
> test my theory.  But alas, X produces a similar condition; the mouse will
> not respond to any clicks, but the cursor does not focus windows when
> dragged over them.  The behavior in X also produced a number of other
> bizarre effects which I don't quite remember.  Either way, something's got
> screwed, and I can't tell if it's hardware or software.

I can't be sure either, but the only real way to tell is to grab another
mouse and try it (shut down the machine and exchange mice, of course).

> I have a current uptime of about 20 days and I really don't feel like rebooting;
> I should note that I did run into this identical situation a couple of months ago
> and was forced to reboot to fix it, but at the time I didn't really think much
> of the whole thing.

Well, if rebooting fixes it...why not?  It's not that much of a hassle.

> So, as my box sits here in mouse-challenged limbo, I ask:  anyone even *seen*
> this happen before?  :)  I'd be pretty happy even just to know what's causing
> this, because I'm completely stumped.  Thanks for your time, guys.

I've seen some really strange behavior at times, but not quite like this.
A little more info on what version of the ADB driver might help, but at
the moment, I'd suggest shutting down and seeing if you could try another
mouse.

I hope this helps some.

Later.

-- 
Colin Wood                                 cwood@ichips.intel.com
Component Design Engineer - MD6                 Intel Corporation
-----------------------------------------------------------------
I speak only on my own behalf, not for my employer.