Tiny Core Base > TCB Talk

Hardware Detection

(1/2) > >>

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.)

Navigation

[0] Message Index

[#] Next page