Looking good here:

FYI did a run on the older machines with -40 last night and haven't noticed any issues. Not seeing any issues with -41 on my "newer" boxes either.

I have looked at this output:
The data in the "parameters" category appears to be a copy of the contents of file "/proc/cmdline". In this particular instance, when the data is appended to "<space><space>parameters:<space>" the result is significantly longer than 80 characters. I expect a fair number of other such instances exist.

Does Perl have output control characters which have an effect similar to what these four "\r\n\t\t" would do in C/C++? If so, when pinxi gets "y1" on the command line, would it be reasonably possible for "pinxi" to process long lines, either on input or output, to: read over about 40 characters and then find the next space, and insert the Perl equivalent to "\r\n\t\t"?

Personally, I much preferred the double-space indenting to the single-space indenting.

I was looking at this output:
In the section "Chassis", are the two single quotes intended, or was that a character string which was supposed to be converted into a number, or some such thing?

Hi "h2-1",

I have read your reasoning about the 64-bit, 32-bit, &c. reported by "pinxi" in this posting:

I think your approach is eminently reasonable. It appears to me the expanded definition of "bits" in the snippet below, is "bits of the mode in which the processor is currently running" (as opposed to the "maximum number of bits of which the processor is capable"). :-)

More excellent points and observations.

baumei, re the -y1, the basic intention of that is to be similar to xml or json output in that each key has one value on one line. You can see this with pinxi -fy1 which will show the cpu flags etc. You are right that the parameters can and often does extend far beyond 1 line of output, at which point it wraps in normal non -y1 output mode.

This is the time to have preferences re the indenting spacing, I have just been experimenting with that, and actually did notice yesterday that 1 space might be a bit too tight, so I'll bump that back up to two. I'm glad you got a chance to use both so a preference would be meaningful. The thing I kind of noticed yesterday in testing was that in the long line mode, the single space indent on wrapped 'lines' (a pinxi/inxi 'line' being full output item for that line, a line can and often is wrapped to 2 or more rows, rows being the visual thing you see, but lines being the logical thing, which you can see if you disable output width control with -y -1.

It's better sometimes to push something to the minimum to see if that's ok, re indentation, then to pull back, than to not test it, so I'm glad you were able to test and state a concrete preference, I'm flexible on these new things.

However, with this all said, I had noticed in total passing during this testing, and over the past months, that the shift + pageup/down in console to scroll back on the output was broken, and luckily I mentioned this to someone else, and he luckily found that was the case, and then found out why:
https://lwn.net/ml/linux-kernel/CAHk...ail.gmail.com/
This very understandable decision on the part of Linus (which resonates heavily with me after having to try to preserve the similar set of hacks and workarounds and hard to explain custom instance treatments that previous inxi CPU logic used, and which pinxi unfortunately has to preserve in part to maintain legacy behavior for systems without the richer data source pinxi now defaults to using) is however deeply impactful to pinxi out of X/wayland, in console mode.

I'd idly noticed out of x scrollback in console wasn't working, but hadn't thought about it, I thought it was just a glitch in my distro or something, but for it not to be working on an absolute level on all new kernels means that a core feature of pinxi output is broken, that's scrolling off screen in console and pgup'ing to see what scrolled away.

Because of this I'm going to add a new output control feature, -Y, which will implement a 'less' like behavior, that is, print only 1 screen height at a time, then wait for 'ok' input hit enter, or exit. If piping to 'less' or 'more' is used, the color coding is switched off, which makes output harder to read. -Y will have several options, if used alone, it will default to 1 screen height, if used with a positive integer, it will print that many lines at once, and if to -1, it will print 1 block of data at once, and I think -2 will override user set configuration for MAX_LINES configuration value and revert to default print all at once.

I'm very glad I learned about this fundamental change in the kernel before doing 3.3.10, otherwise it would be very tricky to handle console output scrolling off the screen.

By the way, I was struck by how nice Linus was being in there, you can tell he wants the functionality back, and he is hoping someone will do it, but he just wants the bad code out for now, which is also understandable. My guess is that framebuffer scroll back functionality is returned within a year, if it's not already being worked on now.

2 members found this post helpful.

3.3.09-42

Restores 2 space indent for level 1 and 2 indents, definitely gets rid of that thing where it looks like level 2 indent might be an output error or glitch. Odd how our brains respond to such small visual cues.

Adds new output control option -Y/--less/--height (goes along with -y, --width) Not bad for what is essentially an emergency fix for console output scrollback being removed from kernel.

Accepts -2 to xxx. -2 overrides configuration item MAX_LINES, -1 shows one primary data block at a time, 0 or -Y alone shows one terminal screen at a time, and > 0 shows the requested numbers of lines at a time. I tried it without the printed hit enter to continue line, but enter creates an empty line anyway, which looked odd, plus the line explains what to do. I decided to not make the mistake I made with -y, which was not creating a sane default for no values given. So the normal out of x/console mode use would be like:

Note that Perl allows a valid argument for an option that accepts arguments to be provided without a space between the option and the argument, which is something I became aware of relatively recently.

This seems ok to me, and actually resolves a long standing annoyance of using help menu in console mode.

As someone immediately discovered testing this, while -Y used without -y1 works as intended, any lines in -y1 that the terminal itself wraps due to them being long will of course take up some of the lines available, which then cuts off the top x lines. This issue isn't really resolvable, I tested a fix or two, but there's actually no way for inxi to know how many lines a printed row will take up in the terminal at this point of the output, so I think a simple note to users to avoid using -Yy1 is best. Better to set heights explicitly, like -Y20y1 for example.

With this said, most systems with reasonably wide consoles will look fine with -y1, I've tested it on many and most look fine, it's only very long kernel parameters and kernel flags that will trigger the unwanted linewraps in the terminal. Solution there is to just use -y instead of -y1 and call it good.

I did add a truncation of the repo url/info if the repo line is wider than the terminal width which works fine, just adds [...] at the end to let you know it was sliced off, that's to avoid wrapping lines by terminal in -Y mode with no -y1 mostly, but it also works fine for -y1.

2 members found this post helpful.

Hi "h2-1",

Would having pinxi offload a significant portion of the output-display duty to "less", both: (a) work well for the user, and (b) reduce the work load for the author of pinxi?

As I understand it the man-pages use "less" for displaying the data, and this works well.

I was thinking the same thing, less also fixes the -y1Y paging issue and doesn't pause inxi's data aquisition as -Y seems to do. No need to add the kitchen sink. <insert systemd joke here>

I found adding -c2 to pinxi and using less -R will preserve the default colour choice.

No, -Y is working reasonably well now, the repo truncation would literally only happen using -Y on a narrow monitor with indentation + line number + repo item length > width of terminal columns, that one completely ignores any max-width set, and only pays attention to the terminal width. In other words, this is one that will activate really only if you try to make it do so, or routinely use 80 column wide terminals in console mode, not gui that is, not ssh via terminal in gui, with machines that have super long repo entries.

Note that using -Y is not required or recommended, it's just something you can do if you feel like it. I've been testing it on various remote and local systems and it's reasonably nice I think, it does pretty much what I want it to do and is just one more typed letter, which is easy to remember.

In general I don't even recommend using -y1 for long output anyway because it takes forever to read it all, that's more for single complicated features, and in almost all cases, it will work fine.

Trying to internally use 'less' somehow would be somewhat of a nightmare, and would certainly be far harder with probably worse results I'd guess, but that's not one I'm going to try, the output generator is a sort of black box which is hard to work on, it took me a few tries to get these last changes working, and usually the goal is to never pay attention at all to the output generator, just send it stuff, and it spits it out the way it is supposed to.

This is one of those "it's almost done now what else can I think of" things, it was more or less because I just learned that the vanishing scroll up feature in the kernel was gone and for being in console I thought a native way to just pause output would be useful without having to do or remember anything else.

As noted, piping removes colors but then I would have to remember what color scheme it's using to add them back in with -c xx, I actually use the color schemes to let me know if it's running as root or regular user, and in and out of console, those can be somewhat useful (there's I think 6 or 8 possible color schemes, user/root in/out of x, in/out of console irc, I think there's 16 possible between 1 user and 1 root), but I could never actually remember what each type was using. [funny note: to remind myself now of the -c color options, I did: pinxi -hY, saw what I wanted, and exited, so I think at least I am going to like -Y].

Note that -Y works for essentially almost everything except the -y1 case for 2 fields, when there is a long parameters: line, or a cpu full flags line, or when there are very long repo lines, but I don't personally consider repo lines that critical in terms of information. I may remove the truncation, I'll probably sleep on it, it's not a big deal much either way, just nicer to be consistent for -Y on all the lines. Much easier to truncate than to add a linewrapper tool for the special output type that is repo file listings, that's a unique output type.

Basically the sequence went something like this:

• Get CPU done, which has a lot more data.
• Fix a small horde of other glitches and subtle errors not related to CPU that popped up during this process.
• Change default widths to make for better online posting readability. -y just never registered with most forum / issue posters, and I've seen one too many horribly wrapped linux kernel issue report with inxi to want to subject support people or bug handlers to that output. So the default width change, which also changed the default where inxi trips to using line starter on own line with 2 space indentation instead of 11, ended up making for more average output lines.
• This would have been fine in and out of X (though for out, I changed it to be 100, not 80, default width, down from I think 115, to avoid creating too many lines, but kept the wrapping of line starters if under 110 columns).
• And this would have been fine until I learned that something I'd noticed off an on the last few months, the change in the console frame buffer scroll back behavior, the change being that has been removed from the kernel, meant that what I would normally and have always done, scroll back up in console, was now not possible.
• Note that it might be nice to get second level indentation working since there's a fair number of lines and it's always been sort of hard to see what lines got wrapped due to width constraints and which are new lines.
• Since to get the second level indentation already had required cleaning up and a slight redo of the main output generator logic, I realized that it might be possible to add -Y with its variants, quite easily. It was very easy to add, required very little code. It's correct that data processing is halted until you let it finish the main block printing (inxi generates its data in advance, usually but not always when the next block starts to build, sometimes it happens a long time before, when it's shared data with another earlier block, that's to avoid a long delay in seeing the first output line, since the first line is really easy and fast to generate), something appears quite soon after you start inxi.
• Someone promptly found a corner case with -Y using -y1, which made the top scroll up off the screen, but only with -Yy1, and only because of 3 things, -SaYy1, -rYyi, and -fYy1. We bounced around some ideas, I tried a few things, they did not work easily and required too much hacking of code in too many places, so he suggested truncating the output, which I did try, but gave up on because it was not elegant or nice, but used that block to truncate the thing that matters least probably in out of X inxi output, -rY. Obviously, if it actually matters to a user, all they have to do is run -r instead of -rY
• And with that, I thought to myself, ok, that's enough, this thing does it all now, lol.
• But I should mention that it's been a long standing slight pet peeve that if I'm out of X and want to check the -h menu I have to remember to use less (or more, then try to remember which is which, and which the system actually has installed), which I don't particularly love in terms of its functionality (though scrolling up and down inside it is nice), so I thought it would be nice to just build in that feature too, since the output generator already does all kinds of length math to generate its lines, the only actual thing that took time was the -Yy1 issue when it was raised.

To me the -Y is purely in the area of, oh, that's nice, ok, easy to remember, just add an upper case Y and you're good, if you want that, usually I ssh into a system that is remote and being accessed in console mode, but I do test a fair amount in my console, out of x, to make sure several behaviors for out of x are working correctly, but with forcing wraps of linestarters to create better public posted output of inxi (that's for support people reading it, not for the users copy/pasting it in), suddenly the issue of the length of the output became more relevant.

Last tail of bugs and glitches...
To me when I start focusing on more aesthetic/usability issues, that means it's basically done, it's just cleaning up stuff I'd been staring at for weeks but not wanting to focus on because there were harder problems to work on, so these are the last little streamers of things left.

I still found 1 more today when testing -Y, there was an actual always existing output generator failure to wrap long lines in one specific circumstance, because of the other glitch, I'd left parameters on its own line, it wasn't supposed to be, it's part of the kernel line, and that became obvious when I was testing the second level indentation feature, suddenly that error became obvious when it had been hidden before. Once I fixed that error, the second output generator error suddenly became visible, in theory it could happen for any key: value pair, but in practice, it only happened with the parameters: item, so it had remained hidden ever since inxi 2.9->3.0 was done.

All in all a lot of real issues were and kept being found and corrected, quite a few from the original refactor to Perl a few years back, and the CPU stuff was in great part actually bad logic from before /sys had this rich type of data consistently, and before inxi was done in Perl which allowed complicated stuff to work.

The non-optimizable CPU frequency issue
The bright side is, somehow, despite adding a ton of logic to cpu, it still tends to run around the same time, roughly, as inxi -Ca did.

I did discover one thing however, inxi had the same issue, but I'd never been aware of it since I had not really paid much attention to optimizing that feature since the logic wasn't very good anyway to put it mildly, but when I did pay attention, I learned that 1 single read query to /sys/devices/system/cpu/cpu0/freq takes between 10 and 20 ms on modern hardware. This is a high end SuperMicro Xeon server.

Ryzen seem to take a bit under 10 ms per thread for the speeds. So when a system has say, 64 threads, and is AMD, just getting those speeds takes about 600 ms, or .6 seconds, or a big chunk of inxi's total execution time. There's another 300 ms sleep delay to let the cpu 'spin down' right before these speeds are grabbed, that can be turned off with --sleep 0. So that is quite a bit of the total time it takes pinxi to run now.

I poked around this issue and ran the debuggers to make sure I hadn't actually created an undesired lag or bottleneck somewhere, but the data was conclusive, this is a slowdown that happens the moment you request to read one of the core scaling_cur_freq files. This tells me a further thing, using /proc/cpuinfo is not giving you the current speeds, at least I do not believe it is, I think that's maybe a snapshot or something that is stored, not sure, but the debuggers show me super granular timers that it takes about 0.01 seconds to grab and parse cpuinfo, but it only takes about 0.001 seconds to actually read the file, which I suspect means that is not actually generated in real time, unless there is a totally different way to get CPU core/thread speeds.

I'd have to look at the kernel code to see how the speeds in /proc/cpuinfo are actually generated, because obviously if they are current and accurate, that would be a far preferable source for speeds, but my strong suspicion is that that is not real live data, it's sort of an illusion based on some type of cached data, though I don't know that, it's only a guess, but to get say, 32, or 64 core speeds, in that millisecond of time, strikes me as not likely.

inxi has used scaling_cur_freq as its primary speed source for a long time however, and the new logic wouldn't really work without using those values, but it does make me wonder where /proc/cpuinfo is actually getting that data from. 10 to 1 a cache of cpu speeds of some type I'd guess that is refreshed every unknown interval. I use similar tricks at work to generate apparently live data that is actually not live, in order to drastically improve speed for the end user without any real loss.

Conclusion, pretty much done barring bugs...
I can tell in the way the features and idea flow is moved to aesthetic and fixing little niggling things. I can also tell how much has changed by my getting tempted to call this release 3.4.00, though technically inxi isn't supposed to get a secondary number version bump unless it gets a new line data item, a new feature that is, so I'll probably leave this as probably the biggest single point release version inxi will ever get, at least I hope ever.

So I might as well get all the stuff that's been bugging me worked out.

The help here has been absolutely invaluable, I don't think the CPU logic would have worked without seeing how wide the data variations could actually be. Ongoing noticing of glitches and non desirable behaviors (like 1 column indentation being a pain to read) also welcome because after a while, stop seeing the stuff objectively, and just see the neat idea that is kind of working, not how it actually looks.

Since I did more core changes today, I guess I have to wait another 24 hours to do the final release, but everything is set for release, man, help, man and help html pages are done, so it's just a matter of actually moving it to inxi, though I expect one or two more glitches based on the last few days output formatting changes. But I found some stuff via those that had been broken for a long time, so that's making me optimistic.

1 members found this post helpful.

Oops, i forgot, inxi removes color codes from piped output for several reasons, one of them being this:

Lol, that's why color codes are removed, I never actually knew about less -R, that's a good one.

So -Y is a good thing. I have used less on remote systems sometimes because -Y didn't exist, but now I'll use -Y I think since it looks nicer. I also don't have to exit -Y when I get to the end, it just ends.

Or use less -R, if you prefer, also a fine option, more than one way to skin this cat.

less -R is good to know about though, I didn't know that one. But Y is 1 character, and 'c32 | less -R' is 13 (including typing the color code to bring color back), but still good to know that one. I'll add a note about less -R plus color code to preserve colors in the man page.

So this seems solid, a long standing little annoyance is removed, which is always a good thing.

fourtysixandtwo, re adding the kitchen sink, lol, sadly that ship has already sailed... however, despite appearances in this thread, I don't actually strive to be working on inxi full time, but sometimes I have to buckle down and really fix some big issues, and that tends to get a lot of people's attention, who then make suggestions, which are generally quite good, which are implemented (like --zv to filter out vulnerablities if you want).... plus the essentially non stop slow dribble of issue reports and suggestions and behind the scenes requests that keep expanding what inxi does. Plus finding a ton of subtle failure cases because of looking very close at the output.

But I do try to maintain a fairly consistent pinxi, pinxi -b, and pinxi -F output, that is, not add much to default output modes beyond tweaking them a little bit now and then.

Example:
and:
The first one highlights the exact problem inxi has had with public posting of the output, that awkward side scrolling in the code box which makes it super hard to read the actual data for the issue.

Default no formatting options used changed a lot, by design, but the actual data changed very little, think only the avg: speed for cpu changed in -b, plus 3 new possible cpu types, MST, AMP, AMCP, which most users will not see in most cases. And the way MHz is added to to the speed line.

Last step is to package the new inxi for tinycore, for some reason, I decided to be the packager of inxi for tinycore, though I'm the worst packager, I only do new tinycore releases now and then.

In terms of the default widths in and out of X, I'll watch how inxi is used over coming months and see if those need to be tweaked, or if they are working pretty much as intended.

If you're wondering, inxi was born in IRC, not console/terminals, and the number of lines printed were considered the most critical thing to avoid flooding the IRC channels. But that use is almost totally gone today, and now it's almost all sys admins, support people, forum postings, issue reports, bug reports, etc. But I am still aware of the issues with having too many lines, and it's hard to really let go of its early IRC roots in terms of absolutely minimizing lines and columns use.

One last one, then off to bed:

I was curious about the spindown, which I haven't tested in a while, the difference is quite dramatic in reported speeds (inxi takes a LOT of resources to run because it does so much work):

With default 300 ms sleep delay before grabbing core speeds:
With delay turned off:
As you can see, most of the cores are spiked all the way since they have been churning away figuring out my hardware and other info.

@h2-1

Thanks for all the work you put in to provide this to the community. It was really fascinating the way you kept all informed of what was happening and possibly coming next, and also in answering each and every person who provided feedback. It was fun to watch and actually caused this 67yo to learn something new.

1 members found this post helpful.

Hi "h2-1",

Recently you were writing about the lack and removal of scrollback from the console.

In case no one has recently mentioned it: the lack/removal of scrollback is only in the 'frame-buffer console'. In the 'normal console', the scrollback still works as expected. :-)

For my computers which are to be only servers, I have always (so far) configured them without X, and to use the 'normal console'. (Generally, the monitor I use for initial setup and/or emergency use is rather small.)