Infer SDCard Reader(s)

[sebma]

Hi, Can you have inxi infer SDCard Reader(s) :

PC1 $ lspci | egrep -i "(sd|card).reader"
06:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5229 PCI Express Card Reader (rev 01)
PCb $ lsusb | egrep -i "(sd|card).reader"
Bus 001 Device 005: ID 05e3:0727 Genesys Logic, Inc. microSD Reader/Writer

?

[smxi]

you're confusing an OEM string that is totally random with actual data. That's very easy to do if you aren't actually familiar with what real data vs random strings actually is in system data.

I've seen many variants of sd card, or really, any type of card, readers, all use different syntaxes and variations.

For example, if you ignore the random OEM assigned string value 'Card Reader|microSD Reader/Writer', you'll note a few actually interesting things in what is actually real data:

Unassigned class [ff00]: that's the real data, the actual pci device type, and when it's unassigned class ff00 that means, it can be literally anything. Similar for usb devices, again, it can be quite literally anything, though in your second example you didn't use the correct command, but I'm quite familiar with pci and usb bus type ids, which is where real ids come from.

inxi doesn't have a primary category for pci readers, and it will take a good guess with -Ja at what the usb device type is, there are actual lists and tables of usb and pci device types that inxi uses internally, coupled with a few string based fallbacks. Since there is no pci type card reader in inxi, that's not currently supported, it's not a disk, it's not a partition, so that would be an entirely new type, so we can largely forget that one unless I feel the urge to add a primary new line type, but it would have to cover far more than just various card readers.

It could in theory be crammed into -d, sort of, since -d already contains floppy and cd / dvd type readers, with or without media inserted.

But that would not probably happen unless I could get a better class/subclass pci id for card readers, I'm not fond of relying on highly unreliable string parsing for getting a primary data type.

Same for usb. Basically if you run -Ja and you don't see the usb card reader listed as a type card reader, that means it's not a type, remembering you have to totally ignore the string of the model info/name, which is just a string which has no data value.

Users often get confused by this, they think that just because they see some words that means that the device actually is known by linux or pci or usb as that type. I know the usb type list is quite complete, the pci list may only cover primary types, I forget, i'd have to check it, but in your case, it's an unknown generic type, which has no data value.

So no, not really. At best it would ba hack relying on string parsing and hoping the model name string contains the card reader string in some recognizable format, which is never a reliable guess, just makes it sometimes see it, sometimes not.

Needs class and sub class hex number ids to be reliable, with that and string parsing, the ids usually are not bad, but I've seen card readers for ages, many years, and never seen any real data to ID them, though I have and do notice them when working on other types of data, particularly usb devices.

So the actual question here is not if I can make inxi infer it, it's if you can show a way to positively ID them with high accuracy. I've looked at a lot of pci and usb device ids, and can't recall that being a valid option, though of course, fallback tests can be made for cases where it's an unknown device type or id, but that gets messy, and it's not like real data, it's kind of pretend stuff.

So I'd say, show me how to do it reliably, for both types, if no reliable way to do it, not a huge point in adding that type. Basically if you think of it, inxi already shows the product name, and if that name contains the string card reader, inxi could parse that, and, somewhat tediously, deduce it's a card reader, but that adds zero actual data or value, since the string already said it was a card reader, and unless the inxi user is totally ignoring the output, that data is already in the string for usb types.

There's so many variants, any time I have to dive into string parsing for ids, that signs me, not someone else, up for months of finding variants, which is tedious, that already is done for disk vendors, that's a manual lookup table based on string parsing of product name, and ram vendors, same, but also with product vendor id checks. Tedious, nobody ever helps me with these, so I don't really relish the thought of adding more random data parsers to inxi and volunteering myself to then do all that work for the rest of inxi's life.

Not that I don't agree that it would be nice if there were reliable ways to id without resorting to random vendor string parsing that a device is of type card reader, that wouldn't be a horrible thing to show, but again, right now, it already shows it for usb, just not for pci.

stuff like this takes a lot of research, a lot of user datasets to see string variations, and to see if there are any product class and sub class ids for usb and pci that tend to be assigned to card readers, there are for example storage classes, but as you see in your example, those aren't consistent or reliable, usually when a pci device is given an unassigned class value, it means it's a type that is not covered by the primary pci class/sub class specifications, which means it's not something that can be reliably detected.

I'll leave this up as a not invalid feature request, but one that I don't personally feel like doing at this point since I don't like doing things that rely on random product name string parsing, that's very low grade, low quality data, just one step above pure garbage, which isn't really what I look for when it comes to inxi features.

[smxi]

While you're doing this research, what you want to look at is the output of lspci -nnv

lsusb is more of a problem because inxi only uses lsusb to get the raw product names and their bus ids, and uses /sys data for everything else re usb data, using the bus ids to match the /sys item with the lsusb item, so that's much harder to actually find the data for for a regular user who doesn' t know how to use inxi data debugger collection tools.

bsd stuff is even harder, since bsds do not have /sys data, which severely limits the data inxi can grab from those types of systems.

Note I have a lot of user data sets, so when I'm curious about the variations, I look at stuff from over the past 10 or so years to see what the variations really were, and to see if I can find patterns that might lead to something better than pure random junk data parsing, otherwise there's very little point in doing the stuff since it really wouldn't add much value, that is, if I suggest in help or man that inxi -d can also show card readers, there's an implication that inxi shows card readers, not that inxi is doing parsing of random strings and hoping they contain the key words card+reader. That's unlikely to give better than maybe 60% or so success, if that.

Unknown usb devices, just fyi, won't even show that product string, that's something that comes from the lsusb internal database, NOT the kernel, it's a matching table of some type that the lsusb guys generate, so when the device is not known, you'll see no data for that string, just the class and device/product raw ids. That's why inxi can id say, a pci graphic card with no product string, it uses the class ID to id it as a type graphics, and is happy with that, since that's totally a reliable id even without any product oem string data at all.

The most promising area is in /sys, to find if there is an internal value that generally points to card readers, that's more likely than usb or pci data, /sys is expanding and has some interesting data types now, growing by the year. But I don't feel like reading through /sys debuggers from systems with card readers to see if I can find those patterns, that's very time consuming, but that's the actual real way to do this feature, given random string parsing is not real data, nor is it reliable or really worth doing except as a fallback to a more reliable method.

Were such a feature to be added, it would be a -d item I believe, since that's the closest type, that's readers already that may contain or not contain block devices. -D is actual block devices, minus the readers. I'm not positive, this is another area of research, but I believe readers with an inserted device show as the device, not the reader, and without, show as the reader, but that's the kind of variation I'm talking about. Few people actually think through what the actual range of possible values and outcomes are, and even fewer actually are willing to test and help find them, actively, ongoing, over time.

Tip of the hat to mrmazda, who is one of those few people, with graphics and distro id features.

[sebma]

@smxi Wouah ! It is much more complicated than I thought :smile:

the output of lspci -nnv

$ lspci -nnv -s $(lspci | awk 'BEGIN{IGNORECASE=1}/(sd|card).reader/{print$1}')
06:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5229 PCI Express Card Reader [10ec:5229] (rev 01)
	Subsystem: Toshiba Corporation RTS5229 PCI Express Card Reader [1179:ff1e]
	Flags: bus master, fast devsel, latency 0, IRQ 33
	Memory at f2a00000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>
	Kernel driver in use: rtsx_pci
	Kernel modules: rtsx_pci

in your second example you didn't use the correct command

In the second example, what command can I use ?

[smxi]

As I indicated, in the second example it's too complicated to explain easily. You can see some of it with lsusb -v but that doesn't map exactly to /sys usb data, but it is made mostly from the same data. That's very long and verbose output for the primary device however, but I'm already fairly sure there are no usb class/subclass ids for card readers, though I'd have to check if they come under the USB disk type. That part I can't remember, but I do know that the drive vendor logic exposes many usb card readers, but I also know that many of those do not contain the string card reader as far as I can remember, the syntax varies widely.

It's always more complicated than regular users think, the entire trick of inxi is to make this huge web of complexity appear to be fairly standardized and consistent despite the fact that it rarely is. Chaos is the rule, not the exception.

You'll note in your expanded pci example that there is zero real data that could be used to determine something is a pci card reader. That comes from, I believe, mainly the fact that the pci class and subclass IDs were created before card readers were a thing.

Basically if there were no class id / sub class id based way to generally detect a device type, relying on random vendor string parsing to deduce that isn't very reliable, since those strings can be empty, can contain words other than the target words, or other variants.

If there are class/sub class ids that sometimes are reliable, then the combination of random key word parsing and the class/subclass id tests can result in decent results.

In other words, it needs more than random string parsing to be a reliable feature. For USB, the strings already show, so that isn't anything added in value to the data. In pci, unless detected as cardreader type, they would not show, which would mean a significant percentage of pci card readers would not show, thus leading to valid bug reports that someone's card reader device didn't show, since there's no real data to detect it, which is not a desirable feature in my opinion.

Note that with drive vendors, in a sense, if no detection is made from the string parsing, it's not a huge deal, all that happens is no vendor: item appears, and the product name/string just shows as it normally would, the thing is known as a fundamental type of 'drive' no matter if the vendor detection works or not.

The case of a primary type of device, card readers, is clearly different since that is a primary type without a core primary way to detect it, with some fallback tests added to boost reliability.

There's a reason inxi has to be as long and complicated as it is, if things were clear simple and obvious, inxi would only need to be a fraction of its current length and complexity.

It's fairly easy to type a few words saying it would be nice for x or y to be a feature, without realizing what that actually entails. New features are generally very difficult to implement, and require fairly long term updates to get reasonably stable, far far far more than most users realize.

I'd have to for instance also check dmidecode and see if it has a device type for card reader, that's one I don't know offhand, sometimes by combining or offering as a fallback dmidecode data a feature can be made more reliable, but it takes work.