diff options
Diffstat (limited to 'inxi.changelog')
| -rw-r--r-- | inxi.changelog | 168 |
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 |