bcm5974 trackpad broken after USB reset

bcm5974 trackpad broken after USB reset

[Liam Mitchell]

Hi,

The trackpad on my 2013 MacBook Pro (10,2) stops working after the USB
device is reset, logging "bad trackpad package, length: 8" when
touching the trackpad.

The reset occurs often on my machine, caused by USB EPROTO (MMF)
errors handled by drivers/hid/usbhid/hid-core.c:hid_io_error() (HID is
handling the keyboard interface of this device). On encountering two
keyboard EPROTO errors within 1.5 seconds, the driver will reset the
USB device, also resetting bcm5974 and trackpad.

I can also reproduce this with the command:
$ sudo usbreset 05ac:0259

I can get the trackpad back into a working state by reloading the
bcm5974 driver:
$ sudo modprobe -r bcm5974; sudo modprobe bcm5974

I experimented with the driver and found that adding msleep(50) to
drivers/input/mouse/bcm5974.c:bcm5974_probe() was enough to allow the
trackpad to restart reliably after EPROTO errors and the usbreset
command.

Not sure if adding a sleep is the right way to fix this, or if I
should be looking more into the EPROTO error handling in HID or even
the source of the EPROTO errors in EHCI, power management or firmware.

Version/hardware info below, any input appreciated, thanks!
Liam

$ cat /proc/version
Linux version 6.18.4-arch1-1 (linux@archlinux) (gcc (GCC) 15.2.1
20260103, GNU ld (GNU Binutils) 2.45.1) #1 SMP PREEMPT_DYNAMIC Fri, 09
Jan 2026 19:43:48 +0000
https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/blob/ac8e7e814bb68e6291b4efd862ee9a72d7dc1165/config

$ lsusb -tvvv # only showing root containing kb/trackpad
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/2p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    /sys/bus/usb/devices/usb4  /dev/bus/usb/004/001
    |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M
        ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
        /sys/bus/usb/devices/4-1  /dev/bus/usb/004/002
        |__ Port 008: Dev 003, If 0, Class=Hub, Driver=hub/2p, 480M
            ID 0424:2512 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub
            /sys/bus/usb/devices/4-1.8  /dev/bus/usb/004/003
            |__ Port 001: Dev 004, If 0, Class=Hub, Driver=hub/3p, 12M
                ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub
(part of BCM2046 Bluetooth)
                /sys/bus/usb/devices/4-1.8.1  /dev/bus/usb/004/004
                Manufacturer=Apple Inc. Product=BRCM20702 Hub
                |__ Port 003: Dev 008, If 0, Class=Vendor Specific
Class, Driver=btusb, 12M
                    ID 05ac:828c Apple, Inc. Bluetooth Host Controller
                    /sys/bus/usb/devices/4-1.8.1.3  /dev/bus/usb/004/008
                    Manufacturer=Apple Inc. Product=Bluetooth USB Host
Controller
                |__ Port 003: Dev 008, If 1, Class=Wireless, Driver=btusb, 12M
                    ID 05ac:828c Apple, Inc. Bluetooth Host Controller
                    /sys/bus/usb/devices/4-1.8.1.3  /dev/bus/usb/004/008
                    Manufacturer=Apple Inc. Product=Bluetooth USB Host
Controller
                |__ Port 003: Dev 008, If 2, Class=Vendor Specific
Class, Driver=btusb, 12M
                    ID 05ac:828c Apple, Inc. Bluetooth Host Controller
                    /sys/bus/usb/devices/4-1.8.1.3  /dev/bus/usb/004/008
                    Manufacturer=Apple Inc. Product=Bluetooth USB Host
Controller
                |__ Port 003: Dev 008, If 3, Class=Application
Specific Interface, Driver=[none], 12M
                    ID 05ac:828c Apple, Inc. Bluetooth Host Controller
                    /sys/bus/usb/devices/4-1.8.1.3  /dev/bus/usb/004/008
                    Manufacturer=Apple Inc. Product=Bluetooth USB Host
Controller
            |__ Port 002: Dev 005, If 0, Class=Human Interface Device,
Driver=usbhid, 12M
                ID 05ac:0259 Apple, Inc. Internal Keyboard/Trackpad
                /sys/bus/usb/devices/4-1.8.2  /dev/bus/usb/004/005
                Manufacturer=Apple Inc. Product=Apple Internal
Keyboard / Trackpad
            |__ Port 002: Dev 005, If 1, Class=Human Interface Device,
Driver=usbhid, 12M
                ID 05ac:0259 Apple, Inc. Internal Keyboard/Trackpad
                /sys/bus/usb/devices/4-1.8.2  /dev/bus/usb/004/005
                Manufacturer=Apple Inc. Product=Apple Internal
Keyboard / Trackpad
            |__ Port 002: Dev 005, If 2, Class=Human Interface Device,
Driver=bcm5974, 12M
                ID 05ac:0259 Apple, Inc. Internal Keyboard/Trackpad
                /sys/bus/usb/devices/4-1.8.2  /dev/bus/usb/004/005
                Manufacturer=Apple Inc. Product=Apple Internal
Keyboard / Trackpad

Re: bcm5974 trackpad broken after USB reset

[Henrik Rydberg]

Hi Liam,

 > The trackpad on my 2013 MacBook Pro (10,2) stops working after the USB
> device is reset, logging "bad trackpad package, length: 8" when
> touching the trackpad.

This sounds like the device has left wellspring mode, and is not 
properly reinitialized after reset. It has been a decade since I worked 
on this driver, but what I can see, there is no reset_resume handler in 
bcm5974, but there is one in appletouch.

I would look into the code around the wellspring mode switch function, 
and see if it gets called after the usb reset. If not, adding the 
reset_resume handler might resolve things.

Hope this helps,
Henrik

Re: bcm5974 trackpad broken after USB reset

[Liam Mitchell]

On Sun, 11 Jan 2026 at 20:59, Henrik Rydberg <rydberg@bitmath.se> wrote:
> I would look into the code around the wellspring mode switch function,
> and see if it gets called after the usb reset. If not, adding the
> reset_resume handler might resolve things.

Thanks for the pointer. The wellspring mode switch is definitely
attempted. The bcm5974 driver does the mode switching in input_dev
open/close hooks. These are called multiple times after reset. See the
following logs produced after `sudo usbreset 05ac:0259`.

[ 2650.749585] usbcore: bcm5974 2-1.8.2:1.2: forced unbind
[ 2650.751511] bcm5974 2-1.8.2:1.2: trackpad urb shutting down: -2
[ 2650.752285] bcm5974: switched to normal mode.
[ 2650.776877] usbcore: usb 2-1.8-port2: not reset yet, waiting 10ms
[ 2650.838722] usb 2-1.8.2: reset full-speed USB device number 5 using ehci-pci
[ 2650.850861] usbcore: usb 2-1.8-port2: not reset yet, waiting 10ms
[ 2650.933792] usbcore: usbhid 2-1.8.2:1.2: usb_probe_interface
[ 2650.933808] usbcore: usbhid 2-1.8.2:1.2: usb_probe_interface - got id
[ 2650.933816] usbhid: drivers/hid/usbhid/hid-core.c: HID probe called
for ifnum 2
[ 2650.933856] hid: drivers/hid/hid-quirks.c: Found squirk 0x84000 for
HID device 0x05ac:0x0259
[ 2650.934811] usbcore: bcm5974 2-1.8.2:1.2: usb_probe_interface
[ 2650.934836] usbcore: bcm5974 2-1.8.2:1.2: usb_probe_interface - got id
[ 2650.935368] input: bcm5974 as
/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.8/2-1.8.2/2-1.8.2:1.2/input/input28
[ 2650.959530] bcm5974: switched to wellspring mode.
[ 2650.967511] bcm5974 2-1.8.2:1.2: trackpad urb shutting down: -2
[ 2650.968274] bcm5974: switched to normal mode.
[ 2650.974204] bcm5974: switched to wellspring mode.
[ 2650.981548] bcm5974 2-1.8.2:1.2: trackpad urb shutting down: -2
[ 2650.982406] bcm5974: switched to normal mode.
[ 2651.001294] bcm5974: switched to wellspring mode.
[ 2651.005533] bcm5974 2-1.8.2:1.2: trackpad urb shutting down: -2
[ 2651.006286] bcm5974: switched to normal mode.
[ 2651.016678] bcm5974: switched to wellspring mode.
[ 2651.023558] bcm5974 2-1.8.2:1.2: trackpad urb shutting down: -2
[ 2651.024432] bcm5974: switched to normal mode.
[ 2651.033633] bcm5974: switched to wellspring mode.
[ 2651.325355] bcm5974: bad trackpad package, length: 8
[ 2651.333339] bcm5974: bad trackpad package, length: 8
[ 2651.341311] bcm5974: bad trackpad package, length: 8

Adding a delay in bcm5974_probe() didn't seem to affect the multiple
open/close/modeswitch logs but it did end up in the correct state.

Liam

Re: bcm5974 trackpad broken after USB reset

[Henrik Rydberg]

[-- Attachment #1: Type: text/plain, Size: 781 bytes --]

> Thanks for the pointer. The wellspring mode switch is definitely
> attempted. The bcm5974 driver does the mode switching in input_dev
> open/close hooks. These are called multiple times after reset. See the
> following logs produced after `sudo usbreset 05ac:0259`.

Indeed, the correct path appears to be taken, so that was not it. Maybe 
the device internals do take some extra time to complete. Presumably 
there is a status field in the control message data; printing it out 
might reveal something.

Here is a completely untested patch which tries to verify that the mode 
is properly set, and dumps the control data in the process. With a bit 
of luck, this will just work because of the added delay, but if not, we 
might be able to figure out the status change.

Henrik


[-- Attachment #2: 0001-untested-bcm5974-verify-mode-switch.patch --]
[-- Type: text/x-patch, Size: 1740 bytes --]

From a0bbd6b5a9a4f05c85a252ace8129cda0689fb45 Mon Sep 17 00:00:00 2001
From: Henrik Rydberg <rydberg@bitmath.se>
Date: Sun, 18 Jan 2026 04:16:07 +0100
Subject: [PATCH] [untested] bcm5974: verify mode switch

---
 drivers/input/mouse/bcm5974.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
index dfdfb59cc8b5..cabe04d8e32d 100644
--- a/drivers/input/mouse/bcm5974.c
+++ b/drivers/input/mouse/bcm5974.c
@@ -648,6 +648,7 @@ static int bcm5974_wellspring_mode(struct bcm5974 *dev, bool on)
 {
 	const struct bcm5974_config *c = &dev->cfg;
 	int retval = 0, size;
+	int retries = 3;
 	char *data;
 
 	/* Type 3 does not require a mode switch */
@@ -661,6 +662,7 @@ static int bcm5974_wellspring_mode(struct bcm5974 *dev, bool on)
 		goto out;
 	}
 
+ again:
 	/* read configuration */
 	size = usb_control_msg(dev->udev, usb_rcvctrlpipe(dev->udev, 0),
 			BCM5974_WELLSPRING_MODE_READ_REQUEST_ID,
@@ -673,6 +675,18 @@ static int bcm5974_wellspring_mode(struct bcm5974 *dev, bool on)
 		goto out;
 	}
 
+	if (data[c->um_switch_idx] == (on ? c->um_switch_on : c->um_switch_off))
+		goto success;
+
+	if (!retries--) {
+		dprintk(2, "bcm5974: failed to switch to %s mode.\n",
+			on ? "wellspring" : "normal");
+		retval = -ENOENT;
+		goto out;
+	}
+
+	print_hex_dump_bytes("bcm5974: control data: ", DUMP_PREFIX_NONE, data, size);
+
 	/* apply the mode switch */
 	data[c->um_switch_idx] = on ? c->um_switch_on : c->um_switch_off;
 
@@ -688,6 +702,9 @@ static int bcm5974_wellspring_mode(struct bcm5974 *dev, bool on)
 		goto out;
 	}
 
+	goto again;
+
+ success:
 	dprintk(2, "bcm5974: switched to %s mode.\n",
 		on ? "wellspring" : "normal");
 
-- 
2.52.0

Re: bcm5974 trackpad broken after USB reset

[Liam Mitchell]

On Sun, 18 Jan 2026 at 04:32, Henrik Rydberg <rydberg@bitmath.se> wrote:
> Here is a completely untested patch which tries to verify that the mode
> is properly set, and dumps the control data in the process. With a bit
> of luck, this will just work because of the added delay, but if not, we
> might be able to figure out the status change.

No luck there. The control data is always exactly as written. I've
also tried logging the control data after longer delays but didn't see
anything different.

[  391.262674] usbcore: bcm5974 4-1.8.2:1.2: forced unbind
[  391.264601] bcm5974 4-1.8.2:1.2: trackpad urb shutting down: -2
[  391.265182] bcm5974: control data: 01 05 00 00 00 00 00 00
                ........
[  391.265992] bcm5974: switched to normal mode.
[  391.290770] usbcore: usb 4-1.8-port2: not reset yet, waiting 10ms
[  391.352802] usb 4-1.8.2: reset full-speed USB device number 5 using ehci-pci
[  391.364919] usbcore: usb 4-1.8-port2: not reset yet, waiting 10ms
[  391.447757] usbcore: usbhid 4-1.8.2:1.2: usb_probe_interface
[  391.447771] usbcore: usbhid 4-1.8.2:1.2: usb_probe_interface - got id
[  391.447779] usbhid: drivers/hid/usbhid/hid-core.c: HID probe called
for ifnum 2
[  391.447820] hid: drivers/hid/hid-quirks.c: Found squirk 0x84000 for
HID device 0x05ac:0x0259
[  391.449301] usbcore: bcm5974 4-1.8.2:1.2: usb_probe_interface
[  391.449329] usbcore: bcm5974 4-1.8.2:1.2: usb_probe_interface - got id
[  391.449692] input: bcm5974 as
/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.8/4-1.8.2/4-1.8.2:1.2/input/input16
[  391.482694] bcm5974: control data: 08 05 00 00 00 00 00 00
                ........
[  391.483487] bcm5974: switched to wellspring mode.
[  391.493648] bcm5974 4-1.8.2:1.2: trackpad urb shutting down: -2
[  391.494169] bcm5974: control data: 01 05 00 00 00 00 00 00
                ........
[  391.495142] bcm5974: switched to normal mode.
[  391.508166] bcm5974: control data: 08 05 00 00 00 00 00 00
                ........
[  391.509157] bcm5974: switched to wellspring mode.
[  391.514674] bcm5974 4-1.8.2:1.2: trackpad urb shutting down: -2
[  391.515205] bcm5974: control data: 01 05 00 00 00 00 00 00
                ........
[  391.516241] bcm5974: switched to normal mode.
[  391.536717] bcm5974: control data: 08 05 00 00 00 00 00 00
                ........
[  391.537626] bcm5974: switched to wellspring mode.
[  391.545669] bcm5974 4-1.8.2:1.2: trackpad urb shutting down: -2
[  391.546175] bcm5974: control data: 01 05 00 00 00 00 00 00
                ........
[  391.547089] bcm5974: switched to normal mode.
[  391.557783] bcm5974: control data: 08 05 00 00 00 00 00 00
                ........
[  391.558488] bcm5974: switched to wellspring mode.
[  391.568627] bcm5974 4-1.8.2:1.2: trackpad urb shutting down: -2
[  391.569033] bcm5974: control data: 01 05 00 00 00 00 00 00
                ........
[  391.569722] bcm5974: switched to normal mode.
[  391.584744] bcm5974: control data: 08 05 00 00 00 00 00 00
                ........
[  391.585475] bcm5974: switched to wellspring mode.
[  392.181559] bcm5974: bad trackpad package, length: 8

Liam

Re: bcm5974 trackpad broken after USB reset

[Liam Mitchell]

On Sun, 18 Jan 2026 at 17:14, Henrik Rydberg <rydberg@bitmath.se> wrote:
> I am wondering if we do the wrong thing with the controls... for TYPE2
> (and many others), we switch between 0x1 and 0x8, as per the code
>
> #define USBMSG_TYPE2            8, 0x300, 0, 0, 0x1, 0x8
>
> But that corresponds to a change in two bits. Quite possibly
> corresponding to reset and enable. It might be worth trying a
> single-state transition, i.e., changing the row above to
>
> #define USBMSG_TYPE2            8, 0x300, 0, 0, 0x1, 0x0
>
> and see if that helps.

I did a lot of experiments changing modes at different times and this
is what I understand:

0x8 ("normal") is pause/off. If this is set, no messages of any kind
will be received.
This is not the same as the default/init state (sending 8 byte
packets, HID?). Even though the first config read returns this (08 05
00 00 00 00 00 00), if you write the same bytes back, it will stop
sending the default 8 byte packets. I haven't found a way to re-enable
this default mode other than USB reset.

0x1 ("wellspring") enables multi-touch packets, how the driver has
been working for 18 years.

0x0 (suggested above) also enables "wellspring" multi-touch packets. I
noticed one major difference in my testing; that it seems to survive
suspend-resume without issues, whereas if the mode was 0x1 on suspend,
it will resume, report 0x0 in config and send default packets again.

Another interesting observation is that the first packet received (60
02, "control response ignored") comes reliably 120-140ms after USB
reset. Importantly, if you send 0x1 or 0x0 before this is received, it
will be ignored. It will update the config but won't take effect. From
this state you have to send 0x8, wait 1ms then send 0x1 (or 0x0) again
to enable wellspring mode.

The above will be why my mouse doesn't work after reset and why adding
msleep() in probe() fixed it.

I think a more permanent fix could be to set mode on receiving that
first packet (control response) and/or on receiving default 8 byte
packets.

I looked at the history of the module and saw that the first packet
has been ignored from the first version so I assume it works the same
across all hardware versions.

Liam

Re: bcm5974 trackpad broken after USB reset

[Henrik Rydberg]

Hi Liam,

 > I did a lot of experiments changing modes at different times and this
> is what I understand:
> 
> 0x8 ("normal") is pause/off. If this is set, no messages of any kind
> will be received.
> This is not the same as the default/init state (sending 8 byte
> packets, HID?). Even though the first config read returns this (08 05
> 00 00 00 00 00 00), if you write the same bytes back, it will stop
> sending the default 8 byte packets. I haven't found a way to re-enable
> this default mode other than USB reset.
> 
> 0x1 ("wellspring") enables multi-touch packets, how the driver has
> been working for 18 years.
> 
> 0x0 (suggested above) also enables "wellspring" multi-touch packets. I
> noticed one major difference in my testing; that it seems to survive
> suspend-resume without issues, whereas if the mode was 0x1 on suspend,
> it will resume, report 0x0 in config and send default packets again.
> 
> Another interesting observation is that the first packet received (60
> 02, "control response ignored") comes reliably 120-140ms after USB
> reset. Importantly, if you send 0x1 or 0x0 before this is received, it
> will be ignored. It will update the config but won't take effect. From
> this state you have to send 0x8, wait 1ms then send 0x1 (or 0x0) again
> to enable wellspring mode.

Looks like you made real progress here, great stuff! With this 
information, we should be able to provide a proper fix, agreed.

> The above will be why my mouse doesn't work after reset and why adding
> msleep() in probe() fixed it.
> 
> I think a more permanent fix could be to set mode on receiving that
> first packet (control response) and/or on receiving default 8 byte
> packets.

I like that, expecially if 0x08 never needs to be set, as touching that 
bit would require some sort of rougher handling. It was a bit uncelar if 
your experiment with the 0x00 mode went between 0x08/0x00 or 0x00/0x01.

> I looked at the history of the module and saw that the first packet
> has been ignored from the first version so I assume it works the same
> across all hardware versions.

Yes, the setup timing was never considered, and your suggestion should 
be a good fix for a lot of devices.

Thanks!
Henrik

Re: bcm5974 trackpad broken after USB reset

[Liam Mitchell]

On Mon, 26 Jan 2026 at 23:20, Henrik Rydberg <rydberg@bitmath.se> wrote:
> Looks like you made real progress here, great stuff! With this
> information, we should be able to provide a proper fix, agreed.

Thanks!

> > I think a more permanent fix could be to set mode on receiving that
> > first packet (control response) and/or on receiving default 8 byte
> > packets.
>
> I like that, expecially if 0x08 never needs to be set, as touching that
> bit would require some sort of rougher handling. It was a bit uncelar if
> your experiment with the 0x00 mode went between 0x08/0x00 or 0x00/0x01.

My previous experiment was between 0x08/0x00. I just tested switching
between 0x00/0x01 and don't see any immediate difference on switching,
just the mentioned difference after sleep/resume.

Regarding never setting 0x08, I see the commit message that introduced
this mentions dropping/repeating keys if 0x08 is not set before
closing (cd72ad3). I couldn't find any traces of this issue or
discussion online. Is it likely to still be an issue?

Liam