Show newer

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.

Because Parse::EDID is not in perl Core Modules, and was/is not even packaged in some large distros, I decided to integrate the code directly into pinxi for next inxi. This is now being finalized. I also added some features to it, and fixed some stuff that made no technical sense. This is running live now in pinxi, and will allow for 'out of the box' fairly complete monitor data for all Linux users (through edid file) as long as it's a drm monitor/graphics interface, with edid data.

Monitor data support is also hugely enhanced, particularly if Perl module Parse::EDID is installed.

Also, for those so inclined, you can now help support the project on with either a one time or a sustaining donation. Help free software authors help you!

Latest features closer to going live, this time it's the -G/Graphics logic that is getting a big upgrade and makeover. As with CPU, this one had some of the oldest logic in inxi. Now in pinxi, support for Wayland compositors hugely enhanced, but due to lack of single standardized tool like xrandr, I have to add the tools in one by one: swaymsg, wlr-randr, wayland-info, weston-info. No support for kwin_wayland or Mutter wayland yet, no data, no info.

Holy Toledo!! Manjaro I think set an all time record, inxi 3.3.10 is already in their 3 branches.

Should hit Manjaro repos within 24 hours if they maintain their normal rapid updating cycle for inxi. Others will trickle in after that. Debian testing/stable should follow sometime after that.

inxi 3.3.10 just out the door now, will wait to see how regular non alpha/beta tester users will react to the changes and fixes for a few months ideally before doing a follow-up release.

pinxi -Cay1
Speed (MHz):
avg: 2803
high: 3892
min/max: 1550/3400
boost: enabled
1: 1559
2: 1552
3: 3892
4: 3865
5: 2850
6: 2768
7: 3284
8: 3314
9: 1449
10: 2008
11: 3212
12: 3891
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm

and so on. Last bugs have been difficult to resolve, hoping today's is the final real one.

pinxi 3.3.09-32 - last bugs being fixed!

pinxi -Cay1
model: AMD Ryzen 5 2600
bits: 64
type: MT MCP
arch: Zen+
family: 17 (23)
model-id: 8
stepping: 2
microcode: 8008204
bogomips: 6799
cpus: 1
cores: 6
tpc: 2
threads: 12
smt: enabled
L1: 576 KiB
desc: d-6x32 KiB; i-6x64 KiB
L2: 3 MiB
desc: 6x512 KiB
L3: 16 MiB
desc: 2x8 MiB
Speed (MHz):
avg: 2803

Quickly followed 3.0.31 with 3.0.32, in order to add a few more weather features, and better ability to handle attribution requirements.

Made it just in time for Debian/Ubuntu next release freezes, I think, it's in sid, and should make it into testing before Ubuntu freezes their testing pool for disco release.

Just did 3.0.31 release, which features a new way to handle weather requests. Also added an option to change the source for IP WAN data, but you're in general better off uising the dig method, it's fast and reliable.

Side note: Is there any way to fix the terrible lag I'm getting on mastodon? It's almost impossible to type a post.

3.1.1 released, that features bug fixes, 1 for Opus, and 2 for escaping " and & in the path when encoding. Everything should be working fine now.

3.1.0 quickly followed 3.0.0, and featured support for Opus output format. Since Opus comes from the same bunch that makes Ogg, the logic was pretty easy to implement, so I decided why not add another output format. Here's to many more years of syncing flac to ogg/opus/mp3 audio libraries!

Grab it at:

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!