Search
288 results for “smxi”
-
Meanwhile, on the #inxi / #pinxi front, all remains peaceful. Issues reported are resolved.
It's lingering in that odd space where not quite enough updates to warrant a new release, so waiting for more to pop up.
I'm calling the long refactor roughly completed with 3.3.33 a win, I'm not hitting code in general that makes me wince, hides issues, or makes logic hard to understand. This was the goal, so looks like a win.
I get slightly nervous when nothing shows up, but that's old habits.
-
A another day in the life for #inxi: Issue 303 on @Codeberg noted #mesa version in #OpenGL was failing on one user's output.
With some good sleuthing (not by me, gfxstrand the OP figured it out), turns out that when mesa is built from git, it added an extra string to end of version number string, which then broke the regex.
While technically working now in #pinxi, I will probably make this pattern less picky in case other weird variants crop up.
Another good cb issue. Not missing #github.
-
Due to an almost overwhelming popular demand (ok ok, a guy asked when I'd release), I grit my teeth, did the last horrifically tedious manual matching tables data updates last night in #pinxi (next #inxi), which always means release is going to be within a day or two.
So this nice collection of corner case fixes will probably go out the door today.
I'm calling it: @Codeberg is working _exactly_ the way I hoped it would. Signal to noise ratio in issues radically higher now than on github.
-
Fixes in #pinxi, con'd
* A big one in #inxi, only didn't show up I think because most distros ship #Xwayland, #Wayland ID always failed without Xwayland because it depended on $DISPLAY, which refers to #X.org display ID, NOT wayland's. $WAYLAND_DISPLAY added, plus some other fallbacks.In a sense, this failure was the largest, but I only found it because I installed #sway and deliberately left off Xwayland to see what I'd really need to install to get stuff running.
2/
-
#inxi update: all in #pinxi now. Nothing very exciting:
* #FreeBSD changes exposed several block device failures, all revolving around not handling /dev/gpt/[device] syntax. Some of these failures are quite obvious, some not as much. Not a big userbase, but it was a good set of bug/issue reports, which is very unusual for the BSDs.
* Adding in some more matching data, gpu vendor IDs, hyprlock, nova #rust #linux #nvidia display driver project.1/
-
@Codeberg so it was with a sigh of relief that I switched all my #github repos to Archived read only status, which has the benefit of also turning off all future pull requests, which you can't disable on gh otherwise. Soimetime in the future I'll start repo by repo removing all the code, and just leaving the README.txt as pointer to the codeberg repo.
This already happened for the inxi-perl branch (#pinxi), docs, tarballs.
So for all practical purposes this frees me from gh and its users.
-
There's going to be a quick new #inxi 3.3.33 release next few days. Currently all running fine in #pinxi. Just need to check man page and docs. New feature -na will show network services/daemons running in advanced network report.
Also a long standing feature request by mrmazda for better error handling of pointless option use.
Added all network services I could find along with documenting each as I added them.
Rushing release due to real bug found and #Ubuntu LTS freeze soon.
-
And with that #inxi 3.3.32 is released. 3 months in the making. Maybe 4k new or changed lines of code. Cleaner. Easier to maintain and add support for software based features like window managers and desktops. Refactors anywhere pain points existed.
Because I had to draw a line there's already some new features coming in next inxi but I couldn't delay release any longer. So will be interesting to see how this does in the wild. #pinxi got as much testing as practical so fingers crossed.
-
After what seems an eternity, and the longest changelog on record I believe, the last pre-release steps are now completed for #inxi 3.3.32 (in #pinxi now). General last steps are updating the manually generated matching tables for cpu microarch, gpu product ids, and drive vendors. None of those are actually available data types, and have to be assembled through manual research and various useful datasources, none of which is complete re the data reports, but which do help.
1/
-
I know this is a long shot: I'm looking for a field name for #pinxi next #inxi Desktop item, which in current inxi is called info:, now repurposed in pinxi to contain random desktop/wm info, like kde framewors+version.
Possible contents are: panels/docks/trays/menus
tools: is used for things like screensaver/lockers.
I've tried a few terms:
comp: [short for components, but could be compositor]
parts: [parts of wm/de, sounds wrong]Best: 2 characters, like tk: wm:, next best 3-5 characters.
-
Wow, between #Slackware (udevadm based RAM report debugging/improvements) and #antiX (desktop/window manager tests and bug finds, and improvements), I lucked out on testing for the #pinxi (next #inxi) 3.3.32 release, I knew there were a lot of issues hidden here and there in both cases, and there were, but it took more eyes than mine to find and fix them.
Requests for testers don't always pan out, but these two certainly did. Of course, my choice of both distro forums was no accident...
-
@drcalambre glad you find #inxi useful.
While the new release (currently running in #pinxi aka next inxi) is taking a long time it's achieving the goals of getting code way more robust internally and making it much easier to maintain long term.
The #antiX people have been finding a lot of minor issues with desktop/window manager handling and once those are solid hoping for release soon. But not while known resolvable issues remain.
Changelog is way too long now...
-
New #inxi 3.3.35 just went out the door. Who will package it first? Me, since I just sent out the #TinyCore package. I decided if I was going to package inxi for TC, I should make sure to release it as soon as the new inxi was pushed to @Codeberg For those wondering, still liking CB, and not missing #github for even a microsecond. CB is everything I hoped it would be. Squeezed in a nice last set of fixes, repos, packages, distro name filter glitch. And of course the #Loongson CPU/GPU stuff..
-
Amazingly, on the rooted #android phone, #pinxi can now also show complete monitor information, aka the screen, which I was really surprised by. I did not expect phone screens to return #EDID data, but they do, at least in this case.
As is often the case, right when I think everything is going to settle down, I get a good issue, a good dataset, or find a key bit of missing info.
Refactoring to handle the port ID mapping was tricky but not too hard Now the old hack is just a fallback.
-
@Rural_Canadian and keep in mind the tools used to make the #chatgpt trash are not fundamentally different from #tesla #FSD beta. Let that sink in. And tesla autopilot far ahead of industry. Which is why #GM' #Cruise just lost license to operate in California. And #Twitrer can't detect bots using their AI (sic). Neither can #google or its #gmail. Or #facebook. Easiest pattern type to match and fails. Those are biggest ai (sic) firms out there. Pattern matching good though.
-
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.
-
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.
-
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.
-
...
But this was still a good opportunity to re-examine the #mp3 tagging logic in #acxi, which I did, and expanded it quite a bit. It's actually quite difficult to see how an organization like #frauenhofer could have done such an awful job with their various tag specs, but they did.Another reason why I urge people to kick the non free audio #codec habit, and go with free top to bottom: #flac > #opus/#ogg, but opus is preferred because ogg is not really being developed much, and lacks features.
-
Extending #inxi / #pinxi distro ID, this time for system base and derived for #devuan, and some more #slackware based ones, like #slackel. Also got #debian/devuan version ID for #peppermint working.
These require installing a vm and then getting the data to match for the ids, sadly there is not, and never will be, a reliable way to both detect derived distros always, and their system bases. /etc/os-release was just not designed correctly, so now we have the dreaded yet another standard...
-
@SpaceLifeForm Like the part of me that really gets excited about new #riscv developments, or #jimkeller talks, or the wild ride that happens if you can get the #slackware community excited about some feature in #inxi that they care about, like cpus. Or the #AntiX people about stuff they care about, like light window managers, screensaver/lockers, etc.
That stuff just does not map at all to non tech types. Nor should it.
-
@SpaceLifeForm Like the part of me that really gets excited about new #riscv developments, or #jimkeller talks, or the wild ride that happens if you can get the #slackware community excited about some feature in #inxi that they care about, like cpus. Or the #AntiX people about stuff they care about, like light window managers, screensaver/lockers, etc.
That stuff just does not map at all to non tech types. Nor should it.
-
@SpaceLifeForm Like the part of me that really gets excited about new #riscv developments, or #jimkeller talks, or the wild ride that happens if you can get the #slackware community excited about some feature in #inxi that they care about, like cpus. Or the #AntiX people about stuff they care about, like light window managers, screensaver/lockers, etc.
That stuff just does not map at all to non tech types. Nor should it.
-
@SpaceLifeForm Like the part of me that really gets excited about new #riscv developments, or #jimkeller talks, or the wild ride that happens if you can get the #slackware community excited about some feature in #inxi that they care about, like cpus. Or the #AntiX people about stuff they care about, like light window managers, screensaver/lockers, etc.
That stuff just does not map at all to non tech types. Nor should it.
-
@RL_Dane @mjgardner @benjaminhollon Tridge is the man, for sure, rsync is a masterpiece, one of my very favorite CLI tools. I have real doubts about anyone doing better in a clean room type rewrite, but I also have doubts the #OpenBSD #openrsync replacement author isn't peeking now and then. Not a criticism, but sometimes you have to cheat just a bit, lol. Though OBSD have great developers, top notch, they solve problems with tiny group (50 devs?) billion dollar companies can't solve.
-
@Anarcat The #wayland protocol devs should step up and thank #sway developers, who did not need to do the extra work to create wlroots wayland library, which has largely saved the entire wayland ecosystem and allowed it to have a chance. @xfce for example in 4.19 I believe is using wlroots in #xfwm4 if I'm not mistaken. But it still leaves 6 primary compositor libraries to deal with, plus any number of minor ones.
I honestly don't know where we'd be if it were not for the work of #sway
11/ -
Some nice datasets and issues for #inxi - Got a rooted #Android dataset, and realized I can detect the #SurfaceFlinger compositor and thus show some data for Display: Also, the recent #Vulkan API upgrade works on android in #termux if you install the vulkan-tools package. Also fixed some partition stuff.
Even better, and also now running in #pinxi is finally finding a way to lock down #DRM vs #Xorg port ID string mapping without using hacks. Works on all DRM driver + #xrandr situations.
-
@jasonkoebler Apple's "Genius" support at their stores is equally silly, as #LouisRossman has repeatedly observed in his apple repair videos. The skill required to do this type of work requires far higher income than these corporatiosn would pay, thus the service they offer cannot be real except for lowest set of problems, or just saying, oh, you need a full board replacement (when a transistor has failed). #Geeksquad was never real to me, it was not possible to do what they claimed to do.
-
@vermaden I read that study a few days ago, it was interesting, and roughly mapped 1 to 1 with my experiences trying to support #wayland in #inxi. With this said, I'm happy to leave this initial forced use test to the enterprise ibm-rhel/fedora based distros.
I much prefer the @xfce strategy of: once we have everything feature complete, we'll add wayland suppport (currently ongoing in 4.19 https://debugpointnews.com/xfce-wayland-update-2023/ for progress).
#TheoDeRaadt's comments on wayland were interesting as well..
-
#damentz of #Liquorix kernel found a weak spot in #inxi's screen resolution handling. When display scaling is used, inxi fails to show both the physical and the logical pixel sizes per monitor/display, and instead shows only the logical. And no scaling. Internally there is a weak attempt to store this data as two items, but it's not used correctly. The desired output will be similar to physical and logical block sizes for drives. Physical used to equal logical so inxi reflects that history.