I have absolutely no idea how this happened, however after my system failed to show anything with graphics (no crashes, just graceful termination of LightDM and XServer, with no explanation why), and reinstallation of quite a few packages (and reverting manual changes meant to enable Intel triple buffering X11-wide), suddenly my AX210 is working without any issues with Linux 5.15, and even Bluetooth LE is working perfectly.

In T2532#197369, @joebonrichie wrote:

Let's get all the packaging stuff landed (at least with the patches on phab) then we can figure out how to integrate it into the upgrade process. Consider the packaging progress part up for grabs.

Thanks, I'll add it's changelog soon.
But we really need to get this sorted out as soon as possible, since currently we have broken hardware with the current Solus defaults due to this,

I had just tested this on my sister's laptop (Celeron N2840, 2GB DDR3L@1333Mhz, 16GB eMMC), and I saw no perceivable real world difference, although all I did to test this was running YouTube videos at 720p, 1080p, 720p60, and 1080p60 via Piped with H.264 as the only enabled codec (only way to watch YouTube videos nowadays at above 360p without heavy chopping, interestingly, 1080p60 was almost viewable this way, despite the CPU supposed to not be able to cope with the strain of streaming something like that at all) and going through the file manager (Nautilus, this is on a Budgie DE).

It appears that linux-firmware is woefully out of date, which coupled with Intel's firmware update cadence shenanigans, could be the reason for the AX210 not working at all on Solus, starting with Linux 5.15.

I can also confirm that none of our devices at home had any regressions with this update.

In T10302#196781, @d0nj0w wrote:

Hi guys,
sorry for not having reported such a long time. But, I resumed my investigation today and may have found something. @Jacek said

In T10302#196719, @Jacek wrote:

Could it be that on newer Intel graphics using "Iris" driver (Broadwell 5th-gen and up) it works, but this bug only concerns the old i915 driver? Maybe Mesa update to 22.0.5 fixed it for newer processors but not the older?

I found that very interesting and tried some of the mesa parameters for the userspace driver like

MESA_LOADER_DRIVER_OVERRIDE=iris gnome-control-center

Surprisingly this gives me a running gnome-control-center and no segfault (no matter if I put "iris" or some random other text there). So I checked the mesa driver folder befor

ls /usr/lib64/dri/
i830_dri.so            kms_swrast_dri.so      r200_dri.so            radeon_dri.so          virtio_gpu_dri.so
i915_dri.so            nouveau_dri.so         r300_dri.so            radeonsi_dri.so        vmwgfx_dri.so
i965_dri.so            nouveau_drv_video.so   r600_dri.so            radeonsi_drv_video.so  
iris_dri.so            nouveau_vieux_dri.so   r600_drv_video.so      swrast_dri.so

and after the libmesa update

ls /usr/lib64/dri/
crocus_dri.so          nouveau_dri.so         r600_dri.so            radeonsi_drv_video.so  vmwgfx_dri.so
iris_dri.so            nouveau_drv_video.so   r600_drv_video.so      swrast_dri.so          
kms_swrast_dri.so      r300_dri.so            radeonsi_dri.so        virtio_gpu_dri.so

Looks like the old i915, i965, ... drivers have been deleted or better replaced by crocus_dri.so. And guess what gives me the segfault again

MESA_LOADER_DRIVER_OVERRIDE=crocus gnome-control-center

So crocus doesn't work for older Intel integrated GPUs like my HD3000 obviously. But I'm running out of ideas what would be the right fix or if there's any.

It appears that this software is active nowadays, with the latest version, 2.8.0 having been released on April 22, 2022, and the latest commit to master being 5 hours ago (and I can see that it was certainly active during the past few months).

In T10302#196728, @toudi wrote:

@moriel5 : I did the procedure you wrote about:

sudo eopkg check | grep Broken
Checking integrity of pysolfc-cardsets                               Broken

so doesn't seem to be the issue

Hmm... It would certainly seem like that.

as for gnome-calendar not being dark, you need to set it in gnome-control-center (as opposed to budgie-control-center). the calendar still won't match the system dark theme but at least it will be dark ;-) as I understand it, it has something to do with the fact that gnome 42 completely blocked user themes.

I'm not a dark theme user, however I use the Arc theme that used to be the default on Linux, and yes, it is due to GNOME devs trying to pull an Apple (you the user do not get to choose what is enjoyable to you, only we, the devs, get to choose for you).

Just for reference, I'm pasting info about my system here:

grep 'model name' /proc/cpuinfo  | head -1
model name	: Intel(R) Core(TM) i3-10100 CPU @ 3.60GHz
lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation CometLake-S GT2 [UHD Graphics 630] (rev 03)
lsmod | grep "kms\|drm"
drm_vram_helper        24576  1 vboxvideo
drm_ttm_helper         16384  2 drm_vram_helper,vboxvideo
ttm                    77824  3 drm_vram_helper,drm_ttm_helper,i915
drm_kms_helper        319488  3 drm_vram_helper,vboxvideo,i915
syscopyarea            16384  1 drm_kms_helper
sysfillrect            16384  1 drm_kms_helper
sysimgblt              16384  1 drm_kms_helper
fb_sys_fops            16384  1 drm_kms_helper
cec                    61440  2 drm_kms_helper,i915
drm                   651264  12 drm_kms_helper,drm_vram_helper,vboxvideo,drm_ttm_helper,i915,ttm
glxinfo | grep -i "vendor\|rendering"
direct rendering: Yes
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
    Vendor: Intel (0x8086)
OpenGL vendor string: Intel
grep LoadModule /var/log/Xorg.0.log
[     2.675] (II) LoadModule: "glx"
[     2.694] (II) LoadModule: "modesetting"
[     2.699] (II) LoadModule: "fbdev"
[     2.700] (II) LoadModule: "vesa"
[     2.707] (II) LoadModule: "fbdevhw"
[     2.708] (II) LoadModule: "glamoregl"
[     3.123] (II) LoadModule: "fb"
[     3.308] (II) LoadModule: "libinput"

and again, last lines from the gdb run:

gdb gnome-calendar
Reading symbols from gnome-calendar...
Reading symbols from /usr/lib64/debug/.build-id/7d/5cabfcbfa0e08263fbdd767ec1330902b0acd8.debug...
(gdb) run
( ... )
Thread 1 "gnome-calendar" received signal SIGSEGV, Segmentation fault.
0x00007fffc1cf15b7 in ?? () from /usr/lib64/dri/iris_dri.so

I have then installed dbginfo for mesalib (sudo eopkg it mesalib-dbginfo) and rebooted the machine, however it still doesn't show me what function is exploding

In T10302#196719, @Jacek wrote:

@moriel5 If you want to see something like a Budgie Calendar, you would need to report it at Budgie's bugtracker, not here.

True, I had simply pointed this out.

Also, they did run sudo eopkg check already, this problem is not due to broken packages. But it really is weird that on your Intel machine it is working.
Could it be that on newer Intel graphics using "Iris" driver (Broadwell 5th-gen and up) it works, but this bug only concerns the old i915 driver? Maybe Mesa update to 22.0.5 fixed it for newer processors but not the older? If that is true, then switching to "Crocus" driver on older processors would fix it, as it uses newer driver code.

That is certainly possible, and would be backed up by the fact that it runs without any issues on my sister's BayTrail-laptop, which relies on Crocus.

I had unfortunately missed last week's sync on my laptop (my previous report was from my desktop, where I am using an AMD dGPU, and I did not have time to test until now), however I did not install the .eopkg from the Googler Drive link.

It appears that I really do need to build the package after adhering to proper packaging habits, not before with a standalone package.yml. That has been fixed now.

I believe I did, but just in case I didn't, I'll do so again.

Thanks, I didn't realize that the differential itself did not get updated (and I have no idea why not) with the new commit.

Due to me forgetting how to use Git, the accompanying files were missing, that has been fixed now.
Also, the lines were cut off, because I copied them over from and back to nano without realizing the ramifications, so I recopied the lines.

1. Thanks, I'll do so immediately.
2. No, I first copied them over from Firefox, but then realized that I was in the Git commit, so then copied... That must have been the issue, me copying the lines from Nano (to GEdit, and then back).

In D13324#227986, @Staudey wrote:

Two small-ish things:

1. Seems like you didn't include the changes to abi_symbols, abi_used_symbols and pspec_x86_64.xml in your commit/diff.
2. Your changelog and summary seem to be cut off at the right side for some lines ^^

And sent differential D13324.

Currently OTPClient is packaged in the Solus repositories.

I'm still trying to get to the root of this, however it seems that there is an issue compiling the x86-64 crosschain for GCC 8 (no idea why this is what is needed for Coreboot, at least the Dasharo implementation for the Optiplex 7010/9010) that comes from the gcc-ada headers.

I can confirm that GNOME Calendar works as expected (not very well, however that is due to GNOME devs' stance in regards to libadwaita and GTK4) here, and I am on a fully updated build here with the Shannon channel as well.

Also, it might be time for this issue to be closed, since I do not think that there are any regressions as a result of crocus being enabled by default at this time, although those more knowledgeable than me should make that decision.

Something seems off.

Bluetooth LE is working without any issues with my AX200 on Linux 5.15, as evidenced from my desktop with the same mouse.

This is a separate issue, however it appears that under Linux 5.14, Bluetooth LE does not appear to be working on the AX210.

Sorry about the delay, I finally caught up.

Yikes, I had completely forgotten about this.

It appears that gucharmap needs to be installed for the plugin to work-properly.

I am not sure what was the cause, however at a certain point the entire system started lagging (starting with the mouse), however a reboot not only fixed that, but also MediaInfo's slow startup.

The update to vala-panel-appmenu does not appear to have fixed MediaInfo's launch time for me.

Sorry it took so long, however here is the screenshot (taken ages ago):

@serebit @JoshStrobl It's fine, no need to be sorry.
I was expecting this, it was more of a last ditch effort in case there was anything that could be done in the interim until I have the budget for at least something 2nd hand that would would work properly, even if basically, with OpenCL (in this case, an example would be a Sapphire Radeon HD 7700 Ghz Edition (GCN1.0) that my friend has at his repair shop, which unless someone else will need specifically that card (there are lots of old NVidia cards there that are more suited for his customers, which only need enough graphics power for 1080p (some only need 720p) on YouTube) my friend is keeping for me for when I have the budget (around the equivalent of ~70$)). My budget is first aimed towards a new motherboard, however, before my current one breathes it's last breath.

I'm sorry I hadn't realized that I hadn't answered the question.
Currently, my main usecase is cRARk, partly for testing it's reliability, however once I have OpenCL running reliably, I intend to expand that to whatever tasks I have at hand that require OpenCL (lack of a proper environment is one of the main reasons why I cannot start utilizing anything that requires compute (another reason is lack of a budget for a full upgrade, especially with something that is not 2nd hand)).

As mentioned, I have a Haswell CPU, which isn't supported by intel-compute-runtime (with clinfo not even showing any platforms whatsoever with it).

I'm really sorry about my utterly long disappearance. My hands have long since recovered (thank you for your comment @serebit), however I had no access to my desktop (and I still have not gotten the heatsink I was supposed to get together with my laptop's new motherboard (iGPU to iGPU+dGPU), so still no working laptop) until now.

I'm sorry about how late I am returning to this issue, I got my hands injured last week carrying bricks.

My sister's laptop:
Removing TLP had absolutely no effect on performance, still as sluggish as ever.
However I had remembered schedutil, after following it's progress for the past year or two (I forget how long), so I reinstalled TLP and set schedutil, and the performance issues are gone.

Aye, on both. However as of yet, it has only aided performance' which is why it has not crossed my mind.
I'll test without it, and return with results.

Additional testing shows a ~50-66% graphical performance hit on my desktop with 5.10, depending on usecase.
My desktop is simply powerful enough, with me mainly relying on nongraphical performance, that I did not notice the eventual hit there.

In T9379#178728, @Jacalz wrote:

I updated to latest unstable and almost everything is working fine, except for one issue with the budgie application menu (sorry if that's not the correct name).
If I press it just after the desktop has just appeared after a computer restart, it shows up too high up and does not respond to clicks:
In all other situations, it works just fine.

! In T9379#178637, @JoshStrobl wrote:
Random locations

Thanks, will it be feasible to add an option to reorganize the icons, without allowing them to be placed wherever?

It's not a perfect calculation, it's an estimate. I'm using static values for the items since getting the calculated heights and widths of items added (which is something I did at the beginning) introduced inconsistencies due to how delayed Gtk can be at allocating and the allocation being inconsistent itself.

Ah, then I guess that this will take time, and is low priority.
In any case, it could be argued that this is much better in some ways than the previous implementation (though I do feel it to be a bit lacking, since I make heavy usage of the desktop).

No it isn't. The icon heights are different and your second column first item has a label that wraps onto the second line, and the label height is variable depending on if its one or two lines. The icons center themselves in whatever internal container GtkImage uses for it.

Thanks for the explanation. In my opinion, it is still not as it should, however understand that this is due to GTK limitations.
Any plans for icon size standardization? That may help out.

There are multiple reports of crashes and SIGABRT for gthumb. See their issue tracker.

Thanks, I shall look into it.

@JoshStrobl By "arbitrary", do you mean random locations on the desktop, that are not aligned to a grid, or anywhere on the desktop, but aligned to a grid, or perhaps even reorganizing the icons?

My freezes certainly have not returned, though now I have issues of a different sort (the PC freezing, outright crashing, and then rebooting), which I suspect are down to failing hardware (probably my dGPU, as no matter what I do, including cleaning the card, and replacing the thermal paste, it idles at ~70 degrees celsius, and rises to 80+ under extended load, though it could also be the board, since Asrock's 9-series boards are known to be unstable).

This could be an issue, since from my experience speaking with the Lollypop developer (on completely unrelated bugs), I saw that Lollypop now requires libhandy, which is against policy on Solus, so it will need to be possible to compile Lollypop without libhandy.

Thanks, when I had attempted to test updating it myself, I got an error that I was not the owner (even though all I had done after modifying the package.yml was run "make", so I thought that @JoshStrobl needs to be the one updating it.

In T9252#176857, @hyphens wrote:

maybe try the -lts kernel? that worked for me: https://discuss.getsol.us/d/5518-can-t-run-away-from-freezes-forever/8

In T9252#176731, @JoshStrobl wrote:

Update: I am now seeing these issues also on 5.7.10, though a lot less often than on 5.6.19.

We don't have the 5.7 kernel as our current kernel, so I have no idea what you're talking about. That was reverted clear back in July. Your issue is not related. The first issue by @endumiuz is a CPU soft lock, there isn't really any information on it, we'd need to see if it's resolved with newer kernels when we finally upgrade to that (blocked by NVMe issues). The second issue presented by @endumiuz is, at first glance, related to a bug in Dash to Dock extension for GNOME Shell, so I would suggest they ensure they're using the default settings since they shouldn't be getting any sort if "infinite recursion" issues.

For whatever reason, I can set my laptop monitor's refresh rate to 120Hz when set below the native resolution, even though it's EDID does not list 120Hz as an option.
Could this perhaps be related?

An update on this.

Update: I am now seeing these issues also on 5.7.10, though a lot less often than on 5.6.19.

I can confirm that this is also happening to me, with a slight variation.
For me, it is only the graphics and keyboard input actions that freeze (I can toggle Num/Caps lock), on both my desktop and my laptop (recently upgraded with a new Barracuda Pro).
Additionally, the screen keeps flickering on Intel graphics.

Certainly interesting, I wonder how this stacks up to Clear Sans, especially with RTL languages.

In T8904#171584, @juliocormor wrote:

In T8904#171295, @moriel5 wrote:

@juliocormor With pleasure. I hope your issue will get resolved, though.

I'm home and trying to test your solution. I'm not sure what do you mean with "refresh XRandr's information via radeon-profile". I have radeon-profile installed but i can't find any options to do that?
Also, I think on the distros the second screen worked were using the modesetting driver for the iGPU, while in Solus the system it's using Intel driver. I have read about how to change it but I'm not sure how. If someone helps me change drivers I think the issue is solved.

That is a problem. Noted.

@juliocormor With pleasure. I hope your issue will get resolved, though.

@Darius I'm not ruling out the drivers being out of date, that happens all too often with new AMD hardware, however I said that the ISO may be corrupt, which means that no matter how many times you reflash it, you will have problems, and the only recourse is to delete it, and download it again (that was what I had to do in my case).

Thanks.

Rather late, however I had a similar issue on my desktop (not at home for the time being, and will need to repair the hard drive when I return, so no way to test anything), however by simply refreshing XRandr's information (via radeon-profile), my TV (old, low-end, with bloated capacitors, 42" 1080p non-smart TV that I got from a friend that was throwing it out after replacing it with a 4K smart TV) was instantly picked up, though I had to due this each time I connected or disconnected it to my Radeon HD6950.

I remember when I had issues installing Solus in the past, and I forget who suggested this to me (probably via IRC, since I cannot find this on the Phabricator) (I think it was either Ikey, Josh, or Drake), however perhaps your installation media got corrupted (that's what happened to me)?

This issue can be closed for now, since the current drivers lack support for UVP (more reverse engineering will need to be done with Microsoft's proprietary protocols).

Update: I have managed to get networking to work via the chroot, and update the system, however there is no change unfortunately.

I seem to have gotten myself into this predicament now, however after attempting to fix it via the means outlined in the Solus Help Center (except for updating the system, as it was already mostly up-to-date (just plasma-desktop-branding not being in the index, and I do not have that installed in any case), plus I was unable to get networking to work inside the chroot), I had managed to fix the Systemd errors, however not the fact that the system is unable to switch-root.

Now, ever since I had updated my desktop, the same thing is happening there.

This is weird, but at least things appear to be working.

Thanks, I'll take a look at them.
Update: I do not see any firmware updates for the 9260, unfortunately.

@aquasp Thanks, it appears I also had that installed.
Back when I had initially set up Solus, I installed this to provide additional codec coverage, however looking at the Arch Wiki page, it is pretty much irrelevant unless you are using Nouveau on NVidia's 900-series or newer cards, and even then, it only appears to support decoding (plus, no support by either Firefox or Chromium).
Otherwise, everything it supports seems to be supported by VA-API and/or NVidia's proprietary driver.

Sure thing:

I intend to try maintaining this package.
I'll reopen this issue if I see that I could reasonably do so.

Thanks, I was concerned whether Srain would be added due to some if it's shortcomings (which will probably be fixed), however I see we were of the same mind on this.

Added abi_symbols

@joebonrichie From what I can see from the patch notes, it looks to be pre-Gen4 graphics.

This is weird, I had noticed that lately my laptop's time and date isn't syncing for whatever reason, and I am getting the issue from time-admin brings me the same message, while gnome-control-center simply does nothing at all.

In D8295#133667, @DataDrake wrote:

In D8295#133050, @moriel5 wrote:

That's odd, abi_symbols wasn't added.

It did when I built it locally just now. Did you forget to git add?

@aquasp Yes, I do (both actually, the 32-bit package for Wine support), as well as the others (though these are more for cases where I need to boot from another PC).

Extremely late update, since I had forgotten all about it, and I'm usually not at home.
My fake "7570" has apparently gotten damaged at the same time as my DH55HC motherboard (thankfully it was just the RTC chip (on the DH55HC), and I got a new one of the same model, however I still need to find someone that will be able to help me replace it).
It still works, but not very well, with VGA having limited resolutions (up to something like 1366x768p), and ignoring the actual monitor's settings, and DVI getting a black screen, no idea about HDMI.

@DataDrake Then in that case, I'll check whether this solves the "blank screen on wake" issue that's been plaguing every PC using Intel graphics (everywhere from i3-540 to i5-6200U, including a BayTrail Celeron and an i3-3220) I had installed Solus on since kernel ~4.19 (granted, it happens much less often, and is a minor issue since I just need to switch TTYs, but it still happens,and the less bugs, the better).