Rebase to SteamOS 3.5 packages

[LukeShortCloud]

This may end up being a winesapOS 3.3.0-rc0 release goal depending on when Valve stabilizes the release.

[LukeShortCloud]

I just synced up the source code for SteamOS 3.4.4 to GitHub. Here are the versions for the relevant major packages we ship:

• linux-steamos = 5.13.0-valve37
• mesa-steamos = 22.2.0.157821.radeonsi_3.4.0_2

[LukeShortCloud]

As of today, SteamOS 3.4 Mesa now fails to build on Arch Linux. Interestingly enough, the 32-bit version builds fine.

[2396/2407] Linking target src/gallium/targets/d3dadapter9/d3dadapter9.so.1.0.0
In member function ‘__ct ’,
    inlined from ‘convertToSSA’ at ../steamos-jupiter-mesa/src/nouveau/codegen/nv50_ir_ssa.cpp:401:26,
    inlined from ‘convertToSSA’ at ../steamos-jupiter-mesa/src/nouveau/codegen/nv50_ir_ssa.cpp:310:28,
    inlined from ‘nv50_ir_generate_code’ at ../steamos-jupiter-mesa/src/nouveau/codegen/nv50_ir.cpp:1331:22:
../steamos-jupiter-mesa/src/nouveau/codegen/nv50_ir_ssa.cpp:407:48: warning: argument 1 value ‘18446744073709551615’ 
exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=]
  407 |    stack = new Stack[func->allLValues.getSize()];
      |                                                ^
/usr/include/c++/13.2.1/new: In function ‘nv50_ir_generate_code’:
/usr/include/c++/13.2.1/new:128:26: note: in a call to allocation function ‘operator new []’ declared here
  128 | _GLIBCXX_NODISCARD void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc)
      |                          ^
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in build().
    Aborting...

We're still waiting on Valve to release SteamOS 3.5.

[LukeShortCloud]

With the Steam Deck OLED announced to be launching next week, I suspect that SteamOS 3.5 with its improved HDR and color support to be releasing to the stable update branch soon.

[LukeShortCloud]

SteamOS 3.5 is now stable!

https://store.steampowered.com/news/app/1675200/view/5484882897552407488

[LukeShortCloud]

winesapOS 3.4.0 will be deprecating SteamOS packages. More specifically, linux-steamos and mesa-steamos will be removed in a future release. The most popular package of mine from the AUR, by far, that people actually use is plasma5-themes-vapor-steamos. I will continue to maintain that KDE Plasma theme on the AUR but we will switch to a different theme.

It is very time consuming and complicated to keep rebasing these packages. I have been the only maintainer of it for the past 1.5 years. Most of the changes in those projects are already upstream now. Using vanilla Arch Linux or Manjaro packages has proven to be a much more stable and smoother experience for winesapOS. A common misconception is that other distributions out there such as ChimeraOS and HoloISO primarily use SteamOS packages but they actually use upstream or their own independent packages for the kernel, Mesa, and many other important services.

The biggest missing feature in upstream packages is HDR support. For those who want this feature, I am considering shipping the linux-hdr kernel for that. I also expect to have working OLED Steam Deck support in winesapOS 3.5.0 based on community patches for sound and Wi-Fi support.

Working with SteamOS packages has been a one way straight. Valve's concern has always been that adding new features from us and other community projects may break their Steam Deck support. I hope that with the OLED Steam Deck out of the way, and Valve's plans to release SteamOS to the public in 2024, that there are can more room for collaboration. Valve remains one of my favorite companies and I cannot thank them enough for their contributions to the Linux gaming ecosystem!

Either way, I want winesapOS to stand on its own as a unique gaming distro and not simply appear as ripping off packages from Valve. Most people do not know this but winesapOS has existed long before the Arch-based SteamOS 3 was released alongside the original Steam Deck. Those three packages from SteamOS we used to provide have always been a small fraction of the whole experience we provide.

If anyone is reading this and wants to take over maintainership of those AUR packages that I have disowned, feel free to reach out. I can provide some hints and documentation I have.