> The pms driver generates what appears to be MouseSystems mouse output :)

That wasn't the reason it wasn't working for me.  The version I was using,
which was the one Charles initially posted to the mailing list was generating
completely bogus output (the top 5 bits of the first byte of every packet were
always all set, so XFree86 didn't recognise any packet as valid).  Once I
switched to the newer version off sun-lamp (and remade the change in order the
interupts were turned off and fixed the reversed dy bug), it worked fine.

I just checked the XFree86 sources, and it appears that the protocol used by
both mousesystems and busmouse mice are identical except that the mousesystems
protocol makes use of bytes 3 and 5 of each 5 byte package in calculating dx
and dy, whereas the busmouse ignores them.  Since the pms driver always sets
bytes 3 and 5 to zero, I figured "busmouse" was more accurate!

I have made another minor modification to the driver, although I'm no longer
convinced that it is such a good idea ... :-)

The current pms driver uses the low order two bits of the first byte from each
mouse packet to map into three bits representing the state of three mouse
buttons as follows:

	00	=>	111		no buttons down
	01	=>	011		left button down
	10	=>	110		right button down
	11	=>	010		left and right button down

This means that if you want pressing both buttons to signifying the middle
button, you have to use XFree86's "Emulate3Buttons" flag, which is irritatingly
broken in that it causes presses of just the left or right buttons to not be
acted on until another mouse event occurs.

I modified the driver to produce '101' for the '11' case above.  When used with
the busmouse mouse type, this gives an "emulated middle button" behaviour
without resorting to the Emulate3buttons flag.  A patch for this is enclosed
below...

This may not be such a good idea, since it means the driver is lying about the
true capabilities of the mouse.  It also means that it is not possible to
generate a "left and right button down" with this being interpreted as a
"middle down" event by X (does this matter?).  Finally, if you don't hit both
buttons simultaneously (or close enough together) you get the left or right
down event, closely followed by a middle down event.  At least with my window
manager (fvwm), this causes non-intuitive behaviour...

I guess the problem should be fixed in XFree86, but from a quick look at the
way mouse events are handled, I'm not sure that is possible...

Anyway, here is the patch...

*** pms.c.orig	Wed Jul 20 15:22:37 1994
--- pms.c	Wed Jul 20 15:21:25 1994
***************
*** 353,362 ****
  	return error;
  }
  
! /* Masks for the first byte of a packet */
! #define PS2LBUTMASK 0x01
! #define PS2RBUTMASK 0x02
! #define PS2MBUTMASK 0x04
  
  int
  pmsintr(sc)
--- 353,359 ----
  	return error;
  }
  
! int buttonmap[] = {0, BUT1STAT, BUT3STAT, BUT2STAT};
  
  int
  pmsintr(sc)
***************
*** 393,400 ****
  		dy = (dy == -128) ? -127 : dy;
  		state = 0;
  
! 		buttons = ((buttons & PS2LBUTMASK) << 2) |
! 			  ((buttons & (PS2RBUTMASK | PS2MBUTMASK)) >> 1);
  		changed = ((buttons ^ sc->sc_status) & BUTSTATMASK) << 3;
  		sc->sc_status = buttons | (sc->sc_status & ~BUTSTATMASK) | changed;
  
--- 390,397 ----
  		dy = (dy == -128) ? -127 : dy;
  		state = 0;
  
! 		buttons = buttonmap[buttons & BUTSTATMASK];
! 
  		changed = ((buttons ^ sc->sc_status) & BUTSTATMASK) << 3;
  		sc->sc_status = buttons | (sc->sc_status & ~BUTSTATMASK) | changed;
  

------------------------------------------------------------------------------