kern/60652: pms(4) misdetects Perixx PS/2 wheel mouse as 5-button protocol

["netbsd.6u9%lmigfernandes.addymail.com@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60652
>Category:       kern
>Synopsis:       pms(4) misdetects Perixx PS/2 wheel mouse as 5-button protocol
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 26 18:50:00 +0000 2026
>Originator:     Luís Fernandes
>Release:        NetBSD 11.0
>Organization:
>Environment:
NetBSD ambox 11.0 NetBSD 11.0 (GENERIC) #0: Thu Jul 30 15:23:12 UTC 2026 mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
The NetBSD 11.0 pms(4) driver incorrectly selects the
PMS_SCROLL5 protocol for this Perixx PS/2 mouse.

With the GENERIC kernel, the mouse is detected as:

pms0 at pckbc1 (aux slot)
wsmouse0 at pms0 mux 0

The mouse behaves incorrectly under X. While moving the mouse
without clicking any buttons or using the scroll wheel, X receives
spurious wheel/button events. This causes the cursor to behave
erratically and applications may receive unintended input.

The problem is not limited to Xorg.

With X stopped, reading /dev/wsmouse0 directly while moving the
mouse shows WSCONS_EVENT_MOUSE_DELTA_Z events and mouse button
events even though no buttons or the wheel are being operated.

The relevant wscons event definitions are:

WSCONS_EVENT_MOUSE_UP        4
WSCONS_EVENT_MOUSE_DOWN      5
WSCONS_EVENT_MOUSE_DELTA_X   6
WSCONS_EVENT_MOUSE_DELTA_Y   7
WSCONS_EVENT_MOUSE_DELTA_Z   10

I built a diagnostic NetBSD 11.0 kernel with PMSDEBUG enabled.

With the unmodified pms driver, the kernel reports:

pms_protocol: found mouse protocol 3
pms_enable: using scroll wheel (5 buttons) protocol

The relevant code in sys/dev/pckbport/pms.c is:

static const enum pms_type tries[] = {
        PMS_SCROLL5, PMS_SCROLL3, PMS_STANDARD, PMS_UNKNOWN
};

The protocol table contains:

{ { 200, 100, 80 }, 3, "scroll wheel (3 buttons)" },
{ { 200, 200, 80 }, 4, "scroll wheel (5 buttons)" },

The driver probes PMS_SCROLL5 first and accepts that protocol
when the mouse responds with device ID 4.
>How-To-Repeat:
1. Connect the Perixx PS/2 mouse directly to a PS/2 mouse port.
2. Boot NetBSD 11.0 GENERIC.
3. Start X.
4. Run:

   xinput test Mouse0

5. Move the mouse without clicking or scrolling.

Spurious button 4/5 events are generated while the mouse is only
being moved.

The problem can also be reproduced below X by stopping X and
reading /dev/wsmouse0 directly. The raw event stream contains
WSCONS_EVENT_MOUSE_DELTA_Z and mouse button events while only
moving the mouse.
>Fix:
As a diagnostic experiment, I changed the protocol probe order in
sys/dev/pckbport/pms.c from:

static const enum pms_type tries[] = {
        PMS_SCROLL5, PMS_SCROLL3, PMS_STANDARD, PMS_UNKNOWN
};

to:

static const enum pms_type tries[] = {
        PMS_SCROLL3, PMS_STANDARD, PMS_UNKNOWN
};

After rebuilding and booting the modified kernel, the driver
reports:

pms_protocol: found mouse protocol 2
pms_enable: using scroll wheel (3 buttons) protocol

The mouse then works correctly. Moving the mouse no longer
generates spurious wheel or button events.

The exact source change is:

--- sys/dev/pckbport/pms.c.orig
+++ sys/dev/pckbport/pms.c
@@ -65,7 +65,7 @@
 static const enum pms_type tries[] = {
-       PMS_SCROLL5, PMS_SCROLL3, PMS_STANDARD, PMS_UNKNOWN
+       PMS_SCROLL3, PMS_STANDARD, PMS_UNKNOWN
 };

This workaround has been verified with a rebuilt NetBSD 11.0
kernel.

I do not know why the mouse responds to the PMS_SCROLL5
identification sequence or whether the protocol negotiation
should reject that response. However, forcing PMS_SCROLL3 makes
the mouse operate correctly.

Additional information:

The original GENERIC kernel reports the following PS/2 devices:

pckbc1 at acpi0 (PS2K, PNP0303) (kbd port): io 0x60,0x64 irq 1
pckbc2 at acpi0 (PS2M, PNP0F03) (aux port): irq 12
pms0 at pckbc1 (aux slot)
wsmouse0 at pms0 mux 0

The mouse reports:

type=ps2

when queried with:

wsconsctl -f /dev/wsmouse0 -m type

The issue persists across a complete power-off and reboot.

The same physical mouse works correctly with Windows, Linux,
FreeBSD and OpenBSD.

The working workaround demonstrates that the issue is specifically
related to the protocol selected by pms(4), rather than the PS/2
hardware, Xorg, or wscons mouse acceleration/settings.