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

[netbsd.6u9%lmigfernandes.addymail.com@localhost]

Quick note on why 200/80/40 why isn't an arbitrary number, plus a

cleaned-up patch.

The 200/200/80 probe only gets the mouse to report device ID 0x04. It

doesn't put IntelliMouse 4.0-class devices (like this Perixx mouse)

into the mode where they actually emit correct packets. That's a

second step. 200/80/40 is Linux's own documented trigger for it:

drivers/input/mouse/psmouse-base.c, im_explorer_detect(), commented as

"Magic to enable horizontal scrolling on IntelliMouse 4.0." So it's the

second half of the real init handshake, not a guessed value.

Also confirmed: all three steps matter, not just the final rate. I

tried collapsing it to a single SET_SAMPLE_RATE(40), and got garbled

cursor movement on the same hardware. Skipping the step-down leaves

the packet framing desynced. Keep the three-step sequence intact.

Updated patch replaces the three copy-pasted blocks with a loop over

the same values. Same behavior, less duplication:

--- sys/dev/pckbport/pms.c.orig

+++ sys/dev/pckbport/pms.c

@@ -128,6 +128,28 @@

if (resp[0] == p->response) {

DPRINTF(("pms_protocol: found mouse protocol %d\n",

tries[j]));

+

+ if (tries[j] == PMS_SCROLL5) {

+ /*

+ * This controller garbles/desyncs the byte

+ * stream unless the sample rate is stepped

+ * down through 200 -> 80 -> 40 after the

+ * enable knock; jumping straight to 40

+ * leaves it misframed.

+ */

+ static const u_char rates[] = { 200, 80, 40 };

+ u_int k;

+

+ cmd[0] = PMS_SET_SAMPLE;

+ for (k = 0; k < __arraycount(rates); k++) {

+ cmd[1] = rates[k];

+ res = pckbport_enqueue_cmd(tag, slot,

+     cmd, 2, 0, 1, 0);

+ if (res)

+ return PMS_UNKNOWN;

+ }

+ }

+

return tries[j];

}

}

Rebuilt and rebooted on the same NetBSD 11.0/amd64 machine; movement

and wheel scrolling both work, no regression from the original patch.