home.social

#inxi — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #inxi, aggregated by home.social.

  1. @EpiphanicSynchronicity @ozamidas @anildash yes re excellent docs. When I was extending window manager and desktop support I installed everything available, in some vms. i3 had by far the best docs of anything I tested. Best man page, best web docs, so I figured if their docs are this good their code must be as well. Sadly the same could not be said for , the wayland i3 clone. Maybe that's gotten better by now. i3 docs also inspired me to upgrade inxi docs and public data.

  2. Oh I nearly forgot. New 3.3.40 rolled out. This is mainly a critical bug fix for a feature very few people use (export to json/xml), plus a key name change. I have a rule that key names can't hold values, but I'd slipped and used BIOS or UEFI as the keyname, instead of firmware: BIOS. Plus a few small fixes. I tend to wait until there are enough updates to warrant a new release, but a bug that makes a feature always fail forced the early release.

    Bug was a silly bad copy/paste, sigh.

  3. The classic window manager and desktop site xwinman.org came up in an unrelated issue on . I had used that site to create the original list of window managers inxi supported, but then I didn't think about it.

    One thing led to another and I found most of the site, except the /archive/ section, which is at archive.org.

    Since this is roughly my skill, I grabbed the site, upgraded it to modern responsive html/css standards: smxi.org/wm/

    Try it on your phone!

  4. With a faint whoosh 3.3.39 goes out the door. Some nice battery upgrades and more cpu variants handled. I got a flurry of pretty good issues which led to most of the improvements and fixes. Also added a section to the inxi.changelog UPDATES: which are all the manually generated matching tables etc.

  5. Ongoing next updates. After the data and upgrade, I decided to grit my research teeth and dig into x86 Via Centaur based CPU. As usual, I had to combine data sources to get the info on each variant. Now pinxi detects Zhaoxin, and gets advanced microarchitecture data for each known model.

    Previously this was tossed in with Centaur data, which cut off when zhaoxin split from via (cpuid family 6 > 7). And was wrong too.

    It's absurdly hard to find this cpu data.

  6. Ongoing #pinxi next #inxi updates. After the #Loongson data and upgrade, I decided to grit my research teeth and dig into #Zhaoxin x86 Via Centaur based CPU. As usual, I had to combine data sources to get the info on each variant. Now pinxi detects Zhaoxin, and gets advanced microarchitecture data for each known model.

    Previously this was tossed in with Centaur data, which cut off when zhaoxin split from via (cpuid family 6 > 7). And was wrong too.

    It's absurdly hard to find this cpu data.

  7. Ongoing #pinxi next #inxi updates. After the #Loongson data and upgrade, I decided to grit my research teeth and dig into #Zhaoxin x86 Via Centaur based CPU. As usual, I had to combine data sources to get the info on each variant. Now pinxi detects Zhaoxin, and gets advanced microarchitecture data for each known model.

    Previously this was tossed in with Centaur data, which cut off when zhaoxin split from via (cpuid family 6 > 7). And was wrong too.

    It's absurdly hard to find this cpu data.

  8. Ongoing #pinxi next #inxi updates. After the #Loongson data and upgrade, I decided to grit my research teeth and dig into #Zhaoxin x86 Via Centaur based CPU. As usual, I had to combine data sources to get the info on each variant. Now pinxi detects Zhaoxin, and gets advanced microarchitecture data for each known model.

    Previously this was tossed in with Centaur data, which cut off when zhaoxin split from via (cpuid family 6 > 7). And was wrong too.

    It's absurdly hard to find this cpu data.

  9. Amazingly, someone showed up in with an issue about CPU support, something I have looked for data on for years. He provided 5 full sys-ci file pairs, which let me crudely emulate the cpu in test mode. Turned out the detection failed because as of Loongson 3A5000 they have their own ISA, in other words it's its own type, forked from MIPS. Fixed the detection and many other glitches, added --loongson emulation flag, and now support works better than ever.

  10. Amazingly, someone showed up in #codeberg with an #inxi issue about #Loongson CPU support, something I have looked for data on for years. He provided 5 full sys-ci file pairs, which let me crudely emulate the cpu in test mode. Turned out the #MIPS detection failed because as of Loongson 3A5000 they have their own ISA, in other words it's its own type, forked from MIPS. Fixed the detection and many other glitches, added --loongson emulation flag, and now support works better than ever.

  11. Amazingly, someone showed up in #codeberg with an #inxi issue about #Loongson CPU support, something I have looked for data on for years. He provided 5 full sys-ci file pairs, which let me crudely emulate the cpu in test mode. Turned out the #MIPS detection failed because as of Loongson 3A5000 they have their own ISA, in other words it's its own type, forked from MIPS. Fixed the detection and many other glitches, added --loongson emulation flag, and now support works better than ever.

  12. Amazingly, someone showed up in #codeberg with an #inxi issue about #Loongson CPU support, something I have looked for data on for years. He provided 5 full sys-ci file pairs, which let me crudely emulate the cpu in test mode. Turned out the #MIPS detection failed because as of Loongson 3A5000 they have their own ISA, in other words it's its own type, forked from MIPS. Fixed the detection and many other glitches, added --loongson emulation flag, and now support works better than ever.

  13. More battery updates in next

    Added more values and updated docs using kernel.org /sys/class/power_supply items.

    They have been busy and added many new values.

    issue #341 prompted me to check what was available. Answer was a lot more! Most consumer systems won't have many of these, like battery temp, but now will show extra if it finds it. Also reordered and restructured fields to allow more clear ordering.

    Fun fun.

    Turns out 3.3.39 will be the battery upgrade release

  14. @[email protected] I had to think about it. -terminal. I use almost every day but I always use the terminal, and inxi does many things. Since I use it to be a terminal only, I guess that's the closest I get to something that does one thing well on a daily basis. Also Kate but it does several things but it is really just a code editor. And . And often . I like using tools I made for my needs.

  15. @doctator I had to think about it. #xfce-terminal. I use #inxi almost every day but I always use the terminal, and inxi does many things. Since I use it to be a terminal only, I guess that's the closest I get to something that does one thing well on a daily basis. Also Kate but it does several things but it is really just a code editor. And #Filezilla. And often #acxi. I like using tools I made for my needs.

  16. @doctator I had to think about it. #xfce-terminal. I use #inxi almost every day but I always use the terminal, and inxi does many things. Since I use it to be a terminal only, I guess that's the closest I get to something that does one thing well on a daily basis. Also Kate but it does several things but it is really just a code editor. And #Filezilla. And often #acxi. I like using tools I made for my needs.

  17. @doctator I had to think about it. #xfce-terminal. I use #inxi almost every day but I always use the terminal, and inxi does many things. Since I use it to be a terminal only, I guess that's the closest I get to something that does one thing well on a daily basis. Also Kate but it does several things but it is really just a code editor. And #Filezilla. And often #acxi. I like using tools I made for my needs.

  18. @doctator I had to think about it. #xfce-terminal. I use #inxi almost every day but I always use the terminal, and inxi does many things. Since I use it to be a terminal only, I guess that's the closest I get to something that does one thing well on a daily basis. Also Kate but it does several things but it is really just a code editor. And #Filezilla. And often #acxi. I like using tools I made for my needs.

  19. In (next ) a full refactor of the venerable Battery module. A issue exposed the bad logic of the battery feature, which near as I can tell was roughly translated verbatim from the original bash during the rewrite. I thought I'd redone all those but I missed battery section obviously. The only difference most users will see is fewer or more decimals. Issue was 0.01 Wh capacity and current charge. Which was prematurely trimmed to 0, actually string '0.0', aka true.

  20. #Inxi est un excellent utilitaire en ligne de commande pour obtenir des informations détaillées et complètes sur le matériel, la configuration du système, les processus, la configuration réseau, etc.

    Un de mes utilitaires préférés auquel j'ai régulièrement recours pour mon ordi sous #Linux quand j'ai besoin d'une info système particulière.

    😉

    linuxtricks.fr/wiki/inxi-un-sc

  21. But wait, there's more cpu arcana!

    Intel, for inexplicable reasons, decided to keep their family stuck on 6. Which leads to them running out of the 256 possible model ids (16x16). This leads them to resort to using stepping id to tell various series apart, which is a royal pain to track. I was hoping they'd stop and use 12 when they did 12th gen Alder Lake, but no such luck.

    Why? I'm guessing some vendor hardcoded in family 6, or it's just a symptom of intel engineering problems.

    4/

  22. ( arcana con'd)
    Amd for family does this:
    Extended Family : Family is:
    Extended family + family.
    So for say zen 2, cpuid shows 8F as family. 8 + F = 23, the hex of which is 17h, aka 16 + 7. 23 is what cpuinfo shows. 17h is what inxi uses internally.

    Since this makes zero logical sense, I've had to update each family block with these 3 values.

    I had zen 5 as Family 20, not 1A, cpuid BF, aka 11 + 15 aka 26 aka 1A.

    Got that? Why isn't cpuid simply 1A? Who knows.
    3/

  23. Here's a peek into the arcana of research, which is then added to docs and tools, in repo, in this case docs/inxi-cpu.txt and tools/cpu_arch.pl.
    This is the data provided by cpuid binary. These are hex values.
    en.m.wikipedia.org/wiki/CPUID
    Normally extended model 3 and model F would give 3F = 3x16 + 15 = 63. And that is how amd does their extended model : model ids.
    /proc/cpuinfo shows this as an integer. So far so good.

    But then amd does something which makes my head hurt:
    (Con'd)
    2/

  24. Meanwhile on the front, youtu.be/bvHrJzB4-MQ?si=LCrrym
    MooresLawIsDead got leaked specs for AMD Zen 7 cpus. With earlier zen 6 specs, this let me try to get support in before actual data appears. That's rare for cpus and gpus. I also realized I'd used the wrong family id for zen 5 cpus, which means advanced architecture data probably never showed.

    This is an easy mistake to make because the way amd does their extended family id is different from how they do their extended model ids.
    1/

  25. With the quietest of whispers new 3.3.38 goes out the door. A few fixes, a few enhancements. But maybe the fewest changes in a new release. The main one was a syntax change for vulkan driver that made inxi show N/A always on newer systems.

    Plus an actual sensors bug I found by pure chance. And an anonymous dataset from a vm that exposed some invalid assumptions about values always being present for any given field name.

  26. @dumpsterqueer you'll never miss github. All that happens when you move to @Codeberg is the signal to noise ratio skyrockets and you end up with mostly good issues. That's been my experience anyway.

    At first I worried about losing all those eyeballs and followers but it quickly dawned on me their quality on gh was so low they were negatives.

    My project keeps getting starred on gh despite having no commits for 1 yr and saying moved to cb. Not reading was my other peeve about gh users lol.

  27. @arstechnica
    Checked for gpu support. I'm not sure why this story was put out. Seems like every 6 months or so some site/channel discovers the driver story. But doesn't research it.

    Current status. Maxwell, Pascal, Volta (those 3 next legacy), along with Turing and newer (supported by foss wrapper) supported in active driver branch (565.xx). The wrapper is not a driver.

    Announced with git repo May 2022.

    The actual foss driver is Nova. I think.
    5/

  28. @arstechnica I have to track nvidia drivers for and in *nix. What's surprising is how long it's taking to make pre Turing/Ampere drivers legacy. That was supposed to come over a year ago. Legacy does not mean no support. Legacy drivers get several years more support. There's nothing new here.

    The cut happens because Turing and newer have moved most of driver into firmware. kernel will use open source wrapper to talk to firmware.
    1/

  29. @arstechnica I have to track nvidia drivers for #inxi and #sgfxi in *nix. What's surprising is how long it's taking to make pre Turing/Ampere drivers legacy. That was supposed to come over a year ago. Legacy does not mean no support. Legacy drivers get several years more support. There's nothing new here.

    The cut happens because Turing and newer have moved most of driver into firmware. #Linux kernel will use open source wrapper to talk to firmware.
    1/

  30. @arstechnica I have to track nvidia drivers for #inxi and #sgfxi in *nix. What's surprising is how long it's taking to make pre Turing/Ampere drivers legacy. That was supposed to come over a year ago. Legacy does not mean no support. Legacy drivers get several years more support. There's nothing new here.

    The cut happens because Turing and newer have moved most of driver into firmware. #Linux kernel will use open source wrapper to talk to firmware.
    1/

  31. @arstechnica I have to track nvidia drivers for #inxi and #sgfxi in *nix. What's surprising is how long it's taking to make pre Turing/Ampere drivers legacy. That was supposed to come over a year ago. Legacy does not mean no support. Legacy drivers get several years more support. There's nothing new here.

    The cut happens because Turing and newer have moved most of driver into firmware. #Linux kernel will use open source wrapper to talk to firmware.
    1/

  32. @arstechnica I have to track nvidia drivers for #inxi and #sgfxi in *nix. What's surprising is how long it's taking to make pre Turing/Ampere drivers legacy. That was supposed to come over a year ago. Legacy does not mean no support. Legacy drivers get several years more support. There's nothing new here.

    The cut happens because Turing and newer have moved most of driver into firmware. #Linux kernel will use open source wrapper to talk to firmware.
    1/

  33. Fastfetch liefert Systeminformationen

    Dieses Werkzeug stellt Systeminformationen im Termin übersichtlich dar. Durch seine Konfigurierbarkeit lässt sich Fastfetch an die eigenen Bedürfnisse anpassen.

    #fastfetch #Neofetch #System_Information #Inxi #Linux

    gnulinux.ch/fastfetch

  34. Got a good issue report. Graphics API item failed to show driver. Turns out that somewhere between vulkaninfo v. 1.3.255 and 1.3.296 they dropped the device driver summary data block. It was always also in a much larger and longer block but I'd never trusted the block name to be consistent. I still don't but there's no choice.This is fixed in but sadly just missed the 3.3.37 release by a few days. Oh well. A user reported it after seeing driver: N/A always.

  35. Found an obscure that appears to be unique. That is, makes its own toolchain, which is what crazy from said defines a base distro. Side uses package manager, and features based with or window manager.

    These odd little distros generally help find and handle corner cases it had missed. In this case didn't have pisi pm/SDE handled.

    Wish I'd noticed side before inxi 3.3.37 went out but this always happens.

  36. Found an obscure #Linux #distro #side that appears to be unique. That is, makes its own toolchain, which is what crazy from #frugalware said defines a base distro. Side uses #pisi package manager, #sysvinit and features #LXDE based #SDE with #pekwm or #openbox window manager.

    These odd little distros generally help #inxi find and handle corner cases it had missed. In this case didn't have pisi pm/SDE handled.

    Wish I'd noticed side before inxi 3.3.37 went out but this always happens.

  37. Found an obscure #Linux #distro #side that appears to be unique. That is, makes its own toolchain, which is what crazy from #frugalware said defines a base distro. Side uses #pisi package manager, #sysvinit and features #LXDE based #SDE with #pekwm or #openbox window manager.

    These odd little distros generally help #inxi find and handle corner cases it had missed. In this case didn't have pisi pm/SDE handled.

    Wish I'd noticed side before inxi 3.3.37 went out but this always happens.

  38. Found an obscure #Linux #distro #side that appears to be unique. That is, makes its own toolchain, which is what crazy from #frugalware said defines a base distro. Side uses #pisi package manager, #sysvinit and features #LXDE based #SDE with #pekwm or #openbox window manager.

    These odd little distros generally help #inxi find and handle corner cases it had missed. In this case didn't have pisi pm/SDE handled.

    Wish I'd noticed side before inxi 3.3.37 went out but this always happens.

  39. Found an obscure #Linux #distro #side that appears to be unique. That is, makes its own toolchain, which is what crazy from #frugalware said defines a base distro. Side uses #pisi package manager, #sysvinit and features #LXDE based #SDE with #pekwm or #openbox window manager.

    These odd little distros generally help #inxi find and handle corner cases it had missed. In this case didn't have pisi pm/SDE handled.

    Wish I'd noticed side before inxi 3.3.37 went out but this always happens.

  40. And yes, just sent the 3.3.37 package off to - which is the last step of the process.

    So that completes this 4 month release cycle. It would have been less but the monitor scaling feature of course turned into a rabbit hole.

    But read the changelog if you are curious. It's long and thorough by design because it's the actual record of what changed, why, and what isn't currently doable. I use it often to find when why and how features are added or removed or changed.

  41. New 3.3.37 goes out the door. Includes last minute workaround for 32 bit intel gen2 gpu eglinfo hang found. Probably a regression in i915 driver. And the big monitor scaling feature.
    Full changelog here:
    codeberg.org/smxi/inxi/src/bra

    This is the longest between releases in quite a while so nice to get some nifty enhancements and fixes in.

    This also introduces the improved option syntax for -b -e, which gets rid of a peeve of -F being impossible to explain.

  42. Churning through an unexpectedly complicated series of updates in next

    Got the gpu monitor scaling handled which required fixing xrandr and wayland tool parsing and logic. False assumptions led to errors in output.

    --force options were glitchy and inconsistently used and documented. Cleaning that up exposed more glitches, like --no-man not working in inxi due to opaque hash names.

    It's surprising how fixing docs, help, and man exposes bugs in logic. Still polishing that up.

  43. Just released new (next ) has first draft of working monitor scaling support. The higher physical screen resolutions get, the more scaling is used. had off and on mentioned this as nice to have feature.

    Not easy to figure out data sources but seems to work with and wayland-info now.

    I realized I could do scaling on my with which made dev a lot easier. Plus a good data file of scaled 3 monitor setup.

    Updated graphics docs with new res section.

  44. Just released new #pinxi (next #inxi ) has first draft of working monitor scaling support. The higher physical screen resolutions get, the more scaling is used. #mrmazda had off and on mentioned this as nice to have feature.

    Not easy to figure out data sources but seems to work with #xrandr and wayland-info now.

    I realized I could do scaling on my #xfce with #x11 which made dev a lot easier. Plus a good data file of #wayland scaled 3 monitor setup.

    Updated graphics docs with new res section.

  45. Just released new #pinxi (next #inxi ) has first draft of working monitor scaling support. The higher physical screen resolutions get, the more scaling is used. #mrmazda had off and on mentioned this as nice to have feature.

    Not easy to figure out data sources but seems to work with #xrandr and wayland-info now.

    I realized I could do scaling on my #xfce with #x11 which made dev a lot easier. Plus a good data file of #wayland scaled 3 monitor setup.

    Updated graphics docs with new res section.

  46. Just released new #pinxi (next #inxi ) has first draft of working monitor scaling support. The higher physical screen resolutions get, the more scaling is used. #mrmazda had off and on mentioned this as nice to have feature.

    Not easy to figure out data sources but seems to work with #xrandr and wayland-info now.

    I realized I could do scaling on my #xfce with #x11 which made dev a lot easier. Plus a good data file of #wayland scaled 3 monitor setup.

    Updated graphics docs with new res section.

  47. I should probably get off my butt and release next . There haven't been any real issues for a while now. Though had an advanced display resolution enhancement request but it takes work and thinking to do. And testing.

  48. @jk your fundamental error was obvious in your Initial pist. You believe distros are little corporations competing against each other for supreme dominance.

    This is profoundly wrong.

    Distro means distribution. Of what? An often massive set of free software projects, kernel and being 2 of the larger. being a smaller.