A basic, high-level and efficient CLI for discovering hardware information about the current system.
Basic example of this:
─ CPU
└── Intel(R) Core(TM) i5-8400 CPU @ 2.80GHz
├── SSE: SSE4.2
├── SSSE3: Supported
├── Cores: 6 cores
├── Threads: 6 threads
└── Codename: Coffee Lake
─ GPU
├── Intel UHD Graphics 630
│ ├── Device ID: 0x3e92
│ └── Vendor: 0x8086
└── AMD Radeon WhateverGreenDowngradeFixed 390X Hawaii XT
├── Device ID: 0x67b0
└── Vendor: 0x1002
─ Network
└── RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
├── Device ID: 0x8168
└── Vendor: 0x10ec
─ Audio
└── Realtek ALC887
├── Device ID: 0x0887
└── Vendor: 0x10ec
─ Input
├── TUF GAMING K7 (USB)
│ ├── Vendor: 0xb05
│ └── Device ID: 0x18aa
└── USB OPTICAL MOUSE (USB)
├── Vendor: 0x93a
└── Device ID: 0x2521
Firstly, we do not support py2
– the only support provided is for python 3.6
and greater.
So please ensure you have python 3.6
or greater installed.
In order to install OCSysInfo
, you can either download the repository manually via GitHub, and run the main.py
script located inside of src
(do also make sure to install the dependencies as shown below), or, via git:
git clone https://github.com/iabtw/OCSysInfo.git
cd OCSysInfo
# Installing dependencies on Windows/Linux
python3 -m pip install -r requirements.txt
# Installing dependencies on macOS
python3 -m pip install -r requirements-macOS.txt
OCSysInfo takes advantage of each platform's native interaction protocol, except for Linux, which uses a pseudo file system & its distros expose no consistent way of obtaining this information via command/API, in order to extract information about the system's hardware manually.
-
sysctl
-
macOS's
sysctl
command exposes a way for us to obtain information about the CPU with ease. The key features of this, which we need, are:- CPU model
- CPU instruction flags
- Core count
- Thread count
- Maximum supported SSE version
- SSSE3 support
-
-
IOKit
-
Apple's
IOKit
framework allows us to interact with the system's devices (we only seek outIOPCIDevice
andIOHDACodecDevice
, as more information would be overtly useless to us.) -
We filter by using
IOPCIClassMatch
, which can serve as a bit mask match, where the goal is to match the type of device exposed throughclass-code
(i.e. display controllers will generally have a bit that's equal to0x03
, multimedia controllers have a bit that's equal to0x04
, etc.) -
With
IOPCIDevice
, we're looking for PCI devices which have a specific bit mask, and we obtain the model (if exposed), device ID and vendor ID through there. -
With
IOHDACodecDevice
, we simply seek out built-in audio controllers that have an HDA codec present. If nothing, that suffices our criteria, is returned, we simply look into0x04
(bit for PCI multimedia controllers.)
-
-
sysfs
-
Devices enumerated as
drm
(/sys/class/drm
) devices are taken into account with the identity of a GPU; which are looked at ifcardX
directories are found. The directories of these enumerations will generally contain acardX/device/device
andcardX/device/vendor
file. -
Devices enumerated inside of
/sys/class/net
are classified only if they contain a*/device/device
and*/device/vendor
file (so that we can at least have a strong assumption that it'd be a valid network controller.) -
Devices enumerated inside of
/sys/class/sound
are looked at for the audio controllers — generally, they'll have a relatively similar enumerations asdrm
devices — as acardX
format.
-
-
proc
- General CPU information is extracted via
/proc/cpuinfo
- Generally, just running the
cat
command on this file won't expose some vital information such as thread count.
The way we obtain threads from it is by doing some black magic:grep -c processor /proc/cpuinfo
- Generally, just running the
- General CPU information is extracted via
When opening up issues, please list all hardware information relevant, and the issue you're encountering. Show real outputs, and the expected output, etc.
-
@Joshj23 — for extensive help in researching how to discover hardware information on Linux platforms, and providing a big portion of machines used for unit testing.
-
@Flagers — for general guidance, documentation reference, implementation ideas, general support, documentation, help in fixing the source code's faulty logic, and much, much more.
-
@Acidanthera — for the OpenCore bootloader (its community is what drew inspiration for this project.)
-
@Rusty-bits — for inspiring the idea of parsing the PCI IDs from the pci.ids list and layout for implementing a search functionality. Though sadly, this idea never reached production.
-
@Rvstry — for extensive help in research regarding identifying various devices on Linux platforms.
-
@Dids — for providing the URL to the raw content of the PCI IDs list repository. Though sadly, this was never used, as we turned more towards scraping the site
-
@DhinakG — for implementing the
ioreg
abstraction forOCLP
, and allowing us to copy it over for our own purposes. -
@CorpNewt — for implementing the logic of scraping the
pci-ids
repository site, and allowing us to use their CLI format. -
@ScoobyChan — for guidance and helping with the implementation of Linux's flags detection.
-
@Quist — for extensive amounts of unit testing on various hardware, they helped immensely with fool-proofing OCSysInfo as best as possible, alongside Joshj23's immense help with unit testing.
-
@renegadevi — for extensive amounts of help with fixing the source code's faulty logic.
-
@khronokernel — for extensive amounts of help with fixing the source code's faulty logic.