fwupd interferes with Kensington mouse #6871
Labels
Comments
|
Ugh, so I really didn't think getting the BOS descriptor would affect anything. 2/2 of the reports are Kensington mice, which might be helpful. Out of interest, does |
wshanks
changed the title
|
From internet searching, it seems like the mouse may have been manufactured in 2006, so it is pretty old. It hasn't otherwise given me any reason to replace it though. I changed the issue description because I had written it back when I thought it was important that the mouse was behind a dock and a hub. |
@superm1 okay if I add the VID/PID to an internal no-bos-descriptor flag or something like that? |
|
I mean it makes sense certainly as a bandaid; but are we missing something in the design? Should we maybe only be opting in devices with a manufacturing date that's new enough? |
Maybe!? Getting a USB descriptor shouldn't brick the device, and I'm also wondering how this doesn't break in Windows too.
How do we get the manufacturing date tho? |
|
@wshanks can you get us the |
I was naively hoping there was something in the descriptor to go on. If not; then lets see if there are any better heuristics. |
|
Here is the |
|
I can confirm the same with A4tech keyboard, Fedora 39 with fwupd-fwupd-1.9.14-1: Keyboard stopped working right after fwupd daemon restart during upgrade. |
hughsie
added a commit
that referenced
this issue
Mar 5, 2024
4 tasks
|
Also see hughsie/libgusb#117 -- one or the other is fine, and this is just covering both bases. |
hughsie
added a commit
that referenced
this issue
Mar 5, 2024
hughsie
added a commit
that referenced
this issue
Mar 5, 2024
hughsie
added a commit
that referenced
this issue
Mar 5, 2024
|
For googlers, this also seems to affect Ledger Nano X |
|
FYI This also affect Nostromo n52 gamepad. This makes it disconnect/reconnect in loop: [ 610.101511] hid-generic 0003:050D:0815.0386: input,hidraw1: USB HID v1.10 Mouse [Honey Bee Nostromo SpeedPad2 ] on usb-0000:05:00.3-1/input1 |
|
@kdj0c does that work in Windows? That's got bcdDevice= 2.10 and so should accept getting the BOS descriptors. I'm guessing stopping fwupd and then doing "sudo gusbcmd save" makes the device act in the same way? |
hughsie
added a commit
that referenced
this issue
Mar 11, 2024
4 tasks
hughsie
added a commit
that referenced
this issue
Mar 11, 2024
I don't have a windows installation here, so I don't know if it still works. Also here is the log when I run: fwupdtool get-devices --verbose --verbose 10:30:09.672 FuUsbDevice ignoring missing BOS descriptor: USB error on device 050d:0815 : Input/Output Error [-1] On Fedora 39, I fixed the issue by downgrading fwupd to fwupd-1.9.5-2.fc39. |
|
Same here, latest fwupd 1.9.14 breaks my old trustee Wacom Bamboo One. The device gets removed then re-added, then removed again continuously with fwupd 1.9.14. Reverting to 1.9.13 fixes that issue. Attaching lsusb-vvv.txt |
|
@ofourdan on a hunch, can you try the https://copr.fedorainfracloud.org/coprs/rhughes/fwupd/ build please |
|
Or you can grab snap/flatpak artifacts if it's easier depending on your distro. |
Works for me! 👍 |
Okay, so I think the last commit was unnecessary -- I think we just need a release with f92ea06 included. @superm1 I'm tempted to leave it in as an example on what to do -- and so we can quirk without a recompile if a broken USB 2.1 device turns up in the real world. Or maybe we remove the .quirk file and leave the code change? |
|
Let's leave both. I agree it's easier to quirk later if the infra is there. Who knows with ancient USB what we'll find! |
hughsie
added a commit
that referenced
this issue
Mar 11, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
A Kensington USB mouse (this one if it is relevant) stopped working after I applied the most recent updates on my Fedora 39 laptop (Lenovo ThinkPad T14 Gen 2). When I look at the system logs, I see
That message led me to this Debian mailing list post from a few days ago which describes a similar issue and goes into more detail of attempted debugging steps. For me, I found that the mouse just did not work at all, rather than partially working like reported there. I tried
systemctl stop fwupd.serviceand confirmed that the mouse started working again after unplugging it and plugging it back in.systemctl start fwupd.servicestopped the mouse from working once again. Checking the history of dnf updates, I see that thefwupdpackages were updated from 1.9.13 to 1.9.14:and I do not notice other relevant packages being updated (like something with
usbin the name).Like the mailing list post points out, the most suspicious line in the release notes for 1.9.14 seems to be "Fix DS-20 descriptors by opening the GUsbDevice earlier" and I noticed that is some previous discussion about difficulties with nested USB hubs here (the only thing that comes up when I search for "BOS descriptor").
One other note -- when I first noticed this, I actually had the mouse plugged into a StarTech USB hub (which lsusb detects as "Genesys Logic, Inc. GL3523 Hub") which was then plugged into a Lenovo Thunderbolt 4 dock which was plugged into the Thunderbolt 4 port of the laptop. However, I then tested and got the same issue both using the mouse plugged directly into the dock and using the mouse plugged directly into a usb port on the laptop.
Steps to Reproduce
This is mostly described above:
systemctl stop fwupd.servicesystemctl start fwupd.serviceIn my standard set up, I have a webcam and keyboard plugged into the StarTech hub plugged into the Thunderbolt 4 dock as well and they are not affected by fwupd.
Expected behavior
fwupd.serviceshould not stop the mouse from working.fwupd version information
Please provide the version of the daemon and client.
Please note how you installed it (
apt,dnf,pacman, source, etc): dnf**fwupd device information**
Please provide the output of the fwupd devices recognized in your system.
NOTE: I ran this without the Thunderbolt 4 dock or the StarTech hub for simplicity, so it should just be a standard Thinkpad T14 Gen 2 output with a USB mouse plugged in.
Additional questions
The text was updated successfully, but these errors were encountered: