New upstream version 3.3.22-1.upstream/3.3.22-1

1 files changed, 168 insertions, 0 deletions

diff --git a/inxi.changelog b/inxi.changelog
index 9c94a8c..48e1707 100644
--- a/inxi.changelog
+++ b/inxi.changelog
@@ -1,4 +1,172 @@
 ================================================================================
+Version: 3.3.22
+Patch: 00
+Date: 2022-10-08
+--------------------------------------------------------------------------------
+RELEASE NOTES:
+--------------------------------------------------------------------------------
+
+Another big one, with a long time to-do item done! /sys based sensors data is 
+now used as a fallback, with fully revised error messages to handle this new 
+sensor data variant. Due to potential bugs this might create, this was left off 
+of the 3.3.21 release, which needed to go out on a schedule, but there is plenty
+of time for 3.3.22 to be debugged.
+
+--------------------------------------------------------------------------------
+KNOWN ISSUES:
+
+1. inxi can't currently handle raw in[0-9] voltage sensor data from 
+/sys/class/hwmon, that may get corrected, but I've honestly never seen a system 
+that shows raw in[0-9] values as field names, so it's probably not very 
+pressing, but it can happen. Similar that is to how default fanx and tempx field 
+names are processed.
+
+2. Currently only checking -Gx, -Nx device temp for bus IDs ending in .0, which
+is the primary PCI device. I think that's the only one that will have a temp, 
+.1, which is a second device on the same hardware, doesn't have that data in 
+tests. Saves some requests since it's a big glob of /sys.
+
+3. Spiral Linux has no obvious way to determine that it is Spiral and not Debian 
+11 as base distro. No /etc/ files for distro ID contain anything for spiral, so
+leaving that one alone.
+
+4. Can't get 100% reliable cpu level > v2 due to it not being a pure cpu flag 
+based test, which is kind of sadly typical for the originators of this idea, but 
+since the choice was dump the feature, or just use the note: check for > v2, 
+opted for note: check. One wants to ask questions here, but honestly I already 
+know the answer so why bother asking the question... The docs for this are 
+awful, inadequate, incomplete.
+
+My strong suspicion is that this is NOT intended to be a distro-wide feature 
+beyond v2 support minimum, but rather is for specific compile options for a 
+package or daemon or server or whatever that can benefit from this type of 
+fine-tuning. One thinks of Gentoo for example back when such fine-tunings could 
+actually deliver noticeable differences in performance. A per system type 
+feature that is, not a distro-wide feature. At least that's my initial feeling, 
+but this is probably about all the  time I will spend on it since inxi can't get 
+it more accurate anyway.
+
+--------------------------------------------------------------------------------
+BUGS:
+
+1. Bug in monitor position logic, the horizontal/vertical sorts were being done 
+alphanumerically, leading to absurd results where 800 > 2560 or whatever. 
+Basically all x / y positions less than 1000 would have forced the smaller 
+number to be considered as the greatest value. Another corner case find by 
+mrmazda. Thanks mrmazda!
+
+--------------------------------------------------------------------------------
+FIXES:
+
+1. Added i350bb sensor to network sensor type.
+
+2. Small glitch with some scenarios with missing fan1 in sensors, showed fan1 0 
+rpm, but then showed fan 3: empty. That was a slight error in how undefined vs 
+'' empty was treated.
+
+3. Added fix for defective fan speeds, skip fan item if > 15000, which is a bug 
+in the fan speed report, making it useless. Seen 65535 reported RPM. Could 
+probably make it 10000 upper limit but suspect that is a simple bug that creates 
+an absurd value, 2^16 so won't be anything high unless bug active. This fix runs 
+for ipmi, linux, and sysctl fan data.
+
+4. Trying for fix for dynamic gpu voltage, assumed always mV, but might be V.
+
+5. Inadequate or obscure or non-existent redhat/suse documentation led to some 
+fixes for cpu v levels. Note that level v3/v4 can't be fully determined by cpu 
+flag tests, but who cares? Certainly not me. Added 'note: check' for v3/v4.
+
+6. Nvidia device arch id was too loose, false id for non existing lovelace arch.
+Note that due to array reverse, the newest ids will always run first, which 
+leads to possible false positives with first string match tests when no product 
+IDs are available yet.
+
+--------------------------------------------------------------------------------
+ENHANCEMENTS:
+
+1. Elbrus CPU arch, process, year, arch data made more complete using new data 
+resource. Thanks Elbrus guys!
+
+2. Finally, raw, basic /sys/class/hwmon temp data. Linux kernel docs note 
+supports temp, fan, volts, amps, energy. But have only seen temps so far. Can 
+force /sys use with --force sensors-sys / --sensors-sys, though there's no point
+to doing that except to test.
+
+Also changed --recommends to note lm-sensors not required for sensor data now.
+
+3. Adding device temp for -Gx, -Nx. Will only work for Linux and when found, and 
+only for free drivers (I think).
+
+4. Added xdriinfo based dri drivers (with fallback to Xorg.0.log as data source, 
+not as accurate), that will show if and only if that driver is not the same name 
+as a detected X or gpu driver.
+
+5. Another big upgrade to cp_cpu_arch, added and corrected many AMD/Intel 
+matches. 
+
+6. A few more gpu product ids, Intel, added.
+
+7. More disk vendors, ids, the list, as we are now well aware, is endless, 
+reflecting perhaps the futility of pursuing the infinite using finite means.
+
+--------------------------------------------------------------------------------
+CHANGES:
+
+1. Slight changes in how inxi supplies no sensor data messages, and in the 
+fallback cases and handling. More accurate and precise, and more robust overall.
+
+2. Due to complexity of understanding level: and the fact not all cpu flags are
+exposed that are required, moved -Cxx level: to -Ca.
+
+3. Changing slightly inaccurate Sound Server for ALSA/OSS to Sound API, which is 
+the closest I can come to explaining clearly what it is. Note that you can only 
+load one API type audio subsystem/driver, so you will be running one or the 
+other, never both, from what I understand. 
+
+Since OpenBSD sndio includes sndiod, calling that a sound server is basically 
+fine, since it's both the server and the interface, if I understand it right, 
+and there won't be a second sound server listed, actually won't be for any BSD
+that I know of, it's going to be sndio or OSS or nothing, unless something has 
+changed.
+
+--------------------------------------------------------------------------------
+DOCUMENTATION:
+
+1. Man page, updates for /sys/class/hwmon based sensor data.
+
+2. Small update for cpu level v3/v4, added note: check explanation, though it's 
+too hard to really explain this stuff since the docs are... not wonderful, when 
+they even exist and don't contradict each other. 
+
+--------------------------------------------------------------------------------
+CODE:
+
+1. Refined significantly sensors missing data and error messages to be much more 
+accurate and granular. Also enables more sensors tools, though hopefully they 
+won't appear since those are a real pain to implement, but it's more open to 
+being sensor tool agnostic now due to these refinements than before.
+
+2. Added xdpiinfo to debugger.
+
+3. Switched x_drivers to return ref of array of refs, use join for output only, 
+that lets us use the drivers to test dri stuff also (if we want or need to), and 
+keeps it consistent with how most of inxi does that type of data 
+handling/testing. If undef, it means no array ref exists, which makes testing 
+easy.
+
+Not truly understanding hash/array refs when inxi rewrite to Perl started is 
+probably one of the bigger causes of glitches and ongoing optimizations. 
+Basically, in all but very small array cases, it's almost always better to start 
+with a ref from the start as soon as the hash/array moves between functions, 
+with one exception, when it's a globally stored data item. Then it depends. But 
+this requires a consistent testing for null data as well, which is harder if you 
+did it in different ways from the start. But slowly and surely chipping away at 
+these.
+
+--------------------------------------------------------------------------------
+-- Harald Hope - Sat, 7 Oct 2022 11:15:12 -0700
+
+================================================================================
 Version: 3.3.21
 Patch: 00
 Date: 2022-08-22