Re: New inxi feature, /sys based usb data
Posted: Tue Aug 14, 2018 9:19 pm
pinxi 3.0.20-29 now fixes or enhances the following:
1. the case above where type: <vendor defined>,Printer appeared is corrected, now if the number of types > 1, and if 1 or more of the items in the array of types is not <vendor defined>, the vendor defined is removed.
2. Because the /sys based type: is actually working better than the lsusb based one, and is much easier to work with, I've altered the logic to replace at the last step the lsusb based type: with the /sys based type: data. This results in a significantly more accurate, and, better, fixable, type: handler, for example, almost all networking devices are vendor defined, but detecting if it's a network device is trivial using the sys based method. And I can extend those hacks over time to hopefully handle more cases of vendor defined, knowing something is a scanner would be nice, for example, though that's not covered in supported types as far as I know. It's quite easy to add integer based class/subclass/protocol matches too now, and there aren't actually all that many that matter.
The way I did this with lsusb was just a hack in the first place, so I don't have much reason to want to preserve what was really just a fast workaround to resolve some oddities with how type was handled by usb, those are easy to work with and not around if I code it myself.
3. Shows all the device types, not just the first one it found, the initial usb logic, which I literally whipped out during pinxi beta dev testing simply to verify that my block feature printer logic was actually working as expected, so I needed to add a few quick features, which turned out to be --slots and --usb (but I knew usb was very weak, it's far better now). For example, on my system, with a dual interface device that has 1 usb connection, it now correctly notes that there is a mouse and keyboard attached, or that it supports those two types.
New features of this are:
1. now shows hub ports, this is a big win, a major improvement, you will be surprised at what you see on your systems, for example, I have what is supposed to be a high end motherboard, but its bus 1 is a usb 2, and extends to the usb 3, allegedly, board headers, which means, I only get usb 2 out of them, and now I know why. that has 14 ports, I believe 6 or 8 for headers, and the rest in the back of the board as plugs.
2. shows now the real bus id path : device ID, this makes it far more useful, and also showed me during testing a big bug with how I was sorting data based only on the bus id/device ids from lsusb, the bug was that leads to assigning devices to the wrong hub at times. Changing sorting to be an alphabetically sorted modified string based on the true bus/port/port etc ids solved this bug, which nobody had noticed, and which was not fixable using the old method, since you'd never have even realized it was wrong.
3. shows usb drivers, 1 or more
If you want to update to confirm these fixes work for -xxx --usb and -xxx --usb --usb-sys that would be appreciated, but so far I believe I've fixed everything I could see here in terms of making both --usb and --usb --usb-sys better overall.
BSD was also enhanced, and now also shows ports, which it never could do before, for those who follow BSDs. But bsd usbdevs data is to put it midly bad and weak, so there's not a huge amount of work to be done there since there is not much data.
This shows the enhanced lsusb based --usb -xxx output, you'll see the less verbose <vendor defined> replaces the old longer value. Where > 1 device types are found, those show. Where lsusb showed vendor defined for network devices, it now shows type: Network
I suspect for a few other device types I can do similar fixes to get the types better, scanner would be as noted nice to get.
This basically is merging the most reliable parts of /sys parsing with the best parts (really only the device vendor/product name) from lsusb, and I could literally do that myself if I was willing to create the db module for vendor / product matches, doing so would knock literally 300 to 500 milliseconds off the execution time, so I'm obviously going to give that some thought. That db wont' be part of inxi though, that would literally more than double its size.
1. the case above where type: <vendor defined>,Printer appeared is corrected, now if the number of types > 1, and if 1 or more of the items in the array of types is not <vendor defined>, the vendor defined is removed.
2. Because the /sys based type: is actually working better than the lsusb based one, and is much easier to work with, I've altered the logic to replace at the last step the lsusb based type: with the /sys based type: data. This results in a significantly more accurate, and, better, fixable, type: handler, for example, almost all networking devices are vendor defined, but detecting if it's a network device is trivial using the sys based method. And I can extend those hacks over time to hopefully handle more cases of vendor defined, knowing something is a scanner would be nice, for example, though that's not covered in supported types as far as I know. It's quite easy to add integer based class/subclass/protocol matches too now, and there aren't actually all that many that matter.
The way I did this with lsusb was just a hack in the first place, so I don't have much reason to want to preserve what was really just a fast workaround to resolve some oddities with how type was handled by usb, those are easy to work with and not around if I code it myself.
3. Shows all the device types, not just the first one it found, the initial usb logic, which I literally whipped out during pinxi beta dev testing simply to verify that my block feature printer logic was actually working as expected, so I needed to add a few quick features, which turned out to be --slots and --usb (but I knew usb was very weak, it's far better now). For example, on my system, with a dual interface device that has 1 usb connection, it now correctly notes that there is a mouse and keyboard attached, or that it supports those two types.
New features of this are:
1. now shows hub ports, this is a big win, a major improvement, you will be surprised at what you see on your systems, for example, I have what is supposed to be a high end motherboard, but its bus 1 is a usb 2, and extends to the usb 3, allegedly, board headers, which means, I only get usb 2 out of them, and now I know why. that has 14 ports, I believe 6 or 8 for headers, and the rest in the back of the board as plugs.
2. shows now the real bus id path : device ID, this makes it far more useful, and also showed me during testing a big bug with how I was sorting data based only on the bus id/device ids from lsusb, the bug was that leads to assigning devices to the wrong hub at times. Changing sorting to be an alphabetically sorted modified string based on the true bus/port/port etc ids solved this bug, which nobody had noticed, and which was not fixable using the old method, since you'd never have even realized it was wrong.
3. shows usb drivers, 1 or more
If you want to update to confirm these fixes work for -xxx --usb and -xxx --usb --usb-sys that would be appreciated, but so far I believe I've fixed everything I could see here in terms of making both --usb and --usb --usb-sys better overall.
BSD was also enhanced, and now also shows ports, which it never could do before, for those who follow BSDs. But bsd usbdevs data is to put it midly bad and weak, so there's not a huge amount of work to be done there since there is not much data.
This shows the enhanced lsusb based --usb -xxx output, you'll see the less verbose <vendor defined> replaces the old longer value. Where > 1 device types are found, those show. Where lsusb showed vendor defined for network devices, it now shows type: Network
I suspect for a few other device types I can do similar fixes to get the types better, scanner would be as noted nice to get.
This basically is merging the most reliable parts of /sys parsing with the best parts (really only the device vendor/product name) from lsusb, and I could literally do that myself if I was willing to create the db module for vendor / product matches, doing so would knock literally 300 to 500 milliseconds off the execution time, so I'm obviously going to give that some thought. That db wont' be part of inxi though, that would literally more than double its size.
Code: Select all
pinxi -xxx --usb
USB: Hub: 1-0:1 usb: 2.0 type: Full speed (or root) hub ports: 14 chip ID: 1d6b:0002
Hub: 1-3:85 usb: 1.1 type: Atmel 4-Port Hub ports: 4 chip ID: 03eb:0902
Device-1: C-Media Audio Adapter (Planet UP-100 Genius G-Talk) driver: cm109,snd-usb-audio usb: 1.1
type: Audio,HID bus ID: 1-3.2:86 chip ID: 0d8c:000e
Device-2: ALi M5621 High-Speed IDE Controller driver: usb-storage usb: 2.0 type: Mass Storage
bus ID: 1-3.4:113 chip ID: 0402:5621
Device-3: Wacom Graphire 2 4x5 driver: usbhid,wacom usb: 1.1 type: Mouse bus ID: 1-4:2
chip ID: 056a:0011
Device-4: Verbatim driver: usb-storage usb: 2.0 type: Mass Storage bus ID: 1-7:11 chip ID: 18a5:3623
Device-5: Tangtop HID Keyboard driver: hid-generic,usbhid usb: 1.1 type: Keyboard,Mouse
bus ID: 1-10:3 chip ID: 0d3d:0001
Device-6: Canon CanoScan LiDE 110 usb: 2.0 type: <vendor specific> bus ID: 1-13:112
chip ID: 04a9:1909
Device-7: Apple Ethernet Adapter [A1277] driver: asix usb: 2.0 type: Network bus ID: 1-14:13
chip ID: 05ac:1402
Hub: 2-0:1 usb: 3.1 type: Full speed (or root) hub ports: 8 chip ID: 1d6b:0003
Hub: 3-0:1 usb: 2.0 type: Full speed (or root) hub ports: 2 chip ID: 1d6b:0002
Hub: 4-0:1 usb: 3.1 type: Full speed (or root) hub ports: 2 chip ID: 1d6b:0003
Hub: 5-0:1 usb: 2.0 type: Full speed (or root) hub ports: 4 chip ID: 1d6b:0002
Hub: 6-0:1 usb: 3.0 type: Full speed (or root) hub ports: 4 chip ID: 1d6b:0003