Ongoing #pinxi next #inxi updates. After the #Loongson data and upgrade, I decided to grit my research teeth and dig into #Zhaoxin x86 Via Centaur based CPU. As usual, I had to combine data sources to get the info on each variant. Now pinxi detects Zhaoxin, and gets advanced microarchitecture data for each known model.
Previously this was tossed in with Centaur data, which cut off when zhaoxin split from via (cpuid family 6 > 7). And was wrong too.
It's absurdly hard to find this cpu data.
More battery updates in #pinxi next #inxi
Added more values and updated docs using kernel.org /sys/class/power_supply items.
They have been busy and added many new values.
#codeberg issue #341 prompted me to check what was available. Answer was a lot more! Most consumer systems won't have many of these, like battery temp, but now will show extra if it finds it. Also reordered and restructured fields to allow more clear ordering.
Fun fun.
Turns out 3.3.39 will be the battery upgrade release
Here's a peek into the arcana of #inxi research, which is then added to docs and tools, in #pinxi repo, in this case docs/inxi-cpu.txt and tools/cpu_arch.pl.
This is the data provided by cpuid binary. These are hex values.
https://en.m.wikipedia.org/wiki/CPUID
Normally extended model 3 and model F would give 3F = 3x16 + 15 = 63. And that is how amd does their extended model : model ids.
/proc/cpuinfo shows this as an integer. So far so good.
But then amd does something which makes my head hurt:
(Con'd)
2/
Churning through an unexpectedly complicated series of updates in #pinxi next #inxi
Got the gpu monitor scaling handled which required fixing xrandr and wayland tool parsing and logic. False assumptions led to errors in output.
--force options were glitchy and inconsistently used and documented. Cleaning that up exposed more glitches, like --no-man not working in inxi due to opaque hash names.
It's surprising how fixing docs, help, and man exposes bugs in logic. Still polishing that up.
Just released new #pinxi (next #inxi ) has first draft of working monitor scaling support. The higher physical screen resolutions get, the more scaling is used. #mrmazda had off and on mentioned this as nice to have feature.
Not easy to figure out data sources but seems to work with #xrandr and wayland-info now.
I realized I could do scaling on my #xfce with #x11 which made dev a lot easier. Plus a good data file of #wayland scaled 3 monitor setup.
Updated graphics docs with new res section.
Today was a reminder of how useful documentation is, for help, man page, and standalone docs . #pinxi (next #inxi) had a lot of changes to in particular CPU logic. Editing man and options for those changes forces me to make sure I have it all right.
The thing with docs is, to write them means you have to be able to put into words what the code is doing, where changes are, how new features come to be, aka, UNDERSTAND. The longer I program, the more I realize the value of having to do this.
I'm going to call the #pinxi (next #inxi ) CPU die/cluster/core counter refactor good. Nobody has found a failure case, but then again, no new complex topologies have appeared.
The issue with GPU class IDs being translated to usable data I've given up on, unlike the kernel, FreeDesktop has bad docs as a rule, so unless someone can find clear docs about 302/380 classes that are nonambiguous, re Intel, AMD, etc use, there's no way to give correct info beyond the current ID active. Not static :(
smxi