Finalizing the features of the display API upgrade in #pinxi. I know I'm getting closer because I did the first updates to the man page and the help options to reflect the new features. I'd been holding off on that since didn't want to change all the time. Started testing on very old systems, Debian Etch, Lenny, fixed some glitches. Also added in some belated OpenGL data features, which I wasn't really aware of, but stuff changes and it's hard to keep up with everything. #inxi 3.3.30 nears.

The huge Graphic API upgrade is now running in #pinxi largely feature complete. Install or update pinxi to latest version to see it in action: -G, -Gxx, -Gxxx, -Ga all tuned.

I realized that this however makes the output too verbose for -b/--basic mode, so I will need to add a comparable basic data filter like drives and cpu already have for graphics.

Maybe add a test where if wayland, show only EGL, if x11, show only OpenGL report. And if no display, show only the most likely one.

Rapidly unfolding in #pinxi - #vulkan and #EGL API reports for graphics.

About to roll out the full output set for vulkan, then I'll need to go over #OpenGL as well to get the 3 to be as similar as possible for each verbosity level.

You can see the full data with pinxi -Ga --dbg 57, it gets more than it's displaying currently, and as noted, a few features may be added to OpenGL if it makes sense and is practical.

Too much code, sigh, but that is how it is when doing old feature upgrades.

Coming over next week to #pinxi, aka, next #inxi, #EGL, #vulkan display API output.

These will use eglinfo and vulkaninfo as data sources, so should not be that hard to implement.

More reorganizations, this time in the inxi-perl/data directory. That's for #inxi development, mostly fake data files used to emulate system features. Added a lot of files, and updated #pinxi to use the new paths. As usual, all the interesting stuff for #inxi lives in the inxi-perl branch.

Odd how derived distros choose to make themselves identifiable, #Bodhi Linux decided to pop their distro file into /etc/bodhi/info which is similar to /etc/lsb_release, so added a way to use the same logic to get data from either source in #pinxi #inxi next. Not to pick on Redhat's Poettering,, but the design of /etc/os-release totally failed to consider complex cases of derived distros, probably because the redhat ecosystem is so sparse with no derived from derived etc... See xkcd on standards

#inxi 3.3..29 is shaping up into a nice release, though I should try to release soon due to some real bugs that have been corrected.

New feature, in #pinxi now, for -j/--swap, shows zswap data, and for zram devices, shows zram compression information.

Thanks to another #slackware user, found even more bugs with the USB network/bluetooth device type logic, symptom was a bluetooth device falling through and detected as network. That was bad test parentheses pluls regex issues.

Significant USB regex bug in #inxi, found by a #slackware user, who happened to have the perfect hardware to expose all stages of the bug, which had 3 components at least.

This led to certain USB networking devices failing to show in -N report, and could have led to failures in other device types too, but networking had the most issues.

This is corrected in #pinxi, and should be out as inxi 3.3.29 fairly soon.

As is often the case, a well done issue / feature request triggered a #pinxi refactor, for bluetooth this time. Added support for blmgmt tool, fixed some broken LMR/HCI version handlers in hciconfig, and fixed the bluetooth version generator as well.

This makes the report a bit more useful, since I believe btmgmt is generally going to be installed by default. Given hciconfig's deprecated status, adding some default data sources is not a bad idea.

Also added back in as -Ea , status: report.

After a somewhat brutal slog, I got the new #pinxi/#inxi Memory total logic working for user and /sys/devices/system/memory and /proc/iomem. Getting some logic that could handle the variations and the possible over/under reported that /sys source can offer, and the under of /proc/iomem, I finally got something that I think will work in almost all cases, barring a few outliers.

As usual, the LOC added up day after day, but as usual, I go for the "use as many as required, but no more" rule.

\1

Fine tuning #pinxi for next #inxi release, with help from the #slackware people, found some corner cases, so was able to tighten the code to show memory total: more accurately, with better messages for checking and estimate. Using /sys/devices/system/memory when present as user fulfills a long standing wishlist to be able to show at least some RAM data as user, and with superuser, /proc/iomem gives more, but both can be inaccurate, so had to add in protections and checks.

\1

Also added to the #pinxi RAM array line Module count, and in cases where > 1 array exists, per array installed RAM totals.

But still struggling with unclear data from /proc/iomem, in some cases, totals are not adding up as expected, though usually they do. And the hack used to get the estimated total system ram is sure to fail and in fact already did once today with a new set of data.

Luckily it's very easy to inject the data from /proc/iomem samples to debug and try to figure out issues

/2

Early stage testing of no root total installed RAM in #pinxi, not reliable because the source /sys/devices/system/memory does not appear in all kernels for as of yet still unknown reasons. Also, have found one case where a 128 GiB RAM system reports as 130 due to one extra block being present.

Root only method seems to be a touch more reliable, and relies on /proc/iomem, counting up System RAM blocks, then rounding up, but only if total near 2 GiB.

Once I got the #pinxi/#inxi USB upgrades stable, I decided it was time to move that data into the features that support USB devices:
-A audio; -D disks; -E bluetooth; -G graphics; -N network.
This turned out nicely, so now those offer similar output as the already existing PCIe feature for the same devices. Triggered by -xx / -a, to keep them similar to display PCIe options.

Given how little traction the -J/--usb option has gotten, I figured might as well show people the data in other options.

Added to #pinxi/#inxi, some last minute #Slackware focused items:
* added slpkg repo file listing for -r, I'd missed that one.

Also finalizing the #USB handling, trying to pin down corner cases, now the mode: reported is usually going to be right.

Still a question on USB 1,2 4 pin connector lanes, but that may just be too granular (4 pin are not duplex, I don't fully understand how they work vs the newer dedicated transmit/receive channels in a lane, which act more like PCIe lanes.

Still polishing away at #pinxi #USB upgrade. Should cover most cases seen with USB 3 and 4 fairly well. Adding the lanes let me get the correct USB mode as well.

Added in some corner case handlers, ideally the mode will be basically right even if the displayed rev: is not what you expect. My suspicion is that some devices are returning the USB 3.2 as their revision intead of 3.0 or 3.1 as per the USB consortium suggestion.

For rabbit holes, this one wasn't too bad, usb4 support in theory now.

Added lanes for USB >+ 3 to #pinxi -Ja next #inxi:

Hub-2: 2-0:1
info: Super-speed hub
ports: 8
rev: 3.1
speed: 10 Gb/s
lanes: 1
mode: 3.2 gen-2
chip-ID: 1d6b:0003
class-ID: 0900
Device-1: 2-8:5
info: SanDisk Ultra
type: Mass Storage
driver: usb-storage
interfaces: 1
rev: 3.0
speed: 5 Gb/s
lanes: 1
mode: 3.2 gen-1
power: 896mA
chip-ID: 0781:5581
class-ID: 0806
serial: <filter>

Making a stab at support for #usb 3.x/4 modes, that's running now in #pinxi. Confusing stuff, and the usb consortium didn't do anyone any favors with their fairly convoluted way of describing the various modes.

I'm wondering how the kernel is going to show that in /sys usb data, I"m guessing the /version file is going follow earlier, and show 4.00 for all the #USB4 iterations, like it shows 3.00, 3.10, 2.00, ,etc.

Anyway running now in pinxi current, if it survives, will be in next #inxi.

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, so good one to test on.