port-sgimips/60206: sgimips: o2 mouse support doesn't enumerate all PS/2 mice

["adrian%freebsd.org@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60206
>Category:       port-sgimips
>Synopsis:       sgimips: o2 mouse support doesn't enumerate all PS/2 mice
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    port-sgimips-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Apr 22 16:25:01 +0000 2026
>Originator:     Adrian Chadd
>Release:        11.99
>Organization:
>Environment:
>Description:
I have some PS/2 mice that enumerate fine on the O2, and some that do not.
The mice work fine in the PROM so it's not specifically a hardware problem.

The PS/2 "specification" requires the controller to inhibit
the clock line for 100uS before trying to transmit.  This tells
the device (in this case a bunch of ps/2 mice) to stop transmitting,
get ready for receive and get ready to send the clock out to the
controller to send said bits.

After staring at traces with a logic analyser it looks like the
controller is NOT doing this in hardware - it immediately attempts
to transmit bytes and if the ps/2 device doesn't handle that,
it will simply never send out clock pulses for the controller to
clock the byte out.
>How-To-Repeat:
* older ps/2 mice (eg my wyse 3 button + scrollwheel mouse) work
* newer ones from amazon do not (3 button + scrollwheel + forward/back buttons, so I guess a 5 button mouse?)

Note the problem isn't in configuration, it's in early probe - the reset command doesn't work. So it's not even at the point where it could be a "how many coordinates / buttons do you support?" part of the mouse protocol exchange.
>Fix:

* Inhibit the clock line, disable tx/rx entirely
* wait 100uS for the device to catch up
* Program the byte to the TX hardware
* Then re-enable TX/RX; the hardware will then attempt to transmit
  it out with the device supplied clock.

This allows both my "already worked" Wyse PS/2 mice and my
"didn't work" in NetBSD mice to now probe/detect correctly.

```
diff --git a/sys/arch/sgimips/mace/macekbc.c b/sys/arch/sgimips/mace/macekbc.c
index 141ee9d334f97..f64bf895600dc 100644
--- a/sys/arch/sgimips/mace/macekbc.c
+++ b/sys/arch/sgimips/mace/macekbc.c
@@ -263,6 +263,7 @@ macekbc_send_devcmd(void *opaque, pckbport_slot_t slot, u_char byte)
 	struct macekbc_internal	*t;
 	bus_space_tag_t iot;
 	bus_space_handle_t ioh;
+	uint32_t ctrl;
 
 	t = opaque;
 	iot = t->t_iot;
@@ -271,8 +272,32 @@ macekbc_send_devcmd(void *opaque, pckbport_slot_t slot, u_char byte)
 	if (macekbc_wait(t, slot, MACEKBC_STAT_TXEMPTY, 1))
 		return 0;
 
+	/* Before sending a byte to a device, the clock needs
+	 * to be inhibited so the device knows it should
+	 * abort transmitting data and get ready to send the
+	 * controller clock pulses so the controller can shift
+	 * out data.
+	 */
+
+	/* Save the config */
+	ctrl = bus_space_read_8(iot, ioh, MACEKBC_CTRL);
+
+	/* Disable TX/RX, inhibit clock */
+	bus_space_write_8(iot, ioh, MACEKBC_CTRL, 0);
+
+	/* 100uS delay to ensure the device sees it */
+	delay(100);
+
+	/* Populate byte to write */
 	bus_space_write_8(iot, ioh, MACEKBC_TX, byte & 0xff);
 
+	/*
+	 * Enable TX/RX, device will generate clock, controller
+	 * will clock out bytes
+	 */
+	bus_space_write_8(iot, ioh, MACEKBC_CTRL,
+	    ctrl | MACEKBC_CTRL_RXCLKON | MACEKBC_CTRL_TXON);
+
 	return 1;
 }
```