bcm5974 touchpad is not recognized as touchpad

On *some* reboots my Macbook’s touchpad does not work properly; it

behaves like mouse wheel, I can only scroll. Only when I press it

down, I can move the pointer to the right, but never to the left.

This happens both with synaptics and libinput driver.

Restarting xorg-server does not help; this appears to be an issue with

the order in which udev rules are applied.

Apparently my bcm5974 touchpad is recognized by udev as a mouse

sometimes (?), because when diffing /var/log/gdm/greeter.log I see a

mouse being recognized (it is never called bcm5974) instead of a

bcm5974 touchpad.

$ sudo diff /var/log/gdm/greeter.log.1 /var/log/gdm/greeter.log.2

[…]

381,387c381,387

< (II) config/udev: Adding input device Apple Inc. Apple Internal Keyboard / Trackpad (/dev/input/event14)

< (**) Apple Inc. Apple Internal Keyboard / Trackpad: Applying InputClass "evdev pointer catchall"

< (**) Apple Inc. Apple Internal Keyboard / Trackpad: Applying InputClass "libinput pointer catchall"

< (II) Using input driver 'libinput' for 'Apple Inc. Apple Internal Keyboard / Trackpad'

< (II) systemd-logind: got fd for /dev/input/event14 13:78 fd 32 paused 0

< (**) Apple Inc. Apple Internal Keyboard / Trackpad: always reports core events

< (**) Option "Device" "/dev/input/event14"

---

389,393c389,393

< (II) event14 - Apple Inc. Apple Internal Keyboard / Trackpad: is tagged by udev as: Mouse

< (II) event14 - Apple Inc. Apple Internal Keyboard / Trackpad: device is a pointer

< (II) event14 - Apple Inc. Apple Internal Keyboard / Trackpad: device removed

< (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:06.0/usb4/4-3/4-3:1.2/input/input14/event14"

< (II) XINPUT: Adding extended input device "Apple Inc. Apple Internal Keyboard / Trackpad" (type: MOUSE, id 12)

---

395,400c395,400

< (**) Apple Inc. Apple Internal Keyboard / Trackpad: (accel) selected scheme none/0

< (**) Apple Inc. Apple Internal Keyboard / Trackpad: (accel) acceleration factor: 2.000

< (**) Apple Inc. Apple Internal Keyboard / Trackpad: (accel) acceleration threshold: 4

< (II) event14 - Apple Inc. Apple Internal Keyboard / Trackpad: is tagged by udev as: Mouse

< (II) event14 - Apple Inc. Apple Internal Keyboard / Trackpad: device is a pointer

< (II) config/udev: Adding input device Apple Inc. Apple Internal Keyboard / Trackpad (/dev/input/mouse1)

---

[…]

Regards,

Florian

Addendum: This never happened during half a year of using Debian 9.

It did happen on GuixSD half a year ago.

This happens on linux-libre-4.9 (same Linux base version as Debian 9)

as well as on what recently was current linux-libre (which I can no

longer use with my GPU since a few weeks ago). I therefore believe

the kernel to be unrelated, unless there are some patches in Debian

but not in recent Linux.

Regards,

Florian

Now that I know wisdomlight has the issue too on their Macbook Air

https://lists.gnu.org/archive/html/help-guix/2020-01/msg00105.html I

investigated further.

From the Linux kernel docs

https://www.kernel.org/doc/html/latest/input/devices/bcm5974.html:

Indeed for me on good boots, the command `lsusb -t` prints

|__ Port 3: Dev 2, If 2, Class=Human Interface Device, Driver=bcm5974, 12M

while on bad boots it says Driver=usbmouse.

But why that happens I do not know, because the mouse_ignore list in

the Linux-libre kernel’s drivers/hid/hid-quirks.c file does list my

touchpad. Strange. I will investigate further if a change to the

kernel config could help.

Regards,

Florian

On Fri, Jan 17, 2020 at 12:35:39AM +0100, pelzflorian (Florian Pelz) wrote:

The issue with Macbook bcm5974 touchpads is a race between the bcm5974

kernel module and the usbmouse kernel module, especially on cold

boots. Indeed a remedy is to run as root

rmmod usbmouse

rmmod bcm5974

modprobe bcm5974

Then the touchpad works again in all directions and not just for

scrolling up-down. The converse is also true;

rmmod bcm5974

rmmod usbmouse

modprobe usbmouse

breaks the touchpad again.

However I also cannot find the reason why this usbmouse loadable

kernel module gets loaded at all. How can I debug what loads this

kernel module? Debian does not show usbmouse in lsmod, and I think

usbmouse should not get loaded in Guix either. usbmouse is not

required for my external USB mouse to work.

To quote the linux-4.19.95 source file 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.

Other workarounds I tried were using Wayland instead of X11, but sway

does not run for me, weston does not build and sddm set to Wayland or

a GNOME Wayland session exhibit the same mouse issue. Building a

kernel with these modules built-in instead of loadable (=y instead of

=m in the kernel config) helped, but I suppose the modules should be

loadable.

Regards,

Florian

On Mon, Apr 20, 2020 at 04:47:18PM +0200, pelzflorian (Florian Pelz) wrote:

Debian 10’s /boot/config-4.19.0-6-amd64 has

# USB HID Boot Protocol drivers

#

# CONFIG_USB_KBD is not set

# CONFIG_USB_MOUSE is not set

while Guix has in /tmp/guix-build-linux-libre-5.4.32.drv-0/linux-5.4.32/.config

CONFIG_USB_MOUSE=m

I will write and test a patch to disable the module in

%default-extra-linux-options, like the description in linux-5.4.11

source file drivers/hid/usbhid/Kconfig recommends:

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.

To compile this driver as a module, choose M here: the

module will be called usbmouse.

If even remotely unsure, say N.

Regards,

Florian

Hi Fllorian,

On +2020-04-20 17:59:08 +0200, pelzflorian (Florian Pelz) wrote:

Could the module be needed "just in case" in an initrd

but should be unloaded before pivoting in a normal case?

--

Regards,

Bengt Richter

On Mon, Apr 20, 2020 at 05:59:08PM +0200, pelzflorian (Florian Pelz) wrote:

The attached patch disables the usbmouse kernel module in the options

for linux-libre. Otherwise, as described previously, the bcm5974

touchpad of Macbooks often erroneously gets assigned the usbmouse

kernel module instead of the bcm5974 kernel module.

Other than Macbooks, usbmouse is not used by any of my actual USB mice

and touchpads anyway (they use usbhid). I cannot know if there are

exotic mice that need usbmouse, but Debian disables the usbmouse

module too and the description in the Linux kernel says about the

usbmouse module:

I tested the patch with linux-libre 5.4 on various x86_64 machines and

I tested 5.4, 4.19 and 4.4 on my Macbook. I did not wait for

compilation to complete on non-Intel architectures, but I doubt the

patch causes problems.

I suppose this can go directly to master even though it requires the

linux-libre to be rebuilt?

Regards,

Florian

From d9f9d4c34a8f4d42af3e90789267137d15d60bb9 Mon Sep 17 00:00:00 2001

Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

This avoids a race with the bcm5974 kernel module.

Fixes https://bugs.gnu.org/35574.

Disable CONFIG_USB_MOUSE.

---

gnu/packages/linux.scm | 5 ++++-

1 file changed, 4 insertions(+), 1 deletion(-)

On Tue, Apr 21, 2020 at 12:26:07AM +0200, Bengt Richter wrote:

I don’t think normal USB mice need the module because they use the

usbhid kernel module. Maybe there are exotic mice, but I don’t think

they are important (see the message where I attached the patch now).

Regards,

Florian

Hello Florian,

Thanks for fixing this! This seems like a reasonable choice. However, I

noticed that on Ubuntu, CONFIG_USB_MOUSE is set to 'M'. So maybe they

have some special udev/blacklist rules to handle this case?

Yes, the kernel is frequently updated on master anyways.

Thanks,

Mathieu

On Mon, Apr 27, 2020 at 08:36:37AM +0200, Mathieu Othacehe wrote:

Interesting. Thank you for checking. So maybe setting

CONFIG_USB_MOUSE=n in the kernel config is the wrong way. I installed

Ubuntu and they just have a file /etc/modprobe.d/blacklist.conf

containing the lines

# these drivers are very simple, the HID drivers are usually preferred

blacklist usbmouse

blacklist usbkbd

I wonder if a default blacklist file would be more like the Guix way.

Or default blacklist kernel-arguments? I remember a discussion by

Danny Milosavljevic and Brice Waegeneire about this at

https://bugs.gnu.org/40274#128. All these avoid recompiling the

linux-libre package.

Danny, Brice, I’m putting you in Cc, maybe you have an opinion on

this? I suppose I should not change %default-extra-linux-options.

Regards,

Florian

Hello Florian,

On 2020-04-28 09:45, pelzflorian (Florian Pelz) wrote:

Keeping this module enabled in the kernel seems a good idea, it allows

support for mice solely speaking Human Interface Device Boot Protocol

(HIDBP); probably somebody somewhere is unwittingly relying on it being

present by default in Guix.

FWI the issue span from the driver 'usbmouse'

(drivers/hid/usbhid/usbmouse.c) which doesn't use

drivers/hid/hid-quirks.c

contrary to 'usbhid' (drivers/hid/usbhid/hid-core.c) which is using it.

This is probably why you did not report having an issue with 'usbhid'

racing with 'bcm597'; 'usbhid' is effectively prevented to take over

your

touchpad by the quirks while 'usbmouse' isn't aware of it.

Passing arguments to the kernel to blacklist a module is the correct way

of

doing this currently FWIU; it's already used in gnu/system/install.scm.

Cheers,

- Brice

On Tue, Apr 28, 2020 at 02:10:58PM +0000, Brice Waegeneire wrote:

Thank you. Shall I push the attached patch?

Regards,

Florian

From 67f8a33e669adc24ca2429e500a5137f12497191 Mon Sep 17 00:00:00 2001

Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

kernel-arguments.

This avoids a race with the bcm5974 kernel module.

Fixes https://bugs.gnu.org/35574.

(<operating-system>)[kernel-arguments]: Default to ...

(%default-kernel-arguments): ... this new variable.

---

doc/guix.texi | 2 +-

gnu/system.scm | 16 ++++++++++++++--

2 files changed, 15 insertions(+), 3 deletions(-)

Hello Florian,

This seems indeed better than not building the module.

I know that (for now) having a mouse in the installer is not very

useful. But maybe `kernel-arguments' in (gnu system install) should

inherit from this field?

Thanks,

Mathieu

On Wed, Apr 29, 2020 at 05:38:02PM +0200, Mathieu Othacehe wrote:

Actually in my tests I no longer need the modprobe.blacklist=radeon on

my AMD PC. I suggest the attached revert instead and will push it if

there are no objections.

Regards,

Florian

On Wed, Apr 29, 2020 at 06:41:22PM +0200, pelzflorian (Florian Pelz) wrote:

Forgot attachment.

Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

This reverts commit 785919121066a10b291d783b6903b5e368e992a8, which is no longer

needed since uvesafb was added in 557e6820a77b24f8f3f03f28ee473137b1caeb64.

---

gnu/system/install.scm | 6 ------

1 file changed, 6 deletions(-)

This patch and the associated revert look fine to me. Let's maybe wait

for Brice opinion.

In the meantime, if you could give me your opinion on:

it would be great :)

Thanks,

Mathieu

On 2020-04-29 18:31, Mathieu Othacehe wrote:

LGTM! I wonder if, as Ubuntu, we should also blacklist “usbkbd” the

counterpart of “usbmouse” or just to wait a bug report about it - if

it ever happen.

- Brice

On Wed, Apr 29, 2020 at 06:41:20PM +0200, pelzflorian (Florian Pelz) wrote:

Reverted as 73ddcab6075f60ef9b3cd72a35fbf7f5d622b6ef.

On Wed, Apr 29, 2020 at 06:46:51PM +0000, Brice Waegeneire wrote:

I will add usbkbd to the blacklist because

https://www.willemp.be/cw/usbkbd/ claims there is a race with the

usbhid module and the Linux kernel documentation says usbhid has more

features and “Use usbhid instead if there isn’t any special reason to

use this.”

Thank you!

Regards,

Florian

Pushed as e06664da02a829c7fa8fd084aac47c837451d57a. Closing.