Race condition between bcm5974 and usbmouse kernel modules

[ryanm0]

System

• xuname:
  Void 5.9.16_1 x86_64 GenuineIntel uptodate rrFFF
• MacBook Pro 9,2 using bcm5974 touchpad. Other MacBooks using the same touchpad are likely also affected.
• package:
  linux-5.9_2, base-files-0.141_4

Description of issue

On Macbooks needing the bcm5974 driver for the trackpad, there is a race condition between the bcm5974 and usbmouse drivers. This causes the usbmouse driver to sometimes be used for the trackpad instead of the correct bcm5974 driver. When the usbmouse driver is used, the trackpad behaves incorrectly (can only scroll and move cursor vertically).

This is documented in the Linux kernel documentation for the bcm5974 driver:

The Apple multi-touch trackpads report both mouse and keyboard events via
different interfaces of the same usb device. This creates a race condition
with the HID driver, which, if not told otherwise, will find the standard
HID mouse and keyboard, and claim the whole device. To remedy, the usb
product id must be listed in the mouse_ignore list of the hid driver.

GNU Guix has dealt with the same issue in the past, see https://issues.guix.gnu.org/35574

Basically, what they found is that there are two ways to fix this:

1. The usbmouse module needs to be disabled in the kernel config (srcpkgs/linuxX.Y/files/*-dotconfig, the setting is called CONFIG_USB_MOUSE, currently it's set to be built as a module)
2. The usbmouse module needs to be blacklisted in the modprobe blacklist file (/usr/lib/modprobe.d/blacklist.conf, owned by the base-files package)

Either way is unlikely to cause problems for normal users, since the usbmouse (and usbkbd) modules are mainly meant to be used for embedded applications, not regular usb mice and keyboards (those are handled by the usbhid module). Quoting the Kconfig file for the usbmouse driver:

config USB_MOUSE
	tristate "USB HIDBP Mouse (simple Boot) support"
	depends on USB && INPUT
	help
	  Say Y here only if you are absolutely sure that you don't want
	  to use the generic HID driver for your USB mouse and prefer
	  to use the mouse in its limited Boot Protocol mode instead.

	  This is almost certainly not what you want.  This is mostly
	  useful for embedded applications or simple mice.

I'd be willing to create a PR to fix this, although I'm not sure which method of fixing this issue would be preferable for Void. Note that the Guix issue I've linked above has some discussion of both ways to solve the issue.

[fosslinux]

Why don't macbook users just blacklist usbmouse themselves?

Or, if according to the docs:

To remedy, the usb product id must be listed in the mouse_ignore list of the hid driver.

Why don't we do this by default then, instead of disabling another feature?

[ahesford]

I have a MacBook and the usbmouse/bcm5974 conflict is non-obvious. It took a bit of digging to figure out why my trackpad was misbehaving (I can't remember now if it was totally dead or had limited range of motion). It also requires a new initramfs because, if you forget to do that, your initramfs tends to load usbmouse before your Void installation can blacklist it.

Nevertheless, I agree with @fosslinux that we shouldn't be arbitrarily disabling features just because one class of users runs into some non-obvious behavior. The kernel docs recommend not saying Y because compiling it in-kernel probably makes it a lot harder to preempt. That is not the case for modules, which can be trivially blocked from loading.

The best way to address this problem might be a page on docs.voidlinux.org.

[ericonr]

Possible source of inspiration void-linux/void-docs#110

[ahesford]

Just looked at the hid_mouse_ignore_list in https://github.com/torvalds/linux/blob/master/drivers/hid/hid-quirks.c and it looks to me like the only option for ignoring the affected devices is to compile in the IDs. Unless I'm overlooking something, the right course of action would be updating the list upstream. I definitely do not think we should maintain a patch for this.

[ryanm0]

I agree, it probably would be best to avoid disabling that feature if it can be avoided.

Regarding the mouse_ignore list: It looks like the device ID (at least for my trackpad) is already in the hid_mouse_ignore_list (my trackpad has an ID of 05ac:0252 which corresponds to USB_DEVICE_ID_APPLE_WELLSPRING5A_ANSI). If my understanding of what's happening is correct, I think the mouse_ignore list might only be used by the usbhid module, and not by the usbmouse module that we're having a conflict with. I looked through https://github.com/torvalds/linux/blob/master/drivers/hid/usbhid/hid-core.c (for the regular usbhid module), and that looks to have code to handle device quirks, including ignoring the device, whereas https://github.com/torvalds/linux/blob/master/drivers/hid/usbhid/usbmouse.c (for usbmouse) looks like it doesn't have any of that. I guess that would explain why a lot of other distros blacklist the usbmouse module by default. That being said, I've never touched kernel or driver code, so I could definitely be overlooking something.

If creating a void docs page for this turns out to be the best solution, I could try working on a macbook page like the one @ericonr linked. However, since I have a different model of macbook than the original author of that PR, I've only experienced the trackpad issue and none of the other issues mentioned there.

[ryanm0]

As a side note, there's a good amount of other devices listed in the hid_have_special_driver list in hid-quirks.c. I wonder if any of those would have a similar conflict with the usbmouse/usbkbd modules.

[github-actions]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.