NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
kern/60651: pms(4) misdetects Perixx PS/2 wheel mouse as 5-button protocol
>Number: 60651
>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:45:00 +0000 2026
>Originator: luis
>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
Hardware:
- x86_64/amd64 PC
- Perixx PS/2 mouse
- Directly connected to the motherboard's PS/2 mouse port
- Three physical buttons: left, middle/wheel, right
- Scroll wheel
The same physical mouse works correctly under Windows, Linux,
FreeBSD, and OpenBSD.
>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. Moving the mouse without
clicking any buttons or using the wheel generates spurious mouse
wheel/button events. This results in the cursor moving erratically
and applications receiving unintended input.
The problem is not limited to Xorg. Reading /dev/wsmouse0 directly
while moving the mouse shows WSCONS_EVENT_MOUSE_DELTA_Z events
and mouse button events even though no buttons or 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 pms.c code 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 therefore probes PMS_SCROLL5 first and accepts it
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.
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 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 am not certain 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.
This mouse is a Perixx PS/2 mouse with three physical buttons
(left, middle/wheel, right) and a scroll wheel. It works correctly
with Windows, Linux, FreeBSD and OpenBSD.
Home |
Main Index |
Thread Index |
Old Index