Show newer

Ongoing slow crawl for CPU arch data, built dates, process nodes, all getting more granular as we chip away at in particular the oldest CPUs, like Intel Family 4, and 5, early AMD. Luckily this has interested a few people, so I'm getting some help on this one. Goal is for info to be more or less right within reason, though docs are rare and difficult to find in any complete form.

Also working on inxi docs, in inxi-perl/docs, expanding, inxi-cpu.txt, inxi-init.txt, big updates.

Also could manifest on a line item that is the last key:value pair on the line, but which was under the given total width for the line. I think 4 issues were covered, 1 a true bug, and 3 long standing weaknesses, 1 I'd been aware of for a long time, and 2 were subtle and only showed up because of new features like --edid full list of supported monitor modes. However, the line output isn't based on which source is printing, it's a black box that takes input and creates output.

Thanks to mrmazda for spotting a subtle layout error that was caused by a long standing weakness in the long 'value' wrapper component of the line printer function. Because of this, I was finely able to fix all the subtle long value split issues which I've been faintly aware of for a long time as weaknesses, but my tests simply never exposed it. Could manifest on any line item where it is not the last key:value pair on the line. This fix is in pinxi now, and will be in inxi 3.3.20 when released.

However, cpu microarch/process/built is getting more granular for AMD, got most of families 5, 6, F, 10, 11, done. Those are slow going however, and I keep getting blocked by because they have well written spider filters blocks, but that's fine, I don't want to do this stuff all the time anyway. K8 was the hardest so far, that's looking pretty good now, fairly granular, and should be reasonably accurate. Some made it into 3.3.19, the rest in pinxi.

Oh, I forgot, also, we had to squeeze out another fast one, 3.3.19, there was another bug found from the core refactor to using array/hash references almost everywhere it makes sense. I'm hoping that was the last real bug with that, when it appears, it's not subtle, inxi fails at that point in the logic with an undefined hash/array ref error. But 3.3.19 rolled in some other nice changes too. Note that the cpu data is still ongoing, but it was never intended to be 100% out of the box. Too hard.

Just a reminder, inxi will never get to the totally meaningless and abstract goal of 1000 github stars if you don't give it a star!!! It's at 896 as of today, but progress has really slowed. Note that this is a totally meaningless achievement, except that having a thousand+ stars (+ because people drop off too now and then) looks cool. Have you starred inxi github today? - Ok, ok, shameless promotion, but a star is a star, LOL...

And we got slimski squeezed in as a new display manager ID type. That's a fork being used by AntiX, also by Rosa now, of SLiM, which appears to be non maintained, and presumably EOL.

inxi 3.3.18 just went out the door, that was a quick bug fix caused by the 3.3.17 refactoring, there was an unhandled undefined scalar that was supposed to contain an array ref. I went in and fixed all those cases, and made everything much more consistent, and got rid of repeated referencing of the same hashes or arrays, now most of them start as a hash/array reference, and are passed around until inxi is done with them. Harder to track, for sure, and can trigger subtle bugs, but better code.

I bit the bullet and also added Intel/AMD cpu build dates, note that is difficult data to collect, and some sites list the introduction dates, and others the actual shipping dates, and production end dates are not always available.

pinxi -Ca
Info: model: AMD Ryzen 5 2600 bits: 64 type: MT MCP arch: Zen+
gen: 2 built: 2018-21 process: GF 12nm family: 0x17 (23) model-id: 8
stepping: 2 microcode: x800820D

pinxi --gpu
Device-1: AMD Cedar [Radeon HD 5000/6000/7350/8350 Series] vendor: XFX Pine
driver: radeon v: kernel alternate: amdgpu arch: TeraScale 2
code: Evergreen process: TSMC 32-40nm built: 2009-15 pcie: ...

And no, vendors other than amd/intel/nvidia for gpu won't be covered, too much work, too few users helped.

inxi 3.3.17 is on the way, that's the filling out of the initial nvidia gpu data in 3.3.16, which itself was hurried out to let people readily identify their nvidia gpu microarchitecture, since the only ones the alpha kernel driver supports are turing and ampere (and newer). 3.3.17 adds amd and intel gpu advanced data, with the -Gx, -Ga, and --gpu arguments. It also adds gpu generation in some cases.

And with that, inxii 3.3.15 is out the door. And yes, TinyCore package has been submitted. This is a new record short interval between tagging the new inxi and submitting the tce package!

3.3.15 ended up with some very nice new features, my favorite actually being a debugger switch, which prints out your entire /sys based pci bus structure:

sudo inxi --slots -a --dbg 48 --dbg 49

-a now prints out pci bus ID children, debuggers print out data structures.

Also, just squeezed in, for inxi --slots -a, will now look for 'children' pci bus ids of the primary pci slot bus id, and show that in a cascading list. This was one of the to-do items of previous releases, and is now working.

Soon to come, inxi 3.3.15, which will fix a major bug in EDID error handling, fatal. Also a nice enhancement, for ram, show voltage if it's found, that is something I'd just missed, probably because most systems didn't have this voltage data in earlier mobos.

And yes, for everyone waiting anxiously to know, inxi 3.3.14 package has been submitted to TinyCore Linux, and should be out, with all the 3.3.13 and 14 fixes, including the various TinyCore features added! Should be in the tce package pool fairly soon. And yes, tested/built on Tinycore 13.0, which is itself fairly hot off the presses. Here's to 21 MiB big operating system isos!

And with that, inxi 3.3.14 is out. That contains many graphics fixes, and a nice set of --slots fixes as well. Note that enough samples of certain impossible to handle monitor X vs kernel port IDs scenarios popped up to make me decide that the range is too large and too random to handle with logic, basically most people's will work well, and a subset will not work well, but that's an issue for X driver developers to take responsibility for, not inxi, sadly.

Added new EDID full data option, --edid to current pinxi, for next inxi. This will show monitor chromacity, and all available modes, as well as any EDID warnings or errors that show up in the parsing. May extend this a bit more, I'll take a look at all the data the edid parser can supply, and see if any is of general use or interest. Or less general, but still of interest. Also preparing to send the full patched version of Parse::EDID to the perl module maintainer once I have it stable.

Gathering data and output samples from 3.3.13 graphics update for inxi, preparing 3.3.14, which will contain many more corner case handlings. Found some very long term nvidia non free driver bugs as well, which now will be sort of handled (nvidia has a tendency to tell the kernel the monitor is disabled when it's not). Still going to be some misses due to the randomized Xorg monitor port ID that drivers are allowed to use, but there's a limit to how far I can work around those oddities.

Just released, fresh from the oven, inxi 3.3.13, with it's huge rewrite/refactor of -G/Graphics, with totally redone internal logic, fully supporting Wayland, though still minus a few required tools for wayland gnome and kde, but if anyone tells me what they are, and how to use them, with samples of the output, those will be added. Note that the changes had built up enough to make it pointless to not release, the only way more upgrades to this new logic can happen is through a lot of user data and samples.

As a bonus, you can now get fairly complete monitor data via ssh or from console, not just from the desktop as had previously been the case. Only a few items, relative positions if > 1 monitor setup, and scaling, if wayland, won't be available in console or ssh.

Show older
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!