Hardware Detection

[CentralWare]

Hi guys!  I'm in need of a little brain-storming which is going to be a mixture of hardware detection and database creation.

I asked yesterday what a good tool would be to read an attached monitor's possible settings (freq/res) and @Curaga noted ddcprobe being one such possibility.  After digging I've found ample references to the program, but haven't come across an origin (site) thus I grabbed a package (vbe) which contained the sources and split things off so that it compiled just the ddc apps - which worked flawlessly on the Intel card I was using to test DosBox which another user was having issues with.

This got me thinking into a "Standard User" concept...  fire up TC (from CD or similar) for the first time, the typical non-nerd has a good chance of being clueless as to what hardware lies within, so I was thinking that maybe it's time to build a method to scan BIOS, PCI, USB, etc. and generate a list of hardware devices and the likes, then cross-reference this list with possible and likely drivers and support packages from within the TC repo that fit the bill in order for the system to operate at (hopefully) peak performance; especially with X users.

This is theory-to-concept stage, so the goal with this post is to have everyone add to the post their experience and knowledge of 'existing' projects/software already in play (with the least number of dependencies, preferably) which obtain hardware related information.  Parsers will have to be created for each to make them useful, but the first step is to obtain the information.

From what I've read, ddcprobe works xx% of the time, so my thinking is to have others implemented which may be able to help close the gap closer to 100%.  (ie: If the most prominent fails, try the next in line, etc. until we run out of contenders.)

Rules are simple: L/GPL or similar, sources are vital - in the final product this will likely be built into a modular, single package such as hwscan class [contender] and hopefully if all succeeds, we'll end up porting this across the board, which I imagine will come in handy quite a bit when dealing with development boards such as Pi and AW.

Goal: When the system first boots, we want to run a scan for storage devices, network devices, etc. which will get us cleanly onto stage 2.  Once we're ready to load up extensions, we'll want to run a second level scan to look for audio, video, dev/video, printers, etc.  If extensions are already loaded we can kick back and relax.  In the event a device isn't matched up with given fw/sw we add to a text file for missing extensions.  If X is going to load, we flag the user for these to be installed, otherwise we do the same on the CLI side.  When it comes to getting from frugal to operational, this tends to be one of the most problematic areas users post about...  needed extensions to get up and running.

Needed: Any function, software package, script, etc. you can think of which has the ability to display hardware information, especially but not limited to the following categories:

Power: PSUs, batteries, thermal, voltage, etc.
Video: Graphics Card(s) and the functions they support
Monitors: The number of monitors and the features of each
Audio: Focused right now on audio i/o (Realtec) more so than input (ATI-AIW, EZcap)
Storage: Controllers and devices attached to them
Communications: wired/wireless/bluetooth, modems, serial, parallel
Input: KB, Mouse, Touch, Joy, etc.
Printers, Webcams and other accessories.

Please post suggestions in the following format so we can keep this organized:
[CLASS] [SUBCLASS] [NAME] [LINK]   such as:
monitors : multiple : ddcprobe : http://www.somewhere.com/path/to/details

Example uses: (example logic - not actual code)
if [ -n "`hwscan power:battery`" ]; then (bootcode) laptop=1; fi from within tc-config where the output from hwscan would be empty if it doesn't exist or is internally disabled or non-empty (details given by hwscan) if a battery is installed and enabled.

gpu=`hwscan video:primary` (returns ATI Radeon xxx)
(scans for firmware-radeon - not installed)
if [ Xorg ] note requirement for firmware install, otherwise suggest it (one-time)

wifi=`hwscan comm:wifi` (returns null)
Don't bother loading wireless related extensions.
If non-null, suggest (once) the installation of wireless/tools.

Thanks to all who read...  and more so to who assist in the collection!

[core-user]

Do you know about 'inxi'?
https://code.google.com/p/inxi/

[hiro]

I had plans for something similar but then ended up using less and less hardware, also changing hardware less often, so I didn't see much need any more.

I still think some people would like a tce style program like this:

$ recommend-hardware-extensions
1. firmware-iwlwifi.tcz
2. wireless-3.16.6-tinycore64.tcz
3. graphics-3.16.6-tinycore64.tcz
4. thinkpad-acpi-3.16.6-tinycore64.tcz
5. bluetooth-3.16.6-tinycore64.tcz
6. alsa-modules-3.16.6-tinycore64.tcz
Enter selection ( 1 - 6 ) or (q)uit, (n)ext, (p)revious:

To find them the program could compare kernel modules content with your device's pci and usb vendor and product ids.
There might be additional benefit if the program can operate offline in some way or an other so you can prepare a list of dependencies and download everything on an other computer with internet connection with ease.

[CentralWare]

@core-user: inxi is described as a script and notes in the FAQs it's based on the tools of the distro, thus sounds as though it's just doing what I'm planning, but the script itself may prove useful pointing in directions of what commands/apps that are being called to do so.  Many thanks!

@hero: Beyond having the -KERNEL portion of the file names in your recommendation list showing x64 thank you for your input!  I think you might be missing the overall picture of what this project is about, though.  Your recommendation is based on preferences you have as to what packages should preinstall by default.  My intention is to "detect" what we're working with while the machine is booting up, long before extensions are loaded, so we know what extensions to even look for -- thus preventing having to have items such as thinkpad-acpi even on the boot device if it's never been booted ON a thinkpad.  There are other instances where alsa doesn't play nice and OSS is required instead (ie: install alsa-mods and you're likely to cause havoc if something such as QEMU or DosBox needs OSS...  the outcome isn't pretty.)  If we "detect" what kind of machine/hardware we're running on, before we're "running" this can all be sorted out in the background.  If there's no bluetooth device installed in the computer...  loading bluetooth-KERNEL would be a waste of memory...  that sort of thing!

[core-user]

I thought 'inxi' might be the sort of thing you were thinking, if it can be improved on, then this could find a home on most distros.
(Please consider if it can be achieved without hard coding TinyCore specifics.)

[Rich]

Inxi.tcz is in the repositories.

[CentralWare]

@core-user: My (basic) interpretation for TC's philosophy is to be as raw/bare-bone as possible and depending on the intended use, you build from there.  The missing ingredient in my opinion is the knowledge of what "pieces" to choose from which is the center of this project.

Example: Let's say I have a USB stick...  oh...  4GB in size (which I think is the smallest our local retailer carries) and I want to make a portable plug-and-play operating system with a general desktop (Xorg+ice?) on either x86, hybrid (x64/x86) or Pure.  A simple boot menu allows me to boot the kernel I'm after and the associated initfs, but the hardware at boot is unknown.

tc-config runs and sets up the basics, but before we get to bootsync.sh we need to determine what hardware is in the machine of we want Xorg to have a good success rate of booting properly.  (ie: ATI Radeon machines, which we have many different boards which have ATI breeds, drop to CLI without the ATI driver.)

Now many people with this intention just load up every driver possible to cover all the bases.  This is fine for some, but a total waste of resources for any modules which aren't being utilized, and I'm going to guess in some instances there are instabilities with kernel drivers that weren't intended to be launched and left hanging.

There's a great deal of logistics that has to go into this, which a good portion of it has already been plotted on the white-board, but here's a good example:

Machine boots using the existing TC kernel and image (regardless of platform.)  Before we start loading extensions, we poll the system for different hardware classes such as video.  We find out we're running one or more ATI/Radeon cards and set that information aside.  We then find out "Hey, we're going to be launching Xorg, Free, etc. down the road here, so we're going to need hardware drivers otherwise the engine is going to stall, so we go and look to see if we have the ATI driver in our TCZ stock.  Yes?  Let's load it up and let bootsync take over.  No?  Hmm...  the end user is going to be asking "Why didn't this work?" so why not prompt them as to whether or not we should go fetch the driver?"  The concept is to take the environment that's been intended (onboot.lst) and help make sure it's possible to accomplish.

Now, let's say you're performing a frugal HDD install.  You have a basic idea of what the machine's capable of, but there's a good chance some pieces are missing (acpi, bridges, etc.) and sometimes there are going to be packages which can help enhance performance, or in cases such as web cams, printers, modems, etc. there might not be an actual TCZ to depend on, but at least you'll have the necessary details to start hunting with.  (I can't tell you how many modems, SATA cards, etc. I've come across which are just re-brands.)

In the end, no...  I'm not trying to expand on the TC concepts...  just on the portability of CORE and a generalized tool to help simplify a good deal of piecing core together with the necessary elements.

Last example: Year 1999/2000 at NASA (Lewis) Research Center it was my job to help keep things afloat on a support level.  Before Dell took over almost the entire base there were every type of desktop and server machine you could imagine all running different operating systems from Warp4 to Windows to SCO with hardware from every end of the Earth.  "Support" was chaotic as you'd have to carry around an entire library in the back of the van for drivers, etc. for when someone screwed something up.  In that same environment, life would be so much simpler to take a single CD and a single USB stick on site which has a sole purpose of maintaining filesystem support (in case you needed to modify something on local storage without the Os itself in the way) and/or the ability to link into a networked server to fetch drivers, apps, etc.  They had never seen a remote installation in their entire operation (which we introduced when all desktop machines and a good number of servers were Dell-ified as we were expected to connected a KB and monitor one machine at a time, run a complete install of 45ish minutes, then install drivers and apps...  ugh!)  Now, fast forward another decade and change and the same scenario still exists if you're working with end users whether it be corporate or computer repair.  TC could easily be a portable tool for virus removal and maintenance all the way down to the entire desktop environment itself, but to hunt for hardware details is the first hurdle which most people don't want to spend hours researching.

[CentralWare]

UPDATE: Thanks for the tip on inxi!  It's of no use "as-is" for the intended purpose, but does have references to different areas for probing hardware.  (Thus the notation of minimal dependencies - inxi seems to assume a full desktop environment which at boot time is not only unavailable, it's overkill to bog TC down with bash and other items just to get to the basics.)  It's a mile-long script, so it looks like I'll be reading for a while!

The ultimate goal is for utilities such as usb and pci-utils, hddtemp, ddcprobe and the likes - lightweight as much as possible yet informative as to what's inside (and like hddtemp, what's going on with it, if necessary.)  HDDtemp has no value to this specific project concept, but it's nice to have embedded into a remaster since it's so small in size.

[nitram]

Hi centralware...

You sound ambitious! Reading through your post brought Puppy Linux to mind. IMO it is one of the best Linux distributions out there to get hardware detected and running at boot. Dug this up, which may/not help with your brainstorming. Note: I'm not overly techie and not a programmer so sorry if this is not helpful.
http://www.puppylinux.com/technical/module-loading.htm

marty

[CentralWare]

@marty: You never have to be a "techy" to be very valuable!  My wife (for example) is the furthest from being computer savvy, but she's still inspirational and helps to think "outside the box" more times than not.  Thanks for the link!

As for Puppy...  I spent very little time with Puppy when it was just a pup.  This project is focused for boot-time (as opposed to the link's notations of hot-plug after booting...  which is something I'll cover later after this side's perfected as I'll have most of the information I need from this project to build that one.)

Ambitious?  Sometimes.  I've been ripping TC apart for months now trying to find a balance between simplicity and "bare bones" and this (boot hardware detection) was the main area so many users have issues with, not because they're techy (or not) but because "what's inside isn't always visible from the outside" and to me, that causes a great deal of wasted time -- something that flares my ambitions.  A new user to TC coming in from Windows...  ugh.  A new user coming in from a main-stream (Debian, Fedora, etc.) has at least a minimal knowledge, but there's no sense re-learning if it doesn't have to be.  If we can take the hardware hunt out of the picture for many, we could expand this to "unknown" devices (such as printers and such where you're only likely to find drivers from the factory) so eventually a driver "database" could be forged.