Show newer

Found also, well, mrmazda found it, obscure hard to trigger bug with multimonitor positioning logic, the positions were being sorted alphanumerically, which then led to a position of say, 800, being considered to be greater than say a position of 1200. Easy fix.

Adding -Gx gpu temp, same function, might as well toss that one in, now -Dx, -Gx, and -Nx all show /sys based temp data if it's available, linux only of course.

Fine tuned some BSD stuff for sensors handling, that's working well too, the DRI driver is working cross platform now as well, no issues, and there's a fallback case where it will try to get it from Xorg.0.log if xdriinfo was not installed. The Xorg log data isn't as reliable, but it is available out of X.

Also, as usual, it's almost impossible to even get Wayland data of this type due to the lack of tools, and any unified reporting suite like X has, which is one big reason X is debuggable and Wayland compositors are generally barely debuggable, with some notable exceptions like the wl-roots stuff (sway's compositor core libraries). Remaining a huge unknown, how to get KDE kwin_wayland or gnome-shell wayland data on cli.

sorry, I mis-typed, xdriinfo shows only Xorg 'Screen' driver, and 'Screen' is not a concept that Wayland uses. I don't know if wayland uses these dri drivers or not, hard to find the docs or info on this, which is the case commonly with xorg and wayland data of this type.

By the way, I'm not positive, but I believe /sys based sensors data would show if you loaded the right module, but without using sensors-detect to find the sensors used, and show the modules to use to drive them, I don't see how most users could figure that out. But I believe if you load the right modulie, the sensors data will appear, but I don't know about the sensors labels etc, without which it's more difficult (or not possible win in voltage types) to match item to proper field, like cpu.

More sensors fixes, sometimes fan speed has a bug in driver, and shows a false, non-existent fan and speed, like 65535, 2^16, which is clearly nonsensical. This type of result is now skipped for ipmi, linux, and sysctl (bsd) sensors data.

Also, new graphics feature, dri driver. This will be for xorg or xwayland only, requires xdriinfo, which shows the active Screen dri driver, which near as I can figure, is a sub driver to the main display driver X shows.

pinxi 3.3.21, next inxi > 3.3.22 rolling right along. Most of the /sys based temp/fan/voltage/watt stuff now working. Note that most of those won't be present if lm-sensors wasn't installed and sensors-detect run and modules loaded, but in theory it will work without lm-sensors usually now. Extended Network -Nx to include temperatures, like -Dx does. I should add that to -G but it's harder, and that's already covered in -s anyway. Bit by bit, this sensors release shaping up nicely.

In development, and working mostly, /sys based system sensors data. Last bits need to be implemented, like being able to exclude sensor types, those are not constructed with the same syntax lm-sensors uses, so it's harder to match them. But the bits of the id strings are based on the same data, lm-sensors just does one more step when creating its sensor id string.

But already should show at least cpu sensor data always, if present in /sys.

Just before tagging the new release, I finally found the real cause of the original bug report, it was, sigh, a typo, as always, but a typo that looked right, in fact, I probably changed it at some point.
ipmitool sensors
instead of correct:
ipmitool sensor

The debugger had it right, only in one place was it wrong, so I added a comment to make sure to note that it's sensor, even though that looks wrong, since it's sensors being queried. ipmi-sensors makes it more confusing, lol. Never ends.

(con'd)... passive consumers to far great a degree. I find this is a disturbing trend, it's like there's this expectation that someone will do everything for them, without them doing anything. I blame it squarely on the smartphone / app generation, that expects everything to be done for them, and takes on a very passive role. Or it could just be the end of the age of real graybeards, hard to say really.

But distressing to me anyway. Still bright spots, Slackware guys still active and involved.

And with that, 3.3.21 is out the door! Ended up with some nice fixes, corner cases handled, and even some new features. I try to get a new feature or two in every release beyond the normal fixes, updates, and bug fixes etc, just to give people a positive reason to update.

Still the ongoing issue of a somewhat distressing lack of actual active participation, which is going to in the end help wind down this project, and then end it, that's in the future, but the current crop of users are....

A nice corner case issue reported, ipmi sensors for some unknown reason returns null, which then exposed some other issues, and subsequent ipmi data samples allowed for more detections of temp/voltage type data.

We don't get enough ipmi testing, and those can only come in general from real server boards.

Note there is a todo which I think I'm going to escalate, which is to take advantage of the relatively 'new' /sys hwmon data to construct sensors data without requiring lm-sensors.

Coming soon to an inxi near you!
* Refactored Packages, more granular, more data, more accurate! Prompted by a real bug for slackware package data.
* SteamOS both Debian and Arch support fine tuned. Slax IDs too where possible.
* Various RAM, GPU, Drive IDs updated.
* Other bugs and glitches

As always, follow along using:

Should be out in a week or less, shooting for Debian/Ubuntu freezes.

It further appears that tctl was not correctly implemented as well, since it appears to always be the same as Tdie, so that's probably 2 regresssions in the k10temp driver for amd zen cpus.

This fix I just squeezed into 3.3.20 since I had not yet 'tagged' the 3.3.20 release.

For those who might wonder, I generally wait a few hours between committing the master/inxi release and tagging it, that gives me time to fix typos I might have missed, or like this, last minute fixes.

In a last last minute fix, squeezed in a fix for the missing AMD Zen cpu temp in -s sensors. Turns out some junior developer decided it would be a 'fix' to the k10temp driver to remove Tdie if Tctl and Tdie values were identical, despite the kernel documentation for the driver clearly stating that tctl is not the same as tdie, and tdie is the real cpu driver.

inxi 3.3.20 goes out the door today, ended up with a nice set of fixes, bugs, and enhancements. All in all a nice update. As usual, the changelog can be found either on github: or more useful, the ongoing pinxi changelog where you can track the realtime changes:
You can also use an HTML version here:

A fairly typical release overall, with no massive refactors etc, but ongoing progress chugs along.

My earliest running vm installs I am pretty sure shipped it, Debian 3.1/Sarge. But with 2.4 kernel, it had very little data, lspci saw a huge jump in utility with 2.6 kernel, in Debian, that was 4/Etch.

Found an odd case where RHEL based distros minimal installs were not shipping with core programs like tar or lspci. Added in error handling and messages to users telling them the programs are not installed which is why they see no data for that item. I had never seen a Linux distro ship without either, so this had not been explicitly handled.

This was discovered while adding RHEL system Base: support for the Distro: item for Rocky, Alma, and CentOS.

The non numeric value was <unknown>, for those who care.

Got a good issue report on github, inxi was spitting out errors when SMT on an smt cpu was disabled, the speed data tool did not expect to ever receive non numeric values, so failed to test to make sure the thing it was receiving started with a number. This failure led to endless divide by non numeric number. Definitely a corner case issue, but totally valid, and it had never shown up in testing I assume because nobody testing had disabled smt on an smt cpu. 3..3.20 will probalby out within week

Show older
Mastodon for Tech Folks is shutting down by the end of 2022. Please migrate your data immediately. This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!