Testers for inxi/pinxi redone -C CPU logic... huge internal changes
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
That's the safest solution. I'm glad to hear that my failure to find a better way is echoed by the f2fs group, who work much more closely with these questions than I do in inxi.
I should probably start a new thread, but I'm getting the finishing touches done on a similar full refactor, to -G / Graphics this time.
Fairly stable as of today I think, features significant inroads to Wayland support, and almost complete data/output abstraction, and ability to switch between data sources seamlessly.
pinxi -U then pinxi -Gay1 if you want to check the new stuff out.
Monitors now show as -Gxx, and -Ga is much more focused on admin type data for -G.
Your output for monitors will be significantly enhanced if you install the perl module Parse::EDID which is roughly what gave me a lot of the missing data for wayland, and a lot of new data for X.org desktops.
It has some fallbacks, if neither that perl module or read-edid/parse-edid are present, it tries a very basic 'strings' type read of the edid binary blob, which actually results in ok results for monitor model in many cases, at least, in some cases. But Parse::EDID gives really good results. Note that not all monitors have edid data, I was fortunate in my tests to have a good test setup with 2 monitors, one with no edid, one with, which let me debug a lot of missing data issues.
The initial plan, now largely working, was to get at least one wayland compositor reporting the required data, then building up the internal logic to handle these data source changes, then start adding compositors as I learn, or they make, the tools required to get some basic data. Note that most monitors and displays should have fairly complete data for single monitor systems, and will be missing the position data, which has to come from the compositor (or xrandr for xorg), as long as Parse::EDID is available. I tried to find a way to do this without that tool, but it just wasn't possible, so grudgingly, I'm going to recommend to maintainers and packagers that they install a dependency to get full support for this feature, though it's not required, and a lot of the data will still work ok.
Sway was a very pleasant surprise, it wasn't random picking it as the first wayland compositor to create the core logic with, as with i3, it's apparently quite well done, and feature complete. There was talk of wlroot, sort of the core logic used by many compositors now, also having wlrandr, but I haven't seen any sign that project took on a life of its own after the initial talk, but that would have been an ideal solution to trying to handle all those compositors that popup every time someone feels like making another one.
This example is with Sway and Xwayland, which is also the only apparently complete compositor/tools I am aware of so far for wayland, with swaymsg giving quite good output data, sort of like xrandr. If you know of comparable tools for gnome (or any other wayland compositor with cli tools to get data, particularly KDE/kwin_wayland), I haven't been able to find anything, odd given that ubuntu/debian/fedora are shipping gnome with wayland as default, but unless I've missed something, still no cli tools to get this sort of data. Main thing I need per compositor is a cli way to determine it's x / y position if > 1 monitors, most of the rest of the data can come from /sys now, if you have Parse::EDID installed.
Like -C, this started with a seemingly innocent feature request, but morphed into a full refactor and rewrite, very similar to the CPU stuff, with a huge improvement in output and reliability.
Sure to be some bugs and failures, and if no /sys/class/drm data, then not much new data will be there, but what is found is more reliable and better organized.
Also can get monitor data out of display now, in console, that's totally new, that was a sort of result of the initial wayland stuff, which enabled a lot of new output features.
Not as intrinsically interesting as cpu stuff unless you are really into the graphics part, but still was a big fix, and with cpu, probably the two oldest, and worst, parts of inxi, with the most legacy carryover logic, which is now largely completely gone. The less said about total lines of code required to achieve these results, the better, sigh...
And yes, Xvesa support was enhanced quite a bit as well, that was useful to present several possible ways of creating the display, Xorg, Xvesa, Wayland, that helped create the abstraction rules, and added some nice features for TinyCore and anyone else who uses Xvesa.
You're timing could have been a bit better as I think the new slackware release is keeping everyone busy.
Found a bug running it on a rpi and macos
Code:
$ /iso/pinxi/pinxi --version | grep ^pinxi
pinxi 3.3.12-25 (2022-02-11)
$ /iso/pinxi/pinxi -Gazy1
Can't use an undefined value as an ARRAY reference at /iso/pinxi/pinxi line 14799.
Here's an sdiff before and after adding the Parse::EDID module
Congratulations on the new slackware by the way, I should have said that, I just realized it had come out.
Timing is hard, this graphics stuff took a lot longer to get working than I'd hoped, the state of wayland tools, if you can even use such a term, is, outside of swaymsg, dismal, so I've had to add more robust data tools, which is why Parse::EDID was a bitter pill I had to swallow, that is the only way to get consistent data across platforms and across display protocols, that works just as well for console mode out of X as it does in wayland.
The string parsing method actually worked super well on all my monitors and systems, at least all with edid data, but of course, as soon as some other people tested it, that string method didn't work very well. I've added filters in it, the assumption being if a certain set of characters is in the string, that data is not useful. The annoying thing is for me, after stripping off the non printing characters, the data was actually very good, at least for monitor name, but it's not useful if it corrupts output for some systems. I'll add more filters, it looks like ^ and & are the signs there, the basic rule there is if contains any one of a known set of bad characters, it's suspect so don't use the data.
pinxi -Ga --dbg 44
will show the raw edid data, most of it's non printing characters.
I did a small change which may have resulted in some of that issue, before I was only cleaning out non printing characters at start of line, the change was to clean them all out. I've never seen an example with linebreaks, but I wonder if by cleaning out all of them, inxi somehow changed them to be linebreaks, that's possible.
Many thanks, this stuff is raw, I really only got enough working a day or two ago to present it in public. Sadly as always, it's a given that my small data sample for these things is not adequate given the inevitable variations to be found between systems.
line 14799. was something left over I forgot to remove, was an earlier method I was trying, and that was the cleanup for the earlier method. I don't actually even understand why that tripped an error, since you do in fact have an xorg server, that was where the error was, the server / server version block.
It's possible that the Xorg version string differed, might be that, which would have led to an empty value where it's always full in my tests.
Yes, I see something there:
What is:
Xwayland -version
and:
Xorg -version
My test systems all return:
Code:
X.Org X Server 1.20.13
X Protocol Version 11, Revision 0
and
Code:
The X.Org Foundation Xwayland Version 21.1.4 (12101004)
X Protocol Version 11, Revision 0
It looks like your Xwayland string is something like this:
The X.Org Foundation Xwayland Project Version 21.1.4
Maybe. inxi never grabbed xwayland data before, but for wayland support it's of course important to know the xwayland version, since true wayland systems don't run x.org at all, just xwayland.
inxi shows xwayland if found as well if in console, since it has no way of knowing if it's a wayland system or not in that case. Your xwayland must have a different syntax then.
Oh, sorry, I realized that the sdiff thing must be producing the empty lines. I've fixed the bug that was exposed on rpi, I forgot to ask someone to test on rpi for me, slipped my mind, thanks for thinking of that one. The mac os and pi I assume had similar issues there.
Still don't understand why it failed to deliver a result and thus triggered that glitch, but that was just a line of leftover code which served no purpose anyway, but it puzzles me slightly how that could have been triggered at all.
The line 14799 issue was just on Raspbian Buster(headless) and Mojave but seems to be fixed now with pinxi 3.3.12-26 (2022-02-12).
Code:
$ uname -a
Linux rasp3 5.10.63-v7+ #1496 SMP Wed Dec 1 15:58:11 GMT 2021 armv7l GNU/Linux
$ /iso/pinxi/pinxi -Gazy1
Graphics:
Device-1: bcm2708-fb
driver: bcm2708_fb
v: kernel
bus-ID: N/A
chip-ID: brcm:soc
class-ID: fb
Device-2: bcm2835-hdmi
driver: N/A
bus-ID: N/A
chip-ID: brcm:soc
class-ID: hdmi
Display:
server: No display server data found. Headless machine?
tty: 200x61
Message: Unable to show GL data. Required tool glxinfo missing.
Code:
# uname -rs
Darwin 18.7.0
# /iso/pinxi/pinxi -Gazy1
Graphics:
Message: No device data found.
Display:
server: No display server data found. Headless machine?
tty: 200x61
Message: Unable to show GL data. Required tool glxinfo missing.
Oh, sorry, I realized that the sdiff thing must be producing the empty lines. I've fixed the bug that was exposed on rpi, I forgot to ask someone to test on rpi for me, slipped my mind, thanks for thinking of that one. The mac os and pi I assume had similar issues there.
Still don't understand why it failed to deliver a result and thus triggered that glitch, but that was just a line of leftover code which served no purpose anyway, but it puzzles me slightly how that could have been triggered at all.
Np, I was just trying to show the differences with and without the Parse:EDID plugin installed. I can give you the output separately if needed.
That seems to be different on your setups, at least the one that had xwayland in the results.
Glad there wasn't some string type newline corruption however in the basic edid binary parsing, otherwise I'd have to debate removing that as the last fallback for monitor model info.
Thanks for confirming the other parts, I see what happened now on the headless systems, or the systems pinxi perceived as possibly headless, that was the single scenario I didn't test, when there was no data at all for server, no xorg, no xvesa, and no xwayland, that explains it. But that's removed and was not needed anyway, so glad you caught that one, thanks.
I'm tracking down the options for wayland resolution and screen position in > 1 monitor setups, and think I'll go with the really bad weston-info output, which has also been split, with I do not know what degree of success, currently in no repo I found, to standalone wayland-info. That also, with some convoluted parsing (because that's not meant for machine parsing as far as I can tell), I can work up into the barebones data needed, without having to wrestle with random compositor tools that usually don't exist anyway.
I'm really glad I held off for 10 years plus on trying to support wayland, even at this relatively late stage, the stuff is not good to put it mildely, except sway, which for some reason seem to have an actual idea how to program and develop software, and did a really good job, swaymsg outputs in either human readable or json, swaymsg is the only tool I've found I'd consider ready for prime time in the wayland space. They also created the wayland backend wlroots, with its attendant but low quality wlr-randr tool, which also gives barebones output which is sort of usable.
I was just testing building sway in a VM but had issues with no cursor. Might have to look into it further and try it on a physical machine.
I'll see about testing on the other older hardware when I can too.
Code:
# Xwayland -version
Slackware Linux Project Xwayland Version 21.1.4 (12101004)
X Protocol Version 11, Revision 0
Build ID: xorg-server-xwayland 21.1.4-1
# Xorg -version
X.Org X Server 1.20.14
X Protocol Version 11, Revision 0
Build Operating System: Slackware 15.0 Slackware Linux Project
Current Operating System: Linux k53e.int 5.15.19 #1 SMP PREEMPT Wed Feb 2 01:50:51 CST 2022 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-generic-5.15.19 root=UUID=bd3be2d5-ff20-45a8-8758-e1be914a2c54 ro quiet splash
Build Date: 26 December 2021 04:51:07PM
Current version of pixman: 0.40.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Here's a 32bit P4 with slackware 15. Left=no perl EDID module, Right=with perl EDID module
Oh, great, thanks, I had to redo the Xwayland version info, which isn't a surprise, I have to treat x server versioning differently in inxi than I do with other application version numbers because of these string variances.
Since that variation could well occur anywhere, I've used a more reliable method to grab the version string now, that's in pinxi.
I'm glad this one didn't make it into the new Slackware, lol, since inxi 3.3.12 doesn't have xwayland data.
note also I'm redoing the -Sxxx desktop/window manager data, which because wayland compositors are window managers, I had to pretty much totally redo internally, so I just finished that off. I'm hoping I didn't break some legacy wm handling, which is possible, I'll have to give those a recheck on my wm vms.
Sway in vm had the same issue for me, no mouse, I just used keyboard controls to do it, actually I had partial mouse, but no cursor, so I have to sort of guess where the mouse cursor is.
I ended up doing a mixture of live usb boot for 2 wayland isos and vm testing. My fedora gnome vm wouldn't even start wayland in vm at all, that one only works if I put it on a usb stick and boot it on a machine.
While researching this, I did find mention that wayland has issues with the way vms create screens, and one of the symptoms is that mouse stuff doesn't work right, that may be why fedora decided to just disable the vm load of wayland completely, with no way to select that option that I could find. Wayland is still very very beta, very sketchy. sway is the only one I've seen so far that feels 'done', and 'non-beta', but I haven't actually used it for anything but testing so can't say if it actually is ready for real use or not.
Xwayland version should work fine now.
This one: model: 2F is the risk of having the fallback to the binary string parsing for the edid blob, I've seen that type of result too in testing, and is why I'm debating if I should just dump it as a fallback. The neat thing about it is when it works you get your monitor model string reasonably right, with no dependencies to install, the bad thing is, sometimes the string is partial, incomplete, or gibberish. That fallback may have to go, though strings has worked quite well for years for SysVinit version numbers. But I'm not using strings. Maybe I should try that instead, I was just doing a direct binary perl read of the file.
Note: If the "s-size" refers to the physical size of the monitor, then it's a little off, as mine is about 14.75" x 12". (If that represents some other quantity, please ignore. )
Last edited by JayByrd; 02-12-2022 at 08:38 PM.
Reason: 2nd thoughts.
The terminology is slightly confusing, the 'Screen-1:' item is referring to an X.org 'Screen', that 'screen' is what controls the monitors within it. The dimensions there are what xorg 'thinks' or 'believes' about the space it has to work with, which is composed of one or more monitors, arranged in a rectangular grid, in your case, that grid is composed of one monitor. I have also noticed that xorg considers it's 'screen' to often have slightly different size than the actual monitor screen.
In Xorg, the hierarchy is this, if I get it right:
Display, only 1 > Screens, 1 or more > each screen > monitors, 1 or more.
Some may recall setting up dual monitors as 1 per xorg screen, though that's not common now, very rate I believe.
Wayland has no 'screens', it has a display, which I 'believe' is a 'seat', though I"m not totally sure about that, wayland docs are somewhat dismal and hard to really find clearly stated, that display, or 'seat', again, I may be wrong on the 'seat' thing, but I think that's what it refers to, controls one or more monitors, so they got rid of the 'screen' part of that system in wayland. That part I am sure about because I saw that documented in black and white.
That is why 'screen' disappears for wayland displays, by the way, and you only get Display: with monitors.
JayByrd, if you install Parse::EDID perl module, you may get a lot more monitor data, unless it has no EDID, then you won't get any more.
the direct cpan way to install modules is:
as root, or sudo:
install make, first of all, make sure you have make on the system
then:
sudo cpan App::cpanminus
then
sudo cpanm Parse::EDID
if it complains about missing local lib, you would need to install that module first:
local::lib
Only do this if Parse::EDID is not packaged,however.
I think if you start out making sure you have make and local::lib installed, the install should 'just work', and I found that each time it failed, it made no difference, I'd install the missing thing, then run the cpanm Parse::EDID again, until it worked.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
)
