lsusb now shows [unknown] for items it didn't before

OpusOne · 2023-10-26 01:32:46

Hi, as the title says, I just noticed that lsusb seems to have changed behaviors recently (not sure from which update though, as I hadn't used lsusb in a couple weeks), and it now displays [unknown] for a lot of items (such as product string) for which it used to display the item in clear before.
Not sure if it could be linked to the hwdata 0.375-2 update, or something else.

For instance, for my mouse:

Bus 003 Device 007: ID 1e7d:2de6 ROCCAT [unknown]

It used to display the product name in clear before, rather than '[unknown]'. The same for a number of other USB devices.

Can anyone try and see if they notice the same behavior? Do you see an explanation?

seth · 2023-10-26 07:31:46

Sanity check:

uname -a
pacman -Qs kernel

and try the behavior w/ the LTS kernel and post the full lsusb output(s) - that USB ID isn't in the USB IDs since a spring (dunno whether it ever was)

OpusOne · 2023-10-26 21:57:29

Linux xxx 6.5.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 19 Oct 2023 22:52:14 +0000 x86_64 GNU/Linux

Digging a bit more, the reason this [unknown] mention appeared can be seen here, it's a recent change in usbutils:
https://git.kernel.org/pub/scm/linux/ke … 566deefe66

This change is supposed to replace an empty string wiith "[unknown]" though, but I am 100% positive the full names appeared before, up to maybe 2 weeks ago.

Another example I get is this:
2109:0817 VIA Labs, Inc. [unknown]

So it would just be a matter of both this recent usbutils change and a recent hwdata change I suppose?
I've never looked at the source code for lsusb, but I was under the impression that it would display the vendor and product strings (read during enumeration) when the IDs were not in the usb.ids list, and it doesn't anymore. The reason I always assumed that is that it did show the vendor and product strings of my custom USB devices that are absolutely not in any official ID list. And now, it shows nothing.

So apart from the lsusb change mentioned above, I'm still looking for another change in lsusb in their commit list that would explain this.

seth · 2023-10-27 06:52:38

The point of the two commands was to see whether installed and booted kernel are aligned, but I've seen the "unknown" in a different thread meanwhile.

I was under the impression that it would display the vendor and product strings (read during enumeration) when the IDs were not in the usb.ids list, and it doesn't anymore.

Hence the question for the kernel alignment and the LTS kernel (to see whether things fail at the enumeration or lsusb using it)

You can also try to downgrade usbutils to 15-3

OpusOne · 2023-10-27 07:25:10

No no, it's not on a kernel level - I can get the USB strings just fine looking in /sys/bus/usb/devices/

For instance,

cat /sys/bus/usb/devices/3-10.2/product

And yes, the installed and booted kernel is the same - I currently have only installed, and only use the default 'linux' package.

I'm starting to wonder whether I was not just dreaming and lsusb never displayed strings from the USB descriptors if the IDs where not in the usb.ids list. But somehow I'm pretty sure it did. Or the fact that it now displays "[unknown]" instead of nothing has made me more conscious of the absence of info?
Weird. Not that it's a huge problem, but as I'm developing USB devices, I found it pretty useful to be able to see that quickly with lsusb - obviously there are other ways to skin the cat here and they'll be fine if lsusb doesn't do what I was expecting anymore.

I'll try to downgrade and see if indeed I was just daydreaming.

Edit: I just downgraded to usbutils-015-3 and I can confirm it effectively did what I remembered it did. For the same device, lsusb gives:

Bus 003 Device 007: ID 1e7d:2de6 ROCCAT ROCCAT Burst Core

and same for all other devices for which usbutils-016 gives [unknown] instead.

I don't know if this change is intentional or not. I haven't read anything about that in the list of commits for usbutils-016. The only thing that I noticed, as I mentioned, is that they have added this '[unknown]' mention (so this is an intentional change), but it was supposed to replace empty strings.
I'm starting to guess that this change has implied a regression as they may directly display it if the USB VID or PID is not in the list, while it looked for the corresponding descriptor string before.

Last edited by OpusOne (2023-10-27 07:36:56)

seth · 2023-10-27 11:54:29

https://git.kernel.org/pub/scm/linux/ke … 566deefe66
Seems like overkill and the "0" was likely used higher up to feed the data from the device.

=> https://github.com/gregkh/usbutils/issues?q=is%3Aissue

OpusOne · 2023-10-27 19:40:30

seth wrote:

https://git.kernel.org/pub/scm/linux/ke … 566deefe66
Seems like overkill and the "0" was likely used higher up to feed the data from the device.

Yes, that's the likely source of regression, although I haven't looked at the code calling this function. But yes snprintf() will definitely not return 0, so the behavior of the caller is changed completely.
I will report it. If they happen to care.

seth · 2023-10-27 20:05:26

Ftr, https://github.com/gregkh/usbutils/issues/177

Arch Linux

#1 2023-10-26 01:32:46

lsusb now shows [unknown] for items it didn't before

#2 2023-10-26 07:31:46

Re: lsusb now shows [unknown] for items it didn't before

#3 2023-10-26 21:57:29

Re: lsusb now shows [unknown] for items it didn't before

#4 2023-10-27 06:52:38

Re: lsusb now shows [unknown] for items it didn't before

#5 2023-10-27 07:25:10

Re: lsusb now shows [unknown] for items it didn't before

#6 2023-10-27 11:54:29

Re: lsusb now shows [unknown] for items it didn't before

#7 2023-10-27 19:40:30

Re: lsusb now shows [unknown] for items it didn't before

#8 2023-10-27 20:05:26

Re: lsusb now shows [unknown] for items it didn't before

Board footer