NetBSD Problem Report #60652
From www@netbsd.org Wed Aug 26 18:49:29 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 "YR2" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 3C7451A923B
for <gnats-bugs@gnats.NetBSD.org>; Wed, 26 Aug 2026 18:49:29 +0000 (UTC)
Message-Id: <20260826184928.24D5A1A923C@mollari.NetBSD.org>
Date: Wed, 26 Aug 2026 18:49:28 +0000 (UTC)
From: netbsd.6u9@lmigfernandes.addymail.com
Reply-To: netbsd.6u9@lmigfernandes.addymail.com
To: gnats-bugs@NetBSD.org
Subject: pms(4) misdetects Perixx PS/2 wheel mouse as 5-button protocol
X-Send-Pr-Version: www-1.0
X-From4GNATS: "netbsd.6u9@lmigfernandes.addymail.com via gnats" <gnats-admin@NetBSD.org>
>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
>Last-Modified: Wed Sep 02 02:40:01 +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:/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.
>Audit-Trail:
From: netbsd.6u9@lmigfernandes.addymail.com
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/60652: pms(4) misdetects Perixx PS/2 wheel mouse as
5-button protocol
Date: Fri, 28 Aug 2026 06:10:51 +0000
--UjRj1rES
Content-Type: multipart/alternative; boundary=Ux5EO852
--Ux5EO852
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
I was able to find a working fix to the mouse problem.
As already ment=
ioned above, the mouse is reporting device ID 0x04 during the standard 200/=
200/80 probe by NetBSD, so it seems that PMS_SCROLL5 detection is performed=
successfully.
However, NetBSD just starts normal PMS_SCROLL5 operatio=
n without the extra initialization, which Linux uses for =E2=80=9CIntelliMo=
use Explorer devices=E2=80=9D.
The sequence of commands that was misse=
d is found in the Linux source code in drivers/input/mouse/psmouse-base.c, =
in function im_explorer_detect(). After detecting device ID 0x04 Linux send=
s:
=C2=A0=C2=A0 200
=C2=A0=C2=A0 80
=C2=A0=C2=A0 40
And this sequen=
ce is commented in the source code as:
=E2=80=9CMagic to enable horizonta=
l scrolling on IntelliMouse 4.0.=E2=80=9D
I have added the same 200/80=
/40 sequence after PMS_SCROLL5 detection in NetBSD.
After this patch, =
the mouse works correctly using the existing NetBSD's 4-byte PMS_SCROLL5 ha=
ndler:
During investigation I tried different packet-parser and synchr=
onization patches. The forced 3-byte framing worked with movement but not w=
ith the wheel, while the normal 4-byte PMS_SCROLL5 and 200/80/40 initializa=
tion patch fixed the mouse problem.
This works only for my Perixx PS/2=
mouse so far. I have not tried whether this affects other hardware devices=
with ID 0x04.
Please note that the patch file I attached below includ=
es only the initialization change of 200/80/40.
Aug 26, 2026, 19:50=
by netbsd.6u9@lmigfernandes.addymail.com:
> Thank you very much for y=
our problem report.
> It has the internal identification `kern/60652'.
=
> The individual assigned to look at your
> report is: kern-bug-people. =
>
> >Category: kern
> >Responsible: kern-bug-people
> >Sy=
nopsis: pms(4) misdetects Perixx PS/2 wheel mouse as 5-button protoco=
l
> >Arrival-Date: Wed Aug 26 18:50:00 +0000 2026
>
>
>
--Ux5EO852
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"content-type" content=3D"text/h=
tml; charset=3DUTF-8">
</head>
<body>
<div dir=3D"auto">I was abl=
e to find a working fix to the mouse problem.<br></div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">As already mentioned above, the mouse is reportin=
g device ID 0x04 during the standard 200/200/80 probe by NetBSD, so it seem=
s that PMS_SCROLL5 detection is performed successfully.<br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">However, NetBSD just starts normal PM=
S_SCROLL5 operation without the extra initialization, which Linux uses for =
=E2=80=9CIntelliMouse Explorer devices=E2=80=9D.<br></div><div dir=3D"auto"=
><br></div><div dir=3D"auto">The sequence of commands that was missed is fo=
und in the Linux source code in drivers/input/mouse/psmouse-base.c, in func=
tion im_explorer_detect(). After detecting device ID 0x04 Linux sends:<br><=
/div><div dir=3D"auto"> 200<br></div><div dir=3D"auto"> &n=
bsp; 80<br></div><div dir=3D"auto"> 40<br></div><div dir=3D"aut=
o">And this sequence is commented in the source code as:<br></div><div dir=
=3D"auto">=E2=80=9CMagic to enable horizontal scrolling on IntelliMouse 4.0=
.=E2=80=9D<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">I have ad=
ded the same 200/80/40 sequence after PMS_SCROLL5 detection in NetBSD.<br><=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">After this patch, the mo=
use works correctly using the existing NetBSD's 4-byte PMS_SCROLL5 handler:=
<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">During investigatio=
n I tried different packet-parser and synchronization patches. The forced 3=
-byte framing worked with movement but not with the wheel, while the normal=
4-byte PMS_SCROLL5 and 200/80/40 initialization patch fixed the mouse prob=
lem.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">This works only=
for my Perixx PS/2 mouse so far. I have not tried whether this affects oth=
er hardware devices with ID 0x04.<br></div><div dir=3D"auto"><br></div><div=
dir=3D"auto">Please note that the patch file I attached below includes onl=
y the initialization change of 200/80/40.<br></div><div dir=3D"auto"><br></=
div><div dir=3D"auto"><br></div><div dir=3D"auto">Aug 26, 2026, 19:50 by ne=
tbsd.6u9@lmigfernandes.addymail.com:<br></div><blockquote class=3D"tutanota=
_quote" style=3D"border-left: 1px solid #93A3B8; padding-left: 10px; margin=
-left: 5px;"><div dir=3D"auto">Thank you very much for your problem report.=
<br></div><div dir=3D"auto">It has the internal identification `kern/60652'=
.<br></div><div dir=3D"auto">The individual assigned to look at your<br></d=
iv><div dir=3D"auto">report is: kern-bug-people. <br></div><div dir=3D"auto=
"><br></div><div dir=3D"auto">>Category: kern<br></div><div dir=3D=
"auto">>Responsible: kern-bug-people<br></div><div dir=3D"auto">>S=
ynopsis: pms(4) misdetects Perixx PS/2 wheel mouse as 5-button protoc=
ol<br></div><div dir=3D"auto">>Arrival-Date: Wed Aug 26 18:50:00 +0000=
2026<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div></bl=
ockquote><div dir=3D"auto"><br></div> </body>
</html>
--Ux5EO852--
--UjRj1rES
Content-Type: text/x-patch; name=netbsd-pms-fix.patch
Content-Transfer-Encoding: base64
Content-Disposition: attachment; name=netbsd-pms-fix.patch;
filename=netbsd-pms-fix.patch
LS0tIC91c3Ivc3JjL3N5cy9kZXYvcGNrYnBvcnQvcG1zLmMub3JpZworKysgL3Vzci9zcmMvc3lz
L2Rldi9wY2ticG9ydC9wbXMuYwpAQCAtMTI4LDYgKzEyOCwzMSBAQAogCQlpZiAocmVzcFswXSA9
PSBwLT5yZXNwb25zZSkgewogCQkJRFBSSU5URigoInBtc19wcm90b2NvbDogZm91bmQgbW91c2Ug
cHJvdG9jb2wgJWRcbiIsCiAJCQkJdHJpZXNbal0pKTsKKworCQkJaWYgKHRyaWVzW2pdID09IFBN
U19TQ1JPTEw1KSB7CisJCQkJdV9jaGFyIGluaXRbMl07CisKKwkJCQlpbml0WzBdID0gUE1TX1NF
VF9TQU1QTEU7CisKKwkJCQlpbml0WzFdID0gMjAwOworCQkJCXJlcyA9IHBja2Jwb3J0X2VucXVl
dWVfY21kKHRhZywgc2xvdCwgaW5pdCwKKwkJCQkgICAgMiwgMCwgMSwgMCk7CisJCQkJaWYgKHJl
cykKKwkJCQkJcmV0dXJuIFBNU19VTktOT1dOOworCisJCQkJaW5pdFsxXSA9IDgwOworCQkJCXJl
cyA9IHBja2Jwb3J0X2VucXVldWVfY21kKHRhZywgc2xvdCwgaW5pdCwKKwkJCQkgICAgMiwgMCwg
MSwgMCk7CisJCQkJaWYgKHJlcykKKwkJCQkJcmV0dXJuIFBNU19VTktOT1dOOworCisJCQkJaW5p
dFsxXSA9IDQwOworCQkJCXJlcyA9IHBja2Jwb3J0X2VucXVldWVfY21kKHRhZywgc2xvdCwgaW5p
dCwKKwkJCQkgICAgMiwgMCwgMSwgMCk7CisJCQkJaWYgKHJlcykKKwkJCQkJcmV0dXJuIFBNU19V
TktOT1dOOworCQkJfQorCiAJCQlyZXR1cm4gdHJpZXNbal07CiAJCX0KIAl9Cg==
--UjRj1rES--
From: netbsd.6u9@lmigfernandes.addymail.com
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/60652: pms(4) misdetects Perixx PS/2 wheel mouse as
5-button protocol
Date: Fri, 28 Aug 2026 22:17:41 +0000
--ygeg2DIn
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Further testing:
The patch was later tested on a fresh installation of=
NetBSD 11.0=C2=A0
with no changes made in the source tree. The result wa=
s that the
same Perixx PS/2 mouse worked fine, including both normal mous=
e
movement and scrolling using the wheel.
This verifies that the pat=
ch is indeed reproducible on a clean NetBSD 11.0=C2=A0
installation and i=
s independent of the test environment used previously.
--ygeg2DIn
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"content-type" content=3D"text/h=
tml; charset=3DUTF-8">
</head>
<body>
<div dir=3D"auto">Further t=
esting:<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">The patch wa=
s later tested on a fresh installation of NetBSD 11.0 <br></div><div d=
ir=3D"auto">with no changes made in the source tree. The result was that th=
e<br></div><div dir=3D"auto">same Perixx PS/2 mouse worked fine, including =
both normal mouse<br></div><div dir=3D"auto">movement and scrolling using t=
he wheel.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">This verif=
ies that the patch is indeed reproducible on a clean NetBSD 11.0 <br><=
/div><div dir=3D"auto">installation and is independent of the test environm=
ent used previously.<br></div> </body>
</html>
--ygeg2DIn--
From: netbsd.6u9@lmigfernandes.addymail.com
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/60652: pms(4) misdetects Perixx PS/2 wheel mouse as
5-button protocol
Date: Wed, 02 Sep 2026 02:31:22 +0000
--3aM0YAsB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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 I=
D 0x04. It
doesn't put IntelliMouse 4.0-class devices (like this Perixx m=
ouse)
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 s=
ingle SET_SAMPLE_RATE(40), and got garbled
cursor movement on the same ha=
rdware. Skipping the step-down leaves
the packet framing desynced. Keep t=
he three-step sequence intact.
Updated patch replaces the three copy-p=
asted blocks with a loop over
the same values. Same behavior, less duplic=
ation:
--- sys/dev/pckbport/pms.c.orig
+++ sys/dev/pckbport/pms.c
=
@@ -128,6 +128,28 @@
if (resp[0] =3D=3D p->response) {
DPRINTF(("pms_pr=
otocol: found mouse protocol %d\n",
tries[j]));
+
+=09=09=09if (tries=
[j] =3D=3D PMS_SCROLL5) {
+=09=09=09=09/*
+=09=09=09=09 * This controll=
er garbles/desyncs the byte
+=09=09=09=09 * stream unless the sample rate=
is stepped
+=09=09=09=09 * down through 200 -> 80 -> 40 after the
+=09=
=09=09=09 * enable knock; jumping straight to 40
+=09=09=09=09 * leaves i=
t misframed.
+=09=09=09=09 */
+=09=09=09=09static const u_char rates[] =
=3D { 200, 80, 40 };
+=09=09=09=09u_int k;
+
+=09=09=09=09cmd[0] =3D =
PMS_SET_SAMPLE;
+=09=09=09=09for (k =3D 0; k < __arraycount(rates); k++) =
{
+=09=09=09=09=09cmd[1] =3D rates[k];
+=09=09=09=09=09res =3D pckbport=
_enqueue_cmd(tag, slot,
+=09=09=09=09=09=C2=A0=C2=A0=C2=A0 cmd, 2, 0, 1, =
0);
+=09=09=09=09=09if (res)
+=09=09=09=09=09=09return PMS_UNKNOWN;
+=
=09=09=09=09}
+=09=09=09}
+
return tries[j];
}
}
Rebuilt and=
rebooted on the same NetBSD 11.0/amd64 machine; movement
and wheel scrol=
ling both work, no regression from the original patch.
--3aM0YAsB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"content-type" content=3D"text/h=
tml; charset=3DUTF-8">
</head>
<body>
<div dir=3D"auto">Quick not=
e on why 200/80/40 why isn't an arbitrary number, plus a<br></div><div dir=
=3D"auto">cleaned-up patch.<br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">The 200/200/80 probe only gets the mouse to report device ID 0x04=
. It<br></div><div dir=3D"auto">doesn't put IntelliMouse 4.0-class devices =
(like this Perixx mouse)<br></div><div dir=3D"auto">into the mode where the=
y actually emit correct packets. That's a<br></div><div dir=3D"auto">second=
step. 200/80/40 is Linux's own documented trigger for it:<br></div><div di=
r=3D"auto">drivers/input/mouse/psmouse-base.c, im_explorer_detect(), commen=
ted as<br></div><div dir=3D"auto">"Magic to enable horizontal scrolling on =
IntelliMouse 4.0." So it's the<br></div><div dir=3D"auto">second half of th=
e real init handshake, not a guessed value.<br></div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Also confirmed: all three steps matter, not just th=
e final rate. I<br></div><div dir=3D"auto">tried collapsing it to a single =
SET_SAMPLE_RATE(40), and got garbled<br></div><div dir=3D"auto">cursor move=
ment on the same hardware. Skipping the step-down leaves<br></div><div dir=
=3D"auto">the packet framing desynced. Keep the three-step sequence intact.=
<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Updated patch repla=
ces the three copy-pasted blocks with a loop over<br></div><div dir=3D"auto=
">the same values. Same behavior, less duplication:<br></div><div dir=3D"au=
to"><br></div><div dir=3D"auto">--- sys/dev/pckbport/pms.c.orig<br></div><d=
iv dir=3D"auto">+++ sys/dev/pckbport/pms.c<br></div><div dir=3D"auto">@@ -1=
28,6 +128,28 @@<br></div><div dir=3D"auto">if (resp[0] =3D=3D p->respons=
e) {<br></div><div dir=3D"auto">DPRINTF(("pms_protocol: found mouse protoco=
l %d\n",<br></div><div dir=3D"auto">tries[j]));<br></div><div dir=3D"auto">=
+<br></div><div dir=3D"auto">+=09=09=09if (tries[j] =3D=3D PMS_SCROLL5) {<b=
r></div><div dir=3D"auto">+=09=09=09=09/*<br></div><div dir=3D"auto">+=09=
=09=09=09 * This controller garbles/desyncs the byte<br></div><div dir=3D"a=
uto">+=09=09=09=09 * stream unless the sample rate is stepped<br></div><div=
dir=3D"auto">+=09=09=09=09 * down through 200 -> 80 -> 40 after the<=
br></div><div dir=3D"auto">+=09=09=09=09 * enable knock; jumping straight t=
o 40<br></div><div dir=3D"auto">+=09=09=09=09 * leaves it misframed.<br></d=
iv><div dir=3D"auto">+=09=09=09=09 */<br></div><div dir=3D"auto">+=09=09=09=
=09static const u_char rates[] =3D { 200, 80, 40 };<br></div><div dir=3D"au=
to">+=09=09=09=09u_int k;<br></div><div dir=3D"auto">+<br></div><div dir=3D=
"auto">+=09=09=09=09cmd[0] =3D PMS_SET_SAMPLE;<br></div><div dir=3D"auto">+=
=09=09=09=09for (k =3D 0; k < __arraycount(rates); k++) {<br></div><div =
dir=3D"auto">+=09=09=09=09=09cmd[1] =3D rates[k];<br></div><div dir=3D"auto=
">+=09=09=09=09=09res =3D pckbport_enqueue_cmd(tag, slot,<br></div><div dir=
=3D"auto">+=09=09=09=09=09 cmd, 2, 0, 1, 0);<br></div><di=
v dir=3D"auto">+=09=09=09=09=09if (res)<br></div><div dir=3D"auto">+=09=09=
=09=09=09=09return PMS_UNKNOWN;<br></div><div dir=3D"auto">+=09=09=09=09}<b=
r></div><div dir=3D"auto">+=09=09=09}<br></div><div dir=3D"auto">+<br></div=
><div dir=3D"auto">return tries[j];<br></div><div dir=3D"auto">}<br></div><=
div dir=3D"auto">}<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">R=
ebuilt and rebooted on the same NetBSD 11.0/amd64 machine; movement<br></di=
v><div dir=3D"auto">and wheel scrolling both work, no regression from the o=
riginal patch.<br></div> </body>
</html>
--3aM0YAsB--
(Contact us)
$NetBSD: query-full-pr,v 1.51 2026/08/10 02:28:17 riastradh Exp $
$NetBSD: gnats_config.sh,v 1.10 2026/05/13 22:00:09 riastradh Exp $
Copyright © 1994-2026
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home