By skyforbes My understanding is that sensor data is generally exposed through /sys/ files by kernel drivers which communicate with the hardware directly under the hood. Running lm_sensors on my laptop mentions that "thermal management is [often] handled by ACPI rather than the OS" so this also indicates to me that some sensors are interfaced through ACPI. I'm not sure if there are any other sources of sensor data is may or may not be used.
There are two parts to reaching parity with software like HWiNFO on Linux:
Sensor Data Parity
The first is of course to be able to get access to all of the same sensors. Throwing around some ideas, keep in mind I know very little about what I am talking about so please correct me or provide more context:
- If a kernel driver itself has the information but isn't exposing it then we can patch the driver to expose /sys/ files to userspace. This was briefly mentioned here: https://community.frame.work/t/responded-sensors-availability-linux-vs-windows/47416/8. My initial thought would be that there would be a bunch of info for components that are commonly used in enterprise (such as certain CPUs). I suspect this approach is probably more viable for components such as CPUs or GPUs.
- In a lot of cases there may just not be any vendor support or documentation, I suspect this is the problem for a lot of things like fans. In this case we may have to make use of the work HWiNFO has done on Windows. This could be done by reverse engineering how HWiNFO works (either by snooping communication with hardware or looking at decompiled software) but I suspect this would be a tedious and manual process that is just fighting an endless uphill battle, far from a solution that could "just work" like HWiNFO does. I imagine software such as WINE is out of the question since HWiNFO likely calls Windows only drivers that do not exist on Linux or ACPI calls that probably are impossible to get working for some reason.
- Request hardware companies to better support Linux. I think this is unlikely for most cases where there isn't already an expansive effort to support linux by these companies.
- Some kind of communication bus fuzzy search (such as by using i2cdetect). I think lm-sensors does this to an extent but I don't think it does much in most cases and can potentially cause issues.
- In some cases a kernel driver does exist but is obscure and not enabled by default or lacks support by frontend software. I experienced this with my laptop 7535U of which I can use the zenergy (amd_energy fork since I couldn't figure out how to easily install amd_energy) driver to view per core energy usage. I had to install this driver myself and no frontend software that I used seemed to support it.
A comprehensive frontend
While there are a couple frontends for different sensors there is none nearly as comprehensive as HWiNFO on Linux. This is in part due to the aforementioned lack of sensor data but possibly also because the software that I've seen is often targeted at specific types of sensors rather than as a centralized hub for nearly all of them (also see point about zenergy above). Getting the above done seems to be the biggest bottleneck but I'd be willing to write a GUI (with CLI fallback) myself if it comes to it (probably in the iced toolkit).
What can we do as a community to improve the situation?
Is what I said earlier correct?
If so how could I or anybody else get started with say reverse engineering a sensor or creating a patch for a kernel driver. What resources are available to get started?
DISCLAIMER: No, this is not LLM written. I handwrote it in VIM in like 40 minutes then spellchecked it. I also made a post in the Arch Linux subreddit with a different title which I changed in this post because I think it made people think that my post was LLM written.