Accelerometer now works on my machine, thanks!
Maybe next time you could also consider enabling all accelerometers, not just mine, like you enabled all light sensors?

Small changes as for joebonrichie suggestion

Bring back some necessary sed commands as they are needed to fix tests, replace some with a patch from Gentoo

Remove sed commands leftover from package of 5.1.3 and 5.2.3, switch off reorg backward compatibility to remove redundant header file, add patch for Blender

Cleaner patch found by GZ

Add GZGavinZhao to MAINTAINERS.md

Add GZGavinZhao to MAINTAINERS.md

Add GZGavinZhao to MAINTAINERS.md

Thank you so much @Staudey ! When I was first testing it 4 years ago it really improved things a lot, I hope it will do the same today.

Looking good for me too. I mean it is exactly as buggy as it was on the previous kernel, it is just a problematic laptop.

            -```````````                  jacek@chujwijacka 
          `-+/------------.`              ----------------- 
       .---:mNo---------------.           OS: Solus x86_64 
     .-----yMMMy:---------------.         Host: MiniBook X 
   `------oMMMMMm/----------------`       Kernel: 6.1.0-22.next 
  .------/MMMMMMMN+----------------.      Uptime: 3 hours, 43 mins 
 .------/NMMMMMMMMm-+/--------------.     Packages: 1129 (eopkg), 7 (snap) 
`------/NMMMMMMMMMN-:mh/-------------`    Shell: fish 3.5.1 
.-----/NMMMMMMMMMMM:-+MMd//oso/:-----.    Resolution: 1600x2560 
-----/NMMMMMMMMMMMM+--mMMMh::smMmyo:--    DE: Plasma 5.26.4 
----+NMMMMMMMMMMMMMo--yMMMMNo-:yMMMMd/.   WM: kwin 
.--oMMMMMMMMMMMMMMMy--yMMMMMMh:-yMMMy-`   Theme: Solus Dark [Plasma], Breeze [GTK3] 
`-sMMMMMMMMMMMMMMMMh--dMMMMMMMd:/Ny+y.    Icons: Papirus-Dark [Plasma], Papirus-Dark [GTK2/3] 
`-/+osyhhdmmNNMMMMMm-/MMMMMMMmh+/ohm+     Terminal: yakuake 
  .------------:://+-/++++++oshddys:      CPU: Intel Celeron N5100 (4) @ 2.800GHz 
   -hhhhyyyyyyyyyyyhhhhddddhysssso-       GPU: Intel JasperLake [UHD Graphics] 
    `:ossssssyysssssssssssssssso:`        Memory: 3301MiB / 11712MiB 
      `:+ssssssssssssssssssss+-
         `-/+ssssssssssso+/-`                                     
              `.-----..`

What do you thing of also including this change? https://www.phoronix.com/news/Linux-Splitlock-Hurts-Gaming Or just wait for 6.2?
Also, thank you so much for such quick kernel update, and including those additional patches!

If the new ISO will include Mesa 22.3, then the Rusticl included in Mesa might be better than one included in ROCm. Certainly it supports much higher OpenCL version and more GPUs, only performance will need to be checked.

On my Chuwi Minibook X, based on Intel reference boar, with Jasper Lake Celeron N5100 I got no problems, as well as some driver problems got fixed. Power consumption improved considerably, but also the performance is lower, they must have tuned the governor. WiFi and BT headphones work just fine with Intel AX201.
Same on my Zen+ PC with B 450 chipset and RX 480

I suggest you could try switching to Pipewire, which fixed a ton of Bluetooth problems for me https://discuss.getsol.us/d/7528-is-pipewire-not-fully-supported-on-solus/20
After you do it, you will see much more available codecs, hope it will fix the microphone too.
Did you also try switching to LTS kernel, did the microphone work there?

@ZenurikSD I tested it again on KDE Wayland, the newest 0.15.0, and it still complains it is missing specifically wlroots stuff. So I think it is worth consulting devs if it can actually fully work on other Wayland compositors than Sway, or only with KMS.

Update to 0.15.0 and update instructions accordingly

@ZenurikSD Awesome, that means there is probably nothing wrong with this build.
You can download the .eopkg from here: https://send.vis.ee/download/a7836816afd78baa/#RzuiSW2VOzVUZB9zs8ocGA
And make sure to move your config as I described in the description of this diff, at the top of the page.

Clean up the package.yml

@ZenurikSD I build it again, and it definitely builds with support for wayland: -- Found Wayland: /usr/lib64/libwayland-client.so;/usr/lib64/libwayland-server.so;/usr/lib64/libwayland-egl.so;/usr/lib64/libwayland-cursor.so
So I don't know how can I fix it.
Oh, and one more thing, you build this package.yml, right? Just making sure, because the build currently in the repos is an ancient 0.10.1, this revision 0.14.1 didn't get accepted yet. So you build the new version posted here yourself and it didn't work, right?

In D13464#234487, @ZenurikSD wrote:

Hello!

Just wanted to report that this package does not work correctly under Wayland because of a build issue. It does not find a wayland display and instead uses X11 to screenshare.

@joebonrichie @GZGavinZhao You guys are amazing! Thank you so much for fixing it so quickly, while I was sleeping ;) And yes, rocm-opencl works just fine, and I can build rocBLAS with rocm-hip, so this seems to be working just fine too. Thanks for your amazing job!

In D13464#232092, @algent wrote:

In D13464#230688, @Jacek wrote:

They changed the config file location, so users will need to manually move them, or configure it again. I don't see an easy way to patch it.

Moving files from /etc to /usr/share will be reported by eopkg as a broken package.

In D13126#231434, @joebonrichie wrote:

Built this locally the other day and found out solbuild supports file:// URIs no problem. e.g. file:///home/foo/solus/dart/dartlang-2.17.6.tar.zst

Nobara integrates this and a better vaapi support into the main package, maybe we could do the same?

They changed the config file location, so users will need to manually move them, or configure it again. I don't see an easy way to patch it.

Remove one argument that is no longer needed

I think what could be the problem for you is this: https://github.com/intel/intel-vaapi-driver/issues/533
With a Mesa update your GPU is no longer using the old Intel driver, but Crocus - new Intel driver adapted for old GPUs. And the libva-intel-driver version we have in the repos doesn't include support for it.
So either you could maybe try the workaround they posted, or someone could patch the driver with that one commit.

Unfortunately you GPU is super old and no longer supported by intel-media-driver https://github.com/intel/media-driver#supported-platforms
[[ https://github.com/intel/media-driver/issues/1288#issuecomment-968441652 | Here they suggested using intel-vaapi-driver instead ]].
Could you install libva-intel-driver and try again?

Could you post here your system specs? It is working fine on both my old Intel (Broadwell) and AMD system.

Have you tried manual partitioning? I found once I manually created /, swap and boot partitions like in the helpcenter docs, rebooted, it detected the new partition nicely.
https://getsol.us/articles/installation/disks/en/

In D13172#228658, @joebonrichie wrote:

Can you update the test plan? Either with an application or you could consider converting this cuda sample to hip for example https://github.com/ROCm-Developer-Tools/HIP/tree/develop/samples/0_Intro/square

Remove unnecessary textfiles

So I think when it can't mach the set of characters it must be falling back to some other driver, maybe LLVMPipe? So clearly Intel video drivers, both for new GPUs and the old ones are the problem. Could any of you report that on Gnome callendar's bug tracker, or maybe even Mesa bugtracker?

Well, the solution is to build i915 again for now on Solus side, and report this issue upstream, on Mesa or gnome calendar bugtracker.

Don't specify for which architecture to build

Remove specifying for which architectures to build, seems to not be necessary

Funny, ZIG has just fixed compatibility with LLVM 14... Only thing needed would be to backport those patches.

@moriel5 If you want to see something like a Budgie Calendar, you would need to report it at Budgie's bugtracker, not here.
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.

I have updated all of it to 5.1.3, which is the newest version we can use with LLVM 14, and 5.2 doesn't build with it and will probably require LLVM 15.
After the changes I made to rocm-hip and finally managing to build a package depending on it I am confident in the whole stack and I hope it can land once LLVM gets updated to 14, and solbuild gets updated to latest git.

Update to 5.1.3, remove use of __noinline__ which broke compatibility with newer GCC

Update to 5.1.3

Update to 5.1.3

Update to 5.1.3

Update to 5.1.3

Update to 5.1.3

Update to 5.1.3

@DataDrake Then probably this can be closed now, if you think LSI should keep going how it is, and this topic can be reassessed if anything changes in the future?

Make hip build use static rocclr
This means I have to include all the patches and sources of -opencl, but there is no other way until upstream changes its approach

Remove the patches allowing to split rocclr into separate package
Unfortunately it means that the hip build will have to contain all the sources of -opencl, and all the patches, but standalone build was abandoned by AMD employee maintaining for Fedora, so better roll back too.

It is also useful to do sudo eopkg check when an app fails, and do sudo eopkg it --reinstall {appname} if any shows up as broken.

I think the main problem is that there are 2 blacklists now. One done by Valve, where they learn about problems first, and then one in LSI, where we only learn it when someone runs into an issue.
So I think all we could do is find where that blacklist is in https://gitlab.steamos.cloud/steamrt/steam-runtime-tools and monitor it. Then it would be much easier to troubleshoot and understand what Valve is trying to do. And then LSI can live on.
I think the blacklist here, separate depending on which runtime a game is using (scout, soldier or in the future sniper): https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/master/tests/pressure-vessel/inside-runtime.py#L691 and https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/master/tests/pressure-vessel/containers.py#L937

Also, on Discord's Github it seems they finally started work on using newer Electron version, so hopefully they will update it in their client soon, and it might fix some of the issues.