Re: [ISSUE] [CLOSED] Race condition between bcm5974 and usbmouse kernel modules

[github-actions[bot] <github-actions[bot]@users.noreply.github.com>]

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

Closed issue by ryanm0 on void-packages repository

https://github.com/void-linux/void-packages/issues/27465

Description:
### 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](https://www.kernel.org/doc/html/v4.12/input/devices/bcm5974.html#usb-race):
```
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](https://github.com/torvalds/linux/blob/master/drivers/hid/usbhid/Kconfig):
```
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.