As interesting as the interesting results were, these more interesting results 
are more interesting.

Tinkering with pms.c, I managed to reduce the number of problems, unitl one of 
the few remaining finally revealed a clue to their cause.  In addition to 
fixing the initialization so the mouse behaves better, I put in a "button 
bounce filter", which imposes an interval after a button press, within which 
mouse motion and further button presses will not be delivered (currently 0.10 
second).

Many of you probably know about this already; it vaguely rings a bell with me, 
like from a few years ago:

Apparently, the X server will gladly deliver mouse events to windows that are 
no longer there.

For example, consider a dialog box with an OK button.  Distracted, harassed 
and in a hurry, you click on the OK button -- triggering an action that takes 
a while -- and accidentally click on the button again.  So the action occurs 
and the dialog goes away, then the client processes the second event, and 
winds up crashing (due to bad programming) as some result of the window not 
being there.
(If the action takes long enough, this can happen even with my "bounce filter" 
in the kernel driver.)

The other problems I've had (such as, with window close buttons) are all  
explained similarly, but are easier to prevent in the driver.  Tinkering with 
the driver reduced the problems, because it reduced the number of accidental 
events being delivered to X.

At any rate, that's my first viable theory.

If true, then this would -- strictly speaking -- not be a NetBSD/i386 problem, 
and could afflict any system with sloppy X clients.

I will say, though, that I never noticed things like this happening until I 
got a new, much faster motherboard and CPU....


--Jim Howard  <jiho@mail.c-zone.net>