Back when I was developing a project called ‘Dohickey’ I had this idea that we could unify a great deal of customer information about hardware and make it so that user facing information was as editable as wikipedia and just as expandable.
I got it to the point where all my hardware had nice names, descriptions, pictures and a set of specifications detailing all the available features. Obviously the project didn’t go anywhere useful for anyone else, mostly due to doing a great deal of development in python and outside of HAL upstream which would have been better placed.
So today I’m going to detail some of the interesting things I had to try and work out or fix while I was doing this project. This is more of a documentation effort so anyone who would like to learn from some of these can try and get some of them into DeviceKit.
Stable Type Identification
Most hardware has the same set of ids used for identifying what a piece of hardware is, vendor id, product id, possibly a revision which usually describes the chipset. For pci you also have sub-vendor id/product id for who ever put the card together.
The first job was to try and stabilise a single field which would become an extendible id, the reasons for this is that multiple devices can be later further identified by their drivers, making more detailed identification. You want to have a field that can make the distinction between a Blackberry Curve and a Blackberry Pearl so your lovely phone management app can display the correct names and picture of the device.
Separation of Device and Hardware
The way most hardware is identified is through the set of device interfaces it presents to the computer’s operating system. Take any of the Intel chipsets (82801H for instance), they all contain the same basic set of chips and being able to identify them all as one single bit of hardware makes things MUCH simpler. Instead of 10 chipset devices, your program can display one chipset with the option to detailing to each separate device.
With pci I managed to do this by figuring out that the first two parts of the pci bus id usually accounted for the physical separation of the hardware, for instance I could be sure that 00:1d.7 and 00:1d.2 were the same pci card or motherboard chipset, but 00:08.0 was something completely different.
Motherboard / Mainboard
Together with the above, I wanted to create a useful was to store information about the motherboard. It’s not a device, it’s a collection of devices and is controlling the rest of the hardware. You can sometimes get useful information from dmidecode but not very often since the thing likes to lie1. I managed to work out what was onboard and what was not using the pcidecode, take the router pci device and work out from there where everything was. Against 356 hardware profiles this system worked quite well.
Once your motherboard has a nice stable id through some mechanism, it doesn’t really matter if the name is initially , because the idea was to be able to attach to that id a real name and other information.
Firewire Isn’t Nice
I spent a lot of time trying to work out how to identify Firewire devices, all the devices I have (including an Apple iSight) did not have any identifiers as per the spec. Either a problem with the kernel driver or a problem with the devices. I ended up stripping and using the name fields as a fall back.
Monitors and Ram
Some bits of hardware lie right on the edge of visibility. If you want to know what kind of ram you have and how much of it and if you have a free slot, you can have a look at dmidecode and it may tell you those things. There’s also a way to interrogate the ram directly for vendor and product details but hardly any of the motherboard chipsets supported it in the linux kernel.
Monitors was similar, you can get some information by looking at the i2c/ddc info, but not all drivers support it. This is one of the things x11 does to work out what resolution your monitor should be. For instance not having the nvidia driver can kill your ability to know what kind of monitor is being used.
1 Check out smolt for how bad the data can get when all you do is rip it directly from dmidecode.