and compositor support.
This finally implements a first try at mir/wayland detection, along with basic handling of actual
display server type output.
New output for Display Server: Display Server: x11 (X.Org 1.19.0) driver: nvidia
Note that since almost all current Wayland systems will have X.org also installed, for the time
being, the data in the parentheses will be from X.org regardless of what display server is detected running
the actual desktop. Out of the desktop, console, the only thing that will show is x data..
No other data is available to me yet until I get way more debugger data so I can see what information the various
implementations of wayland without x tools actually makes available, my guess is it won't be much.
Also experimental -xx option: -G shows compositor, but only for wayland/mir currently.
I have no idea if this will work at all, but it's worth giving it a try as a rough beginning to
start handling the wide range of wayland compositors being created.
This feature will probably take several versions to get stable.
Also added new debugger data collector data for wayland information, but the pickings are slim, to
put it mildly.
Now there is an -x option for -i that will show the additioanl IPv6 address data for scope global,
temporary, and site. Also a fallback for unhandled scope: unknown. If the tool 'ip' is used, it will
filter out the deprecated temp site/global addresses, ifconfig tool does not appear to offer this
option.
Also changed is that now ipv6 address always shows, it's not an -x option. Probably about time to
start rolling out ip v6 data to users now that ip v6 is starting, slowly, to be used more.
Another small change, the link address for ipv6 is changed from ip-v6: to ip-v6-link so that it's
more clear which IP v6 address it is.
The last commit had a significant logic error in it that did not distinguish between the link address,
which is what should have only shown, and the remaining possible addresses.
I've tried to get a basic bsd support, but it's difficult to know the variants of ifconfig output syntax
Note that this bug is not universal, but I believe this will make inxi more right than wrong
as a general rule. Further note that altitude is NOT actually the altitude of the city/location
requested, in most cases, but rather the altitude of the weather station data assigned to that
location request.
from BIOSTAR. Also fixed a few other sloppy gsub, and fixed a few gensub errors as well.
Since BIOSTAR is a fairly common mobo, I'm surprised I haven't gotten this bug report
before.
This closes issue #102.
While default configs remain in /etc/inxi.conf, the user overrides now use the following order of tests:
1. XDG_CONFIG_HOME / XDG_DATA_HOME for the config and log/debugger data respectively.
2. Since those will often be blank, it then uses a second priority check:
$HOME/.config $HOME/.local/share to place the inxi data directory, which was previously here:
$HOME/.inxi
3. If neither of these cases are present, inxi will default to its legacy user data: $HOME/.inxi as before
In order to make this switch transparent to users, inxi will move the files from .inxi to the respective
.config/ .local/share/inxi directories, and remove the .inxi directory after to cleanup.
Also, since I was fixing some path stuff, I also did issue 77, manual inxi install not putting man pages in
/usr/local/share/man/man1, which had caused an issue with Arch linux inxi installer. Note that I can't help
users who had a manual inxi install with their man page in /usr/share/man/man1 already, because it's too risky
to guess about user or system intentions, this man location correction will only apply if users have never
installed inxi before manually, and have no distro version installed, unlike the config/data directory,
which does update neatly with output letting users know the data was moved.
Note that if users have man --path set up incorrectly, it's possible that the legacy man page would show up
instead, which isn't good, but there was no perfect fix for the man issue so I just picked the easiest way,
ignoring all man pages installed into /usr/share/man/man1 and treating them as final location, otherwise
using if present the /usr/local/share/man/man1 location for new manual install users.
Also, for users with existing man locations and an inxi manually installed, you have to update to inxi current,
then move your man file to /usr/local/share/man/man1, then update man with: mandb command (as root), after that
inxi will update to the new man location.
Also added some more XDG debugger data as well to cover this for future debugger data.
This closes previous issue #77 (man page for manual inxi install does not go into /usr/local/share/man/man1) and
issue 101, which I made today just to force the update.
Just as a side note, I find this absurd attempt at 'simplifying by making more complex and convoluted' re the XDG
and .config and standard nix . file to be sort of tragic, because really, they've just made it all way more complicated,
and since all 3 methods can be present, all the stuff has to be tested for anyway, so this doesn't make matters cleaner
at all, it's just pointless busywork that makes some people happy since now there's even more rules to follow, sigh.
graphics driver, so it would not show in output, which causes support issues for users of that specific
driver, like some cases of Intel. Also inxi would always have failed to show it unloaded in cases where
radeon/nouveau were used but it had been loaded by xorg to begin with. So probably worth updating packages
I'd say.
each disk is on its own line always, this makes it easier to read and/or parse.
Also, the lines now wrap nicely for extra data > console width, or -y 80 for example if
you're trying to force most of the data to fit into 80 columns.
handling, and legacy linux. VM id will remain a work in progress, and will probably
require a few fixes for fringe cases. Nice to have would be things like OpenBSD's
vm which is difficult to detect. However, I believe this should handle roughly 99% of
realworld vm id cases, except for some commercial stuff that will require more data.
Now -M shows device type, like desktop, laptop, notebook, server, blade, vm (and tries to get vm type).
vm detection will take more work, for now I'm just going for the main ones used, but it will certainly
miss some because it's hard to detect them in some cases unless you use root features. Also note, in
most cases a container I believe will display as a vm, which is fine for now.
For BSDs, and older linux, there is a dmidecode fallback detection as well.
Basic support added for Budgie desktop detection. This is waiting more data, so the support will be
missing the version information. Go Budgie!!
Added /var/tmp and /var/log and /opt to basic partition data: -P
This will probably not impact more than a handful of people in the world, but that's fine.
Modified the static BIOS in -M to now show UEFI for actually UEFI booted systems, and, ideally,
UEFI [Legacy] for UEFI booting in bios legacy mode, and BIOS for all others. Hopefully this will
work ok, we'll see.
-B option now shows, if available, battery data. Quite good data for systems
with /sys battery data, only rudimentary for systems using dmidecode (BSDs).
dmidecode has no current voltage/charge/current supported capacity.
Main row shows charge and condition. Condition shows you have much capacity the
battery currently has vs its design capacity. Charge shows the Wh/percent of
current capacity of battery (NOT the rated design capacity).
-x adds battery vendor/model info, and battery status (like, charging, discharging,
full).
-xx adds battery serial number and voltage information. Note that voltage information
is presented as Current Voltage / Designed minimum voltage.
-xxx adds battery chemistry (like Li-ion), cycles (note: there's a bug somewhere in
that makes the cycle count always be 0, I don't know if that's in the batteries,
the linux kernel, but it's not inxi, just FYI, the data is simply 0 always in all
my datasets so far.
For dmidecode output, the location of the batter is also shown in -xxx
A sloppy unescaped / triggered a failure I didn't notice in partition info.
Please update your inxi packages immediately if your version is 2016-03-21 or newer.
on /etc/issue step to first test for os release and not mint, then lsb verison and
not mint, then /etc/issue. This should keep the mint detection working well, as long
as they keep mint string in the /etc/issue file, that is, but that's out of our control.
test for the non deprecated battery test, /sys/class/power_supply/BAT0 existence.
This resulted in failure to indicate 'portable' where applicable.
I may also now add battery information where applicable since that's easy to get from
/sys
1. Add amdgpu to possible xorg drivers list (and gpu sensors data)
2. switch to default dig command to get WAN ip. This is usually but not always faster than
the http method. Because the IP source is not truly trustworthy (run by cisco), I'm keeping a
fallback mode on 1 second time out failure of the previous http based methods. Added dig
to recommended tools list.
NOTE: missing product name/serial info, because it's not being treated by linux kernel
as a standard disk. Could not find that data anywhere in the system debugger dump.
If you know how to find the model name/number and or serial, let me know.
Also small fix, as noted: ip: should be ip-v4 to match with ip-v6, thanks mikaela.
Also some debugger fixes and updates.
Changes: updated inxi updaters to use github locations.
I will do this commit once for googlecode, and once for github, after that,
all commits will go only to github.
inxi moves to github, despite my dislike of for profit source repos, and git,
I decided that I just don't have the time or energy to do it right, so I'm going
to use github.
The project is already moved, though I have left inxi up for the time being on
code.google.com/p/inxi until I move the wiki to http://smxi.org
Everything is pretty much the same, the project url is:
https://github.com/smxi/inxi
The direct download link for the gz is:
https://github.com/smxi/inxi/raw/master/inxi.tar.gz
git pull is:
git pull https://github.com/smxi/inxi master
svn checkout url:
https://github.com/smxi/inxi
And that's about it.
showing Frameworks version, which is apparently NOT the same as the plasma version.
Also added debugger kde versioning to make this stuff less of an ordeal for data collection.
#kde-devel, now using kf5-config --version which gives similar output to kded4 --version
I use this for both 4 and 5, but since 4 has worked fine for years, I'll just use this for 5
and later.
normal, in this case, sddm decided that using a .pid or .lock file in /run was too easy
so they changed to some session id type string in the /run/sddm/ directory.
Speaking for myself, I find such pointless changes from anything resembling normal behaviors
to the reason that gnu freedesktop systems will never achieve significant desktop use globally.
Also, in the same vein, added debuggers to try to figure out what plasma5/kde 5 is using
internally to give command line version information. Again, something pointless internally
was changed, thus breaking something that had faintly resembled an api, which is of course
why desktop gnu linux will never actually take off, developers in the real world have no
interest in chasing after such pointless and never ending churn in even the most trivial
areas of the OS, let alone the core.
inxi remains however as a log of this ongoing churn and lack of discipline, and so remains
an interesting process of observation, and a way for users to try to avoid the constant
changes in simple system queries that should really never change, so I can see a reason
to keep it going since it's obvious that the actual foss ecosystem itself will not and apparently
cannot grasp that it is the lack of stable apis, methods, etc, that has kept desktop gnu linux
from achieving any actual real world success or popularity, and that is the actual problem
that should be fixed, not some pointless internal change to something.
On the source repo front, maintainers, I still can't find an acceptable alternative to the
impending shutdown of googlecode. github is a for profit venture that people who seem totally
void of any sense of history believe is actually going to be around longer than say, sourceforge,
or googlecode, as a legitimate source hosting site.
I'd welcome any suggestions. So far all the options are bad that I can find.
Top preference is svn, but if git is the absolute only other choice for an otherwise good option,
I'd consider git, but it's a horrible option for inxi because of how inxi development and debugging
works, vs how git works. ie, svn branches are perfect, git branches are totally wrong.
I may end up just hosting the svn on my own servers to avoid having to move yet again when the next
for profit flakey site decides to close up or monetize the source hosting.
The original idea of googlecode was for google to 'pay its dues to the foss community', but apparently
they got bored with that idea, plus of course, the ongoing total failure of google to deal with
automated spam, which has always been a huge bug in the core google corporate culture. But googlecode
was by far the best option I've come across, it was done by a deep pocketed corporation not for profit
for pretty good reasons, and was never intended to be a profit center, which is the closest I could
see for a non free option.
Setting up svn gui stuff however is a royal pain and requires ongoing maintainance for the life of
the software, which is NOT fun, nor will I sign up for that obligation.
I may end up moving to github anyway, even though git truly sucks for inxi and myself, but it's an
idea I find fairly vile, apparently free software (sic) authors seem to have no grasp of the concept
of fredom when it comes to source code hosting, judging by the absurd popularity of github as the
default go to source repo. Their website is pathetic as well, which isn't very promising.
So we'll see where it goes, I think I have until august to decide what to do for source hosting.
Since I'm old enough to have seen sourceforge and now googlecode do the same thing, along with a lot
of other options, to say github won't do this too is delusional, what you can almost certainly say is it
will do it, the only question is when. But, just as Linus did with his non free linux kernel version
control, people will stick with the non free stuff until you realize you can't use it anymore, because
it is non free. Free software hosted on non free source repos is to me one of the most absurd and
stupid things I've ever heard of to be honest.
the switched file name. Kudos to anyone out there fighting to create a working alternative
to the unreliable and buggy and windows emulating systemd, I wish devuan luck. Maybe between
devuan and gentoo and slackware we can save the free software core systems before it's too late.
pet peeve of mine. Now, if -I, -b, -F, or anything that can trigger the memory: used/total
in Information line is not used, -tm will always show the system used/total ram data on the
first line of the Memory item of -t output.
Also, if -xtc (trigger ram data in cpu output) is used, and -I is not triggered, and -tm is
not triggered, will also show system used/total ram data on the cpu first line.
I'd found it odd that this data did not appear when -tcm or -tm or -xtc were used, so this is
now fixed. I used the -t option a fair amount to find memory/cpu use issues, and usually I
don't use the option with other options, so the lack of total system ram data was odd.
long term solution to identify itself, so the hack I had in place fails on new MATE.
We'll see if this does it for various glitches, now quassel and mate latest should
again be working.
fine for all derived distros like Sabayon as well. The test looks for:
/etc/portage/repos.conf/ and type -p emerge
if found will then grab the repos from the source files found.
Note that the logic for this was almost identical to that used for rpm so it was an
easy addon. Please let us know if you have an issue and provide data samples of relevant
files.
1. Tightened runit init detection to use proc, note that if runit works on BSDs inxi will
require more data to properly detect it on BSDs..
2. Use openrc runlevel tests natively if openrc detected.
3. Fixed subtle issue with alias to inxi file and paths.
4. Added rc-status data collection for debugger, improved debugger data collector handling
of bsd and other tests to note absent if not there in file names.
Fixed bugs in Epoch init system detection, caused false positives in systems booted on
SysVinit, but with Epoch installed. Epoch turns out to be in PID 1 == epoch (/proc/1/comm)
so that's easy to fix.
Also fixed spacing isxue with OpenRC output in -I line.
at least on the system I got data from, is not using .pid/.lock extensions, but other systems
are, I'm adding sddm AND sddm.pid detection. This required changing the id to use explicit -f
for test, not the previous -e, which will force only files, not directories, to trigger yes case.
No other changes, but it's worth updating to this because distros may start using sddm in the not so
distant future, it's beta currently though.
