#pinxi — Public Fediverse posts

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.

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.

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.

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

In #pinxi (next #inxi ) a full refactor of the venerable Battery module. A #Codeberg issue exposed the bad logic of the battery feature, which near as I can tell was roughly translated verbatim from the original bash during the #perl rewrite. I thought I'd redone all those but I missed battery section obviously. The only difference most users will see is fewer or more decimals. Issue was 0.01 Wh capacity and current charge. Which was prematurely trimmed to 0, actually string '0.0', aka true.

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/

Got a good #inxi #codeberg issue report. Graphics #Vulkan API item failed to show driver. Turns out that somewhere between vulkaninfo v. 1.3.255 and 1.3.296 they dropped the device driver summary data block. It was always also in a much larger and longer block but I'd never trusted the block name to be consistent. I still don't but there's no choice.This is fixed in #pinxi but sadly just missed the 3.3.37 release by a few days. Oh well. A #Mint user reported it after seeing driver: N/A always.

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.

Next #inxi is shaping up well, all running in #pinxi now. Came across an ancient distro I'd never heard of, #TDSDE, which apparently preceded Gentoo by a few months. Poor docs, unreliable source builds, but got everything inxi cares about working, and found some weak spots. These corner case distros often expose weak assumptions.

Also locked down #rpm packages, #urpm #eopkg #pisi repo reports, which were not great, or not working.

Took a while to get enough fixes to warrant a new release.

Next #inxi is shaping up well, all running in #pinxi now. Came across an ancient distro I'd never heard of, #TDSDE, which apparently preceded Gentoo by a few months. Poor docs, unreliable source builds, but got everything inxi cares about working, and found some weak spots. These corner case distros often expose weak assumptions.

Also locked down #rpm packages, #urpm #eopkg #pisi repo reports, which were not great, or not working.

Took a while to get enough fixes to warrant a new release.

Next #inxi is shaping up well, all running in #pinxi now. Came across an ancient distro I'd never heard of, #TDSDE, which apparently preceded Gentoo by a few months. Poor docs, unreliable source builds, but got everything inxi cares about working, and found some weak spots. These corner case distros often expose weak assumptions.

Also locked down #rpm packages, #urpm #eopkg #pisi repo reports, which were not great, or not working.

Took a while to get enough fixes to warrant a new release.

Found issues in #inxi repo report for some software sorced repo lists.: #mageia's #urpmq, #pisi, #solus #eopkg. These all are roughly similar and all had same report glitch of showing one repo data source per output line instead of source then all repos. The output was also weird. Corrected in #pinxi. Thanks #mrmazda for noticing.

Then noticed the #rpm package count failed for mageia. Turns out they are using different version of rpm, missing some options so no results. Will add workaround.

The slow motion tidal wave of core #pinxi (next #inxi ) refactors continues unabated. Thanks to ongoing testers at #antiX and particularly to #mrmazda who has been helping find failures by the best way possible: running and doing things I don't. Just found bug that made fallback startx/xinit detections always fail. That was the new logic. Also found more failures caused by fixes to version tests, they were relying on bug behavior to work. Always a risk when fixing bugs.

All going well.

This slow rolling #inxi / #pinxi refactor is hitting little things left and right, first the redo of the ps data handler, which morphed into the program version refactor, which then morphed into the just completed Display Manager refactor, which expanded to add the previously incorrectly ID'ed login/seat managers, like #seatd, #greetd, #elogind. Now inxi shows dm if detected dm, but if not, shows login: [manager] item instead. This covers situations like sway, labwc etc, started by seatd.

\1

Adding #inxi / #pinxi support for #slitaz, and it's package manager / repos #tazpkg. This also exposed a significant bug with init detections on #busybox based distros, which made it hang when detecting the init system due to way too lose tests. Now correctly gets init as BusyBox and version too. Also added in corrected slitaz distro ID.

this is turning into yet another really big inxi release, but waiting is proving to be productive in terms of features.

Finished TinyX detections as well.

Also verified distro ID for #inxi / #pinxi newer releases of #slax #debian / #slackware releases.

I don't do these upgrades that often, the original idea was that distros would actually care and spend the time to help, but that plan never materialized on the earthly plane, so it basically just happens when I get bored and feel like doing it.

That issue stands alone and lonely, year after year.

Also some huge documentation dumps for Audio from #mrmazda gave a lot of systems and data.

Finding even more in #pinxi / #inxi working in old distros in vm, #Debian #sarge, failed to handle x log file name XFree86.0.log, no idea how that escaped me, and also modules were _drv.o, not .so, back then with 2.4 kernel, so those tests failed too. Have versions for the sound servers that support version, so the list of fixes / enhancements shaping up nicely for the completed version, 3.3.27, did 26 as a quick out the door get bugs fixed release, but 27 will be the final one for this series.

Filling in the the #inxi / #pinxi sound server/api stuff. Added #aRts, #Esound/#Enlightenment Sound Daemon/esd, filled out #NAS (Network Audio System), added active/inactive detection for #ALSA.

I wanted to get the initial fixes for the standard current sound servers out as bug fixes, which was 3.3.26, and then I figured I'd fill in the rest.

Testing on old #Debian vms, #etch, #sarge, #lenny, all working fine as of today. Sarge shipped with aRts installed, with OSS+2.4 kernel, good test case..

With with a faint pop, just missed Chinese New Year release, #acxi 3.6.00 goes out the door. Now to move on to do other things.

For those watching, #pinxi is moving very slowly towards next #inxi, but nothing pressing really calls for a release yet, but features/enhancements are slowly building up. Better intel/amd gpu IDs for example.

I think this is a first, since the new #acxi --config option is easy to implement, and useful, I extended it to #pinxi/#inxi. This will be in next inxi, and is in present pinxi now.

Usually acxi lags somewhat behind inxi in terms of code and logic, but due to recent heavy spate of work on acxi, the pattern is reversed for the time being.

I don't know why it never struck me to just let users easily find what config file is active, and what configs it has, but there you have it.