bcm5974 touchpad is not recognized as touchpad

  • Done
  • quality assurance status badge
Details
4 participants
  • Bengt Richter
  • Brice Waegeneire
  • Mathieu Othacehe
  • pelzflorian (Florian Pelz)
Owner
unassigned
Submitted by
pelzflorian (Florian Pelz)
Severity
normal
P
P
pelzflorian (Florian Pelz) wrote on 5 May 2019 08:54
(address . bug-guix@gnu.org)
20190505065411.2rb5aqaaxywc4qvk@pelzflorian.localdomain
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"
---
Toggle quote (7 lines)
> (II) config/udev: Adding input device bcm5974 (/dev/input/event12)
> (**) bcm5974: Applying InputClass "evdev touchpad catchall"
> (**) bcm5974: Applying InputClass "libinput touchpad catchall"
> (II) Using input driver 'libinput' for 'bcm5974'
> (II) systemd-logind: got fd for /dev/input/event12 13:76 fd 32 paused 0
> (**) bcm5974: always reports core events
> (**) Option "Device" "/dev/input/event12"
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)
---
Toggle quote (5 lines)
> (II) event12 - bcm5974: is tagged by udev as: Touchpad
> (II) event12 - bcm5974: device is a touchpad
> (II) event12 - bcm5974: device removed
> (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:06.0/usb4/4-3/4-3:1.2/input/input12/event12"
> (II) XINPUT: Adding extended input device "bcm5974" (type: TOUCHPAD, 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)
---
Toggle quote (6 lines)
> (**) bcm5974: (accel) selected scheme none/0
> (**) bcm5974: (accel) acceleration factor: 2.000
> (**) bcm5974: (accel) acceleration threshold: 4
> (II) event12 - bcm5974: is tagged by udev as: Touchpad
> (II) event12 - bcm5974: device is a touchpad
> (II) config/udev: Adding input device bcm5974 (/dev/input/mouse0)
[…]

Regards,
Florian
P
P
pelzflorian (Florian Pelz) wrote on 5 May 2019 09:41
(address . 35574@debbugs.gnu.org)
20190505074152.ttmow2unsscdovhz@pelzflorian.localdomain
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
P
P
pelzflorian (Florian Pelz) wrote on 17 Jan 2020 00:35
(address . 35574@debbugs.gnu.org)(address . wisdomlight@protonmail.com)
20200116233537.myczkgkwnfpn75hu@pelzflorian.localdomain
Now that I know wisdomlight has the issue too on their Macbook Air
investigated further.

From the Linux kernel docs
Toggle quote (9 lines)
> 5.2. 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.

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
P
P
pelzflorian (Florian Pelz) wrote on 20 Apr 2020 16:47
(address . 35574@debbugs.gnu.org)(address . wisdomlight@protonmail.com)
20200420144718.ehopbrz7hzvn5vxx@pelzflorian.localdomain
On Fri, Jan 17, 2020 at 12:35:39AM +0100, pelzflorian (Florian Pelz) wrote:
Toggle quote (4 lines)
> 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.

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
P
P
pelzflorian (Florian Pelz) wrote on 20 Apr 2020 17:59
(address . 35574@debbugs.gnu.org)
20200420155908.ulewy4c2vqkuzgfr@pelzflorian.localdomain
On Mon, Apr 20, 2020 at 04:47:18PM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (6 lines)
> 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.

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
B
B
Bengt Richter wrote on 21 Apr 2020 00:26
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 35574@debbugs.gnu.org)
20200420222607.GA4620@LionPure
Hi Fllorian,

On +2020-04-20 17:59:08 +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (4 lines)
> On Mon, Apr 20, 2020 at 04:47:18PM +0200, pelzflorian (Florian Pelz) wrote:
> > However I also cannot find the reason why this usbmouse loadable
> > kernel module gets loaded at all. How can I debug what loads this

Could the module be needed "just in case" in an initrd
but should be unloaded before pivoting in a normal case?

Toggle quote (40 lines)
> > 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.
>
> 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
>
>
>
--
Regards,
Bengt Richter
P
P
pelzflorian (Florian Pelz) wrote on 27 Apr 2020 02:28
(address . 35574@debbugs.gnu.org)
20200427002857.apq5nreio5kllpoq@pelzflorian.localdomain
On Mon, Apr 20, 2020 at 05:59:08PM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (4 lines)
> 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:

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:
Toggle quote (3 lines)
> This is almost certainly not what you want. This is mostly
> useful for embedded applications or simple mice.

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
From: Florian Pelz <pelzflorian@pelzflorian.de>
Date: Mon, 20 Apr 2020 19:03:57 +0200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] gnu: linux-libre: Disable usbmouse kernel module.

This avoids a race with the bcm5974 kernel module.

* gnu/packages/linux.scm (%default-extra-linux-options):
Disable CONFIG_USB_MOUSE.
---
gnu/packages/linux.scm | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

Toggle diff (25 lines)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 2acbe649f0..5f2f17b31a 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -42,6 +42,7 @@
;;; Copyright � 2020 Pierre Neidhardt <mail@ambrevar.xyz>
;;; Copyright � 2020 Chris Marusich <cmmarusich@gmail.com>
;;; Copyright � 2020 Vincent Legoll <vincent.legoll@gmail.com>
+;;; Copyright � 2020 Florian Pelz <pelzflorian@pelzflorian.de>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -618,7 +619,9 @@ for ARCH and optionally VARIANT, or #f if there is no such configuration."
("CONFIG_VIRTIO_MMIO" . m)
("CONFIG_FUSE_FS" . m)
("CONFIG_CIFS" . m)
- ("CONFIG_9P_FS" . m)))
+ ("CONFIG_9P_FS" . m)
+ ;; These modules cause trouble:
+ ("CONFIG_USB_MOUSE" . #f))) ;see <https://bugs.gnu.org/35574>
(define (config->string options)
(string-join (map (match-lambda
--
2.26.1
P
P
pelzflorian (Florian Pelz) wrote on 27 Apr 2020 02:32
(name . Bengt Richter)(address . bokr@bokr.com)(address . 35574@debbugs.gnu.org)
20200427003254.c4zr6bcwdd2uxjx3@pelzflorian.localdomain
On Tue, Apr 21, 2020 at 12:26:07AM +0200, Bengt Richter wrote:
Toggle quote (3 lines)
> Could the module be needed "just in case" in an initrd
> but should be unloaded before pivoting in a normal case?

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
M
M
Mathieu Othacehe wrote on 27 Apr 2020 08:36
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 35574@debbugs.gnu.org)
87pnbtwi2y.fsf@gmail.com
Hello Florian,

Toggle quote (5 lines)
> 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.

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?

Toggle quote (3 lines)
> I suppose this can go directly to master even though it requires the
> linux-libre to be rebuilt?

Yes, the kernel is frequently updated on master anyways.

Thanks,

Mathieu
P
P
pelzflorian (Florian Pelz) wrote on 28 Apr 2020 11:45
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)
20200428094502.cduna7cyerl77ouq@pelzflorian.localdomain
On Mon, Apr 27, 2020 at 08:36:37AM +0200, Mathieu Othacehe wrote:
Toggle quote (4 lines)
> 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?

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
B
B
Brice Waegeneire wrote on 28 Apr 2020 16:10
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
eec008869e0cd1e021617134a27acb56@waegenei.re
Hello Florian,

On 2020-04-28 09:45, pelzflorian (Florian Pelz) wrote:
Toggle quote (3 lines)
> 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.

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.

Toggle quote (20 lines)
> From the Linux kernel docs
> <https://www.kernel.org/doc/html/latest/input/devices/bcm5974.html>:
>> 5.2. 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.
> 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.

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
P
P
pelzflorian (Florian Pelz) wrote on 29 Apr 2020 17:27
(name . Brice Waegeneire)(address . brice@waegenei.re)
20200429152736.xocwatxukviul3bl@pelzflorian.localdomain
On Tue, Apr 28, 2020 at 02:10:58PM +0000, Brice Waegeneire wrote:
Toggle quote (5 lines)
> Keeping this module enabled in the kernel seems a good idea,
> […]
> 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.

Thank you. Shall I push the attached patch?

Regards,
Florian
From 67f8a33e669adc24ca2429e500a5137f12497191 Mon Sep 17 00:00:00 2001
From: Florian Pelz <pelzflorian@pelzflorian.de>
Date: Wed, 29 Apr 2020 17:17:55 +0200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] system: Blacklist usbmouse kernel module in default
kernel-arguments.

This avoids a race with the bcm5974 kernel module.

* gnu/system.scm (%default-modprobe-blacklist): New variable.
(<operating-system>)[kernel-arguments]: Default to ...
(%default-kernel-arguments): ... this new variable.
* doc/guix.texi (operating-system Reference): Document the change.
---
doc/guix.texi | 2 +-
gnu/system.scm | 16 ++++++++++++++--
2 files changed, 15 insertions(+), 3 deletions(-)

Toggle diff (63 lines)
diff --git a/doc/guix.texi b/doc/guix.texi
index d0592220a7..c87283d97f 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -11274,7 +11274,7 @@ possible to use the GNU@tie{}Hurd.}.
A list of objects (usually packages) to collect loadable kernel modules
from--e.g. @code{(list ddcci-driver-linux)}.
-@item @code{kernel-arguments} (default: @code{'("quiet")})
+@item @code{kernel-arguments} (default: @code{%default-kernel-arguments})
List of strings or gexps representing additional arguments to pass on
the command-line of the kernel---e.g., @code{("console=ttyS0")}.
diff --git a/gnu/system.scm b/gnu/system.scm
index 3c511f4089..ab6982ef5e 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -7,6 +7,7 @@
;;; Copyright � 2019 Meiyo Peng <meiyo.peng@gmail.com>
;;; Copyright � 2020 Danny Milosavljevic <dannym@scratchpost.org>
;;; Copyright � 2020 Brice Waegeneire <brice@waegenei.re>
+;;; Copyright � 2020 Florian Pelz <pelzflorian@pelzflorian.de>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -148,7 +149,8 @@
%base-packages-linux
%base-packages-networking
%base-packages-utils
- %base-firmware))
+ %base-firmware
+ %default-kernel-arguments))
;;; Commentary:
;;;
@@ -179,7 +181,7 @@
(kernel-loadable-modules operating-system-kernel-loadable-modules
(default '())) ; list of packages
(kernel-arguments operating-system-user-kernel-arguments
- (default '("quiet"))) ; list of gexps/strings
+ (default %default-kernel-arguments)) ; list of gexps/strings
(bootloader operating-system-bootloader) ; <bootloader-configuration>
(label operating-system-label ; string
(thunked)
@@ -488,6 +490,16 @@ possible (that is if there's a LINUX keyword argument in the build system)."
((#:linux kernel #f)
target-kernel)))))
+(define %default-modprobe-blacklist
+ ;; List of kernel modules to blacklist by default.
+ '("usbmouse")) ;see <https://bugs.gnu.org/35574>
+
+(define %default-kernel-arguments
+ ;; Default arguments passed to the kernel.
+ (list (string-append "modprobe.blacklist="
+ (string-join %default-modprobe-blacklist ","))
+ "quiet"))
+
(define* (operating-system-directory-base-entries os)
"Return the basic entries of the 'system' directory of OS for use as the
value of the SYSTEM-SERVICE-TYPE service."
--
2.26.1
M
M
Mathieu Othacehe wrote on 29 Apr 2020 17:38
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87zhauwbdx.fsf@gmail.com
Hello Florian,

Toggle quote (3 lines)
> This avoids a race with the bcm5974 kernel module.
> Fixes <https://bugs.gnu.org/35574>.

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
P
P
pelzflorian (Florian Pelz) wrote on 29 Apr 2020 18:41
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)
20200429164120.fousoswocdgsralr@pelzflorian.localdomain
On Wed, Apr 29, 2020 at 05:38:02PM +0200, Mathieu Othacehe wrote:
Toggle quote (4 lines)
> 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?

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
P
P
pelzflorian (Florian Pelz) wrote on 29 Apr 2020 18:42
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)
20200429164247.xvipdobeutvvhron@pelzflorian.localdomain
On Wed, Apr 29, 2020 at 06:41:22PM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (2 lines)
> I suggest the attached revert instead

Forgot attachment.
From: Florian Pelz <pelzflorian@pelzflorian.de>
Date: Wed, 29 Apr 2020 18:22:48 +0200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] Revert "install: Pass "modprobe.blacklist=radeon"."

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(-)

Toggle diff (19 lines)
diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index d31ed9a197..8804585215 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -471,12 +471,6 @@ Access documentation at any time by pressing Alt-F2.\x1b[0m
(label (string-append "GNU Guix installation "
(package-version guix)))
- ;; XXX: The AMD Radeon driver is reportedly broken, which makes kmscon
- ;; non-functional:
- ;; <https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00441.html>.
- ;; Thus, blacklist it.
- (kernel-arguments '("quiet" "modprobe.blacklist=radeon"))
-
(file-systems
;; Note: the disk image build code overrides this root file system with
;; the appropriate one.
--
2.26.1
M
M
Mathieu Othacehe wrote on 29 Apr 2020 20:31
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87h7x2ywgw.fsf@gmail.com
Toggle quote (3 lines)
> On Wed, Apr 29, 2020 at 06:41:22PM +0200, pelzflorian (Florian Pelz) wrote:
>> I suggest the attached revert instead

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
B
B
Brice Waegeneire wrote on 29 Apr 2020 20:46
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)
a05761af67fe842601dc4f520244c9e5@waegenei.re
On 2020-04-29 18:31, Mathieu Othacehe wrote:
Toggle quote (15 lines)
>> On Wed, Apr 29, 2020 at 06:41:22PM +0200, pelzflorian (Florian Pelz)
>> wrote:
>>> I suggest the attached revert instead
>
> 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:
> https://lists.gnu.org/archive/html/guix-patches/2020-04/msg00707.html,
> it would be great :)
>
> Thanks,
>
> Mathieu

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
P
P
pelzflorian (Florian Pelz) wrote on 1 May 2020 10:33
(address . 35574@debbugs.gnu.org)
20200501083330.u5fwcuhxu4yxcwwc@pelzflorian.localdomain
On Wed, Apr 29, 2020 at 06:41:20PM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (4 lines)
> 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.

Reverted as 73ddcab6075f60ef9b3cd72a35fbf7f5d622b6ef.
P
P
pelzflorian (Florian Pelz) wrote on 1 May 2020 10:57
(name . Brice Waegeneire)(address . brice@waegenei.re)
20200501085719.b2ewxlbgtcl2lhxw@pelzflorian.localdomain
On Wed, Apr 29, 2020 at 06:46:51PM +0000, Brice Waegeneire wrote:
Toggle quote (4 lines)
> 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.

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
P
P
pelzflorian (Florian Pelz) wrote on 1 May 2020 11:15
(address . 35574-done@debbugs.gnu.org)
20200501091547.5jvxxvkoc3f4qh2m@pelzflorian.localdomain
Pushed as e06664da02a829c7fa8fd084aac47c837451d57a. Closing.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 35574@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 35574
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch