#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.

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.

From a simple issue (#312) on #codeberg #pinxi (next #inxi) finally dumps the legacy -F/--full option names in favor of much more accurate and easier to explain -e/--expanded. Easier because -F hasn't been full output for over 10 years, and -F now actually expands -b/--basic, so noting that -e expands basic is a lot more logical than explaining that --full is not actually full at all, not even close. -F now listed as deprecated to avoid confusion in help/man. Redid -v too, all consistent now.
1/

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.

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 :(

Last testing of #pinxi (next #inxi ) die cluster core counter core rewrite. Pardon the pun. I can't stop myself. Fixes probably both #codeberg wrong core count issues. 307 was RISCV 2 cluster 8 core reporting as 4 core MT. This fix is a true fix, not a hack. Being tested by #slackware forums now. Looks good.

Also grabbed new #pop_os 24.04 #cosmic w/ #iced toolkit alpha iso. Hoping to add cosmic and ice tk support as well.

The longest period without Issues or dev work in years in this release.

I've been gathering data for the Chinese #Loongson #MIPS CPU and GPUs, almost no data on the GPUs for the GPU arch tables (need more product IDs for matches), but found a fairly complete listing of Loongson CPUs on https://en.wikichip.org/wiki/loongson/godson_2/2h then found a collection of sample cpuinfo output files, which was enough to create a rough first CPU arch support in #pinxi (next #inxi). Just debugged last bits, seems to be working. Chinese built #Deepin (#Debian derived) supports #LoongArch.

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.

To release next #inxi now, or not to release and wait for more fixes/issues etc to show up? Always a tough call when there are not a huge amount of fixes, but there are real fixes that impact some people. Right now it's a little light for a new release for my taste, but it's been about 6 weeks, and the bugs/fixes I got were real issues, and should probably move from #pinxi to inxi.

This makes 3.3.35, like 3.3.34, mostly corner case fixes and updates. Which suggests... stability?!

Added initial support in #pinxi (next #inxi) for Loongson GPUs, but I have almost no data, so it won't be very meaningful. More important is to add in support on backend tools/gpu_raw.pl and gpu_ids.pl, which is where the GPU arch data for inxi gets generated.

Support for Loongson CPUs is totally lacking, I have no data, no cpuid data, nothing, though I found a good source for at least some of the features, process nodes, etc, but no way to match to actual CPUs.

And so it goes.

Meanwhile, on the #inxi / #pinxi front, all remains peaceful. Issues reported are resolved.

It's lingering in that odd space where not quite enough updates to warrant a new release, so waiting for more to pop up.

I'm calling the long refactor roughly completed with 3.3.33 a win, I'm not hitting code in general that makes me wince, hides issues, or makes logic hard to understand. This was the goal, so looks like a win.

I get slightly nervous when nothing shows up, but that's old habits.

A another day in the life for #inxi: Issue 303 on @Codeberg noted #mesa version in #OpenGL was failing on one user's output.

With some good sleuthing (not by me, gfxstrand the OP figured it out), turns out that when mesa is built from git, it added an extra string to end of version number string, which then broke the regex.

While technically working now in #pinxi, I will probably make this pattern less picky in case other weird variants crop up.

Another good cb issue. Not missing #github.

Due to an almost overwhelming popular demand (ok ok, a guy asked when I'd release), I grit my teeth, did the last horrifically tedious manual matching tables data updates last night in #pinxi (next #inxi), which always means release is going to be within a day or two.

So this nice collection of corner case fixes will probably go out the door today.

I'm calling it: @Codeberg is working _exactly_ the way I hoped it would. Signal to noise ratio in issues radically higher now than on github.

Fixes in #pinxi, con'd
* A big one in #inxi, only didn't show up I think because most distros ship #Xwayland, #Wayland ID always failed without Xwayland because it depended on $DISPLAY, which refers to #X.org display ID, NOT wayland's. $WAYLAND_DISPLAY added, plus some other fallbacks.

In a sense, this failure was the largest, but I only found it because I installed #sway and deliberately left off Xwayland to see what I'd really need to install to get stuff running.

2/

#inxi update: all in #pinxi now. Nothing very exciting:
* #FreeBSD changes exposed several block device failures, all revolving around not handling /dev/gpt/[device] syntax. Some of these failures are quite obvious, some not as much. Not a big userbase, but it was a good set of bug/issue reports, which is very unusual for the BSDs.
* Adding in some more matching data, gpu vendor IDs, hyprlock, nova #rust #linux #nvidia display driver project.

1/

@Codeberg so it was with a sigh of relief that I switched all my #github repos to Archived read only status, which has the benefit of also turning off all future pull requests, which you can't disable on gh otherwise. Soimetime in the future I'll start repo by repo removing all the code, and just leaving the README.txt as pointer to the codeberg repo.

This already happened for the inxi-perl branch (#pinxi), docs, tarballs.

So for all practical purposes this frees me from gh and its users.

There's going to be a quick new #inxi 3.3.33 release next few days. Currently all running fine in #pinxi. Just need to check man page and docs. New feature -na will show network services/daemons running in advanced network report.

Also a long standing feature request by mrmazda for better error handling of pointless option use.

Added all network services I could find along with documenting each as I added them.

Rushing release due to real bug found and #Ubuntu LTS freeze soon.

And with that #inxi 3.3.32 is released. 3 months in the making. Maybe 4k new or changed lines of code. Cleaner. Easier to maintain and add support for software based features like window managers and desktops. Refactors anywhere pain points existed.

Because I had to draw a line there's already some new features coming in next inxi but I couldn't delay release any longer. So will be interesting to see how this does in the wild. #pinxi got as much testing as practical so fingers crossed.

After what seems an eternity, and the longest changelog on record I believe, the last pre-release steps are now completed for #inxi 3.3.32 (in #pinxi now). General last steps are updating the manually generated matching tables for cpu microarch, gpu product ids, and drive vendors. None of those are actually available data types, and have to be assembled through manual research and various useful datasources, none of which is complete re the data reports, but which do help.

1/

I know this is a long shot: I'm looking for a field name for #pinxi next #inxi Desktop item, which in current inxi is called info:, now repurposed in pinxi to contain random desktop/wm info, like kde framewors+version.

Possible contents are: panels/docks/trays/menus

tools: is used for things like screensaver/lockers.

I've tried a few terms:
comp: [short for components, but could be compositor]
parts: [parts of wm/de, sounds wrong]

Best: 2 characters, like tk: wm:, next best 3-5 characters.

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.

Wow, between #Slackware (udevadm based RAM report debugging/improvements) and #antiX (desktop/window manager tests and bug finds, and improvements), I lucked out on testing for the #pinxi (next #inxi) 3.3.32 release, I knew there were a lot of issues hidden here and there in both cases, and there were, but it took more eyes than mine to find and fix them.

Requests for testers don't always pan out, but these two certainly did. Of course, my choice of both distro forums was no accident...

https://codeberg.org/smxi/pinxi/src/branch/master/pinxi.changelog
The changelog for #pinxi aka next #inxi is getting massive. Already 3-4x longer than average.

But still finding and fixing old and new issues almost daily. The refactors and debugger improvements are being done anywhere I find pain points almost automatically now since one core goal for 3.3.32 is to upgrade code and features I've never had time for in past.

Last known challenge is better handling of complex window manager scenarios for -S Desktop line.
1/

@drcalambre glad you find #inxi useful.

While the new release (currently running in #pinxi aka next inxi) is taking a long time it's achieving the goals of getting code way more robust internally and making it much easier to maintain long term.

The #antiX people have been finding a lot of minor issues with desktop/window manager handling and once those are solid hoping for release soon. But not while known resolvable issues remain.

Changelog is way too long now...

With some useful testing by #antiX users on their forums, maybe tightened the Window Manager / Desktop detections in #pinxi (next #inxi), and also, more imporant long term, added some nice debuggers that make easier to find what is happening in desktop/wm detection process. These themselves were helped by the series of core refactors I have already largely completed. New features enabled by refactor, success!

Going to bash around some weird wm scenarios in a mega wm vm I have, one of several.

More #inxi / #pinxi CPU issues, it looks like #fedora / #rhel have changed a default standard path in /sys for unknown reasons, thus breaking inxi cpu speed collection. This tripped need to do more refactors, this time to the fake cpu data debugger logic, it was not complete.

Also, a new codeberg issue pointed out that in many #Linux I can get basic RAM/RAM array data from udevadm, which appears to dump some dmi data into itself, available to user.

Still tracking down root causes.

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

3/ I've been trying to move #inxi and in particular #pinxi and its docs/data files to open from their largely either undocumented, or non-publically documented status. Same with the data used to emulate various data types. There will always be a subset of data I can never release in public because of user trust issues, but as long as I extract the files from them needed for various features, that's fine.

I have been surprised by how time consuming even this basic and simple process has been.

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.

@RL_Dane @mjgardner @benjaminhollon @sotolf the translation was extremely difficult, but I got MASSIVE help from many distro forums, amazing really. #pinxi was made originally as #perl #inxi, so I could verify new inxi would be feature complete on release, no breaking everything every major upgrade for inxi! 3.0 inxi had far more features lol than bash inxi. I think it took 6 months, it was really hard. And 2 years to fix the translation. New rule: no bash if > 40 lines.