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.
Glad I posted the slackbuild then. I was waffling on whether or not to do it, but just goes to show you never know how sharing something useful will spark another idea or pique someones interest to send them down a fruitful path...No matter how small that bit of information was.
It sure makes sense to include it with a script like yours.
So am I, thanks. I actually hadn't even considered looking at the code before, but your packaging script kind of crammed home the point that I was breaking an inxi rule, to require a non core perl module to do standard functions, so after taking a look at the code, and realizing it was license compatible, and 'just worked', with basically no extra work or modifications beyond wrapping it in a class/package, I figured, why not?
There's 2 methods I'm not using, not a lot of lines of code, but if I don't end up using them, I could remove them for another 34 lines since inxi won't need them. One of them might be worth keeping, check_parsed_edid, but it doesn't do that much of interest.
Based on the cpan Parse::EDID changelog, I'd hazard a guess that when inxi ships with this, the userbase of ParseEDID will jump exponentially, probably. I'll email the maintainer just to let him know.
The import of Parse::EDID seems to have gone fine, it's been extended to include vendor 'nice' names, but there is no actual single place I could find that matches those 3 letter vendor codes to the vendor name, all the lists I found are incomplete. But it's not bad from what I can see, tested to make sure no regressions on tinycore, on openbsd, ongoing on wayland fedora gnome and manjaro sway, and it seems ok.
That looks like it completely failed to get any /sys/class/drm monitor data to me. What is:
ls /sys/class/drm
anything?
And:
inxi -Gaz --dbg 44
which will output anything it found, but to me it looks like no drm data was there. What kind of monitor is it?
To me it looks like you had xrandr installed, which did get some basic monitor info, like the dimensions and hz, and all the /sys based monitor data tests failed.
DVI-D-0 looks like an Xorg monitor ID, changed from a kernel ID of DVI-D-1 (kernel stuff seems consistent and well done, numbering starts at 1, always follows same rules for the id construction). The internal mapping rules should have matched those, unless there's an error in the regex.
Just FYI, there's going to be a 3.3.14 reasonably soon, as soon as I see where the display/monitors stuff is failing, already getting random failures from online posts of inxi -Ga data. This was kind of my plan because I could tell I'd exhausted the variations for monitor stuff more or less among testers and my own stuff, this was immediately confirmed on the first outputs posted yesterday and day before. A few corner cases already handled in pinxi, probably within a few days most will be handled I think. Though there's one I'm going to have to try to get data from the guy, his system simply did not find any monitor data at all, that was an amd radeon apu setup, which I'd wondered about in terms of how they show in the system. Still needs more data though. APU showed as Device-1, so it wasn't that, but don't know what the issue there was.
Still missing any complete source for monitor vendor 3 character code IDs, which means any of the less common monitor code > vendor name matches will have to be done empirically, by the person telling me the brand on their monitor, and the manufacturer_name code id they see in -Ga --dbg 44 output. I think to be complete, somewhat, about 20 more will need to be added, after that it gets really obscure. 10 would probably handle most of the more standard ones people actually use that are still missing.
Redoing the ParseEDID stuff, will contact the guy once I have it more or less done and see if he wants any of the changes.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.