But wait, there's more #inxi cpu arcana!
Intel, for inexplicable reasons, decided to keep their family stuck on 6. Which leads to them running out of the 256 possible model ids (16x16). This leads them to resort to using stepping id to tell various series apart, which is a royal pain to track. I was hoping they'd stop and use 12 when they did 12th gen Alder Lake, but no such luck.
Why? I'm guessing some vendor hardcoded in family 6, or it's just a symptom of intel engineering problems.
4/
(#inxi arcana con'd)
Amd for family does this:
Extended Family : Family is:
Extended family + family.
So for say zen 2, cpuid shows 8F as family. 8 + F = 23, the hex of which is 17h, aka 16 + 7. 23 is what cpuinfo shows. 17h is what inxi uses internally.
Since this makes zero logical sense, I've had to update each family block with these 3 values.
I had zen 5 as Family 20, not 1A, cpuid BF, aka 11 + 15 aka 26 aka 1A.
Got that? Why isn't cpuid simply 1A? Who knows.
3/
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/
Meanwhile on the #inxi front, https://youtu.be/bvHrJzB4-MQ?si=LCrrymqnQc5lVH4c
MooresLawIsDead got leaked specs for AMD Zen 7 cpus. With earlier zen 6 specs, this let me try to get support in before actual data appears. That's rare for cpus and gpus. I also realized I'd used the wrong family id for zen 5 cpus, which means advanced architecture data probably never showed.
This is an easy mistake to make because the way amd does their extended family id is different from how they do their extended model ids.
1/
3 moduri de a utiliza comanda inxi
inxi este un instrument de informații despre sistem în linia de comandă care oferă o mulțime de informații despre calculatorul dvs., fie că este vorba de un laptop, desktop sau server. Comanda inxi este licențiată sub licența GPLv3, iar multe distribuții Linux o includ. Conform depozitului său de pe GitHub: „inxi se străduiește să susțină cea mai largă gamă de sisteme de operare și hardware, de la cele mai simple desktop-uri de cosum, până la cele mai avansate […]https://comunitatealinux.ro/3-moduri-de-a-utiliza-comanda-inxi/
With the quietest of whispers new #inxi 3.3.38 goes out the door. A few fixes, a few enhancements. But maybe the fewest changes in a new release. The main one was a syntax change for vulkan driver that made inxi show N/A always on newer systems.
Plus an actual sensors bug I found by pure chance. And an anonymous #OpenBSD dataset from a vm that exposed some invalid assumptions about values always being present for any given field name.
@dumpsterqueer you'll never miss github. All that happens when you move to @Codeberg is the signal to noise ratio skyrockets and you end up with mostly good issues. That's been my experience anyway.
At first I worried about losing all those eyeballs and followers but it quickly dawned on me their quality on gh was so low they were negatives.
My #inxi project keeps getting starred on gh despite having no commits for 1 yr and saying moved to cb. Not reading was my other peeve about gh users lol.
@arstechnica
Checked for #inxi gpu support. I'm not sure why this story was put out. Seems like every 6 months or so some site/channel discovers the #nvidia driver story. But doesn't research it.
Current status. Maxwell, Pascal, Volta (those 3 next legacy), along with Turing and newer (supported by #linux #kernel foss wrapper) supported in active driver branch (565.xx). The wrapper is not a driver.
Announced with git repo May 2022.
The actual foss driver is Nova. I think.
5/
@arstechnica I have to track nvidia drivers for #inxi and #sgfxi in *nix. What's surprising is how long it's taking to make pre Turing/Ampere drivers legacy. That was supposed to come over a year ago. Legacy does not mean no support. Legacy drivers get several years more support. There's nothing new here.
The cut happens because Turing and newer have moved most of driver into firmware. #Linux kernel will use open source wrapper to talk to firmware.
1/
Fastfetch liefert Systeminformationen
Dieses Werkzeug stellt Systeminformationen im Termin übersichtlich dar. Durch seine Konfigurierbarkeit lässt sich Fastfetch an die eigenen Bedürfnisse anpassen.
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.
Found an obscure #Linux #distro #side that appears to be unique. That is, makes its own toolchain, which is what crazy from #frugalware said defines a base distro. Side uses #pisi package manager, #sysvinit and features #LXDE based #SDE with #pekwm or #openbox window manager.
These odd little distros generally help #inxi find and handle corner cases it had missed. In this case didn't have pisi pm/SDE handled.
Wish I'd noticed side before inxi 3.3.37 went out but this always happens.
And yes, just sent the #inxi 3.3.37 package off to #TinyCore - which is the last step of the process.
So that completes this 4 month release cycle. It would have been less but the monitor scaling feature of course turned into a rabbit hole.
But read the changelog if you are curious. It's long and thorough by design because it's the actual record of what changed, why, and what isn't currently doable. I use it often to find when why and how features are added or removed or changed.
New #inxi 3.3.37 goes out the door. Includes last minute workaround for 32 bit intel gen2 gpu eglinfo hang #mrmazda found. Probably a regression in i915 driver. And the big monitor scaling feature.
Full changelog here:
https://codeberg.org/smxi/inxi/src/branch/master/inxi.changelog
This is the longest between releases in quite a while so nice to get some nifty enhancements and fixes in.
This also introduces the improved option syntax for -b -e, which gets rid of a peeve of -F being impossible to explain.
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.
3 kleine Helfer: CLI-Informationszentrale, IP-Adreßvergabe mit Wäscheklammern und PDFs editieren
https://tube.tchncs.de/videos/watch/4c825607-726c-4b76-bf62-e9eed1939ff6
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.
@jk your fundamental error was obvious in your Initial pist. You believe distros are little corporations competing against each other for supreme dominance.
This is profoundly wrong.
Distro means distribution. Of what? An often massive set of free software projects, #Linux kernel and #LibreOffice being 2 of the larger. #inxi being a smaller.
@jk from doing #inxi distro ID, I use System base/derived. There are not that many system base distros active. A distro that builds its own toolchain can be considered a base. A derived/spin are built from a base. Commonly Ubuntu, Debian, Arch.
Each base has in general a real reason to exist, otherwise the people who make it would have no reason to make it. Distros are mostly made by people, not "they". A few by corps. Different interests, different priorities, different ideas. The bazaar.
