NetBSD Problem Report #60206

From www@netbsd.org  Wed Apr 22 16:24:02 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.netbsd.org", Issuer "R12" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 30E4C1A923C
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 22 Apr 2026 16:24:02 +0000 (UTC)
Message-Id: <20260422162401.02B6F1A923F@mollari.NetBSD.org>
Date: Wed, 22 Apr 2026 16:24:00 +0000 (UTC)
From: adrian@freebsd.org
Reply-To: adrian@freebsd.org
To: gnats-bugs@NetBSD.org
Subject: sgimips: o2 mouse support doesn't enumerate all PS/2 mice
X-Send-Pr-Version: www-1.0
X-From4GNATS: "adrian@freebsd.org via gnats" <gnats-admin@NetBSD.org>

>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:          needs-pullups
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Apr 22 16:25:01 +0000 2026
>Closed-Date:    
>Last-Modified:  Mon May 04 16:31:05 +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;
 }
```

>Release-Note:

>Audit-Trail:
From: "Adrian Chadd" <adrian@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/60206 CVS commit: src/sys/arch/sgimips/mace
Date: Tue, 28 Apr 2026 14:20:33 +0000

 Module Name:	src
 Committed By:	adrian
 Date:		Tue Apr 28 14:20:33 UTC 2026

 Modified Files:
 	src/sys/arch/sgimips/mace: macekbc.c

 Log Message:
 macekbc: fix byte transmit to properly inhibit clock line first

 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.

 The mice in question work fine on the O2 PROM, so it's not a
 hardware issue per se.

 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.

 So:

 * 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.

 This addresses PR port-sgimips/60206 .


 To generate a diff of this commit:
 cvs rdiff -u -r1.9 -r1.10 src/sys/arch/sgimips/mace/macekbc.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->needs-pullups
State-Changed-By: adrian@NetBSD.org
State-Changed-When: Mon, 04 May 2026 16:31:05 +0000
State-Changed-Why:
Code landed; needs pullup into -10 and -11


>Unformatted:

Home	PR Database Search