I wish them the best with the hardware, but the marketing and the pitch are just horrible. Even ignoring poor speach skills (combined with being nervous and non-native), this is exactly how I don’t like products to be advertised - a lot of boring numbers and specs, lots of magical marketing words, but nothing meaningful and practical.
Why would I care on how high they clocked that thing while there’s zero information on how games will actually run?
3-4h battery life is a bold promise, but what games and settings? Is that while pushing it to the limit, or is it average in tested games?
Very little being said about software. Cool, Linux 6.7 (so hyped for features of that particular kernel /s), you forgot to mention if it will ship with Mesa 24 and what Wayland protocols will it support. Seriously though, who the heck cares? How about integration with game launchers and store fronts? How would I know what that gamepad UI offers? How would the extended input work? Will it work with Steam Input or there’s an independent utility for controller mapping? If so, how complete comparing to Steam’s one? „We included touchpad” - cool, I noticed even two of them, but how usable they will be is a big unknown here.
120Hz is nice, but what about synchronization? Will the panel (and software) be VRR capable, or will it just vsync?
Is this even a product targeting gamers in general or Linux and tech enthusiasts specifically? Because if the intention was to impress gamers (especially interested in consoles) then it’s just showing how they don’t get that market.
I tried all of them and none can handle adding custom kernel modules properly. The longest I spent was on Bazzite, because I could build my custom rpm for akmods, but then it has issues sometimes that the image was built with newer kernel than available and it fails due to being unable to install kernel modules. Long story short it requires full image build. The viable solution would be to ask devs to include the driver I need in their akmods collection, but that’s some random github fork of old driver removed from mainline kernel long time ago. I’d much rather have ability to add that myself.
I tried Nobara and used its gamescope-session package. It’s just as complete as Bazzite and the final touches are far easier to get. It’s still traditional Fedora, but gaming and HTPC ready almost out of the box.
I’m very sceptical. I’m fine with their launcher being proprietary, but when they utilize FOSS then just contribute to projects and improve the whole ecosystem. Without exclusivity.
Lie about SteamOS being locked to Steam on their front page is immediate red flag. Yes, it’s Steam-first, the easiest way of running games is, well, through Steam, so obviously it doesn’t offer painless controller friendly way of installing games from other store fronts, but at the same time nothing is locked here and other launchers or games from other stores work fine on SteamOS. The point is fair, but the word choice is ass.
And how exactly integration with something like Epic or GOG would be „first class citizen” without official support/agreements? Do they plan deals with Epic? Is their CEO happy to suddenly support Linux or is it going to be locked down to just the platform? If it’s unofficial, how it will work from the legal standpoint that they advertise potentially paid software with other companies brands as if it was official?
If there will be any form of exclusivity, the PR will be horrible
Make sure Steam is not a Snap package - it’s known from having many issues.
When locked, try to switch to tty with ctrl+alt+f3 (or 4, 5,…), login, list processes using ps -aux, find if there are any processes remaining from the game or RED Launcher, try to kill it and go back to desktop (ctrl+alt+f1 or 2) to check if it’s unlocked.
The classic way of using Wine is as simple as running any Windows binary using Wine program loader. If you’ve got Wine installed, you can likely just “Open with” in the Dolphin explorer, or simply wine program.exe in terminal. That is not a good idea however, because you just have a single Wine prefix (which by default is in ~/.wine and is controllable with env variable WINEPREFIX`) and also you will likely miss at least some dependencies for your game.
Dependencies required for launching a game will be different depending on what that game was built with in what period. If the game uses Vulkan or OpenGL natively, you don’t need any translators, but it still might need .NET Runtime, VC Redistributables, some other Windows libraries that are not (and cannot be due to legality) shipped with stock Wine. If it’s DX 9/10/11 game, you need DXVK. if it’s DX12 you nees VKD3D-Proton. You can install these using Winetricks.
To automate and ease all of that, I recommend Bottles. The app is focused on providing you with generic way to run Windows software instead of collecting scripts, it manages prefixes, install most needed dependences automatically and provide a way to manually install everything else.
I think this is also a good idea to mess with native way pf running things with Wine if you just want to learn more on how it works.
Going back to login screen is concerning at the very least, like it wasn’t your game crashing, but the Xserver or Plasma, which could potentially be a kernel bug (with amdgpu) or Mesa, or Xorg…
Try to gather some logs as it happens. See if it’s kernel/amdgpu thing
sudo dmesg
See if it’s something in user space crashing (plasma session? Xorg?)
journalctl -b # then press capital G to jump to the end of logs
I’d try to:
- trying the Plasma Wayland session to see if it’s not Xorg (should be straightforward given that you’re on AMD/RDNA2).
- revert back to stock kernel
- trying mainline kernel 6.5
- revert to stock Mesa
I wouldn’t say Arch is any more difficult to maintain and in some areas even much smoother once properly configured and in the long run. That’s because of its simplicity (the OS internals are simple, clean and easy to understand) and great documentation. I find anything Debian-based to be pretty painful experience on desktop in comparison with Arch.
All in all it depends on you. Arch isn’t that big of a deal if you can read and are willing to put a bit of an effort to it and its strenghts justify that for the vast crowd using it.
Btw, ArchISO now comes with guided installer that does most of what you need automatically and provides fairly bare bones, but usable system out of the box.
PopOS is currently using modified GNOME on Xorg. It’s impossible to get mixed refresh rates on Xorg/X11 (which is the legacy display protocol) and with your setup you are pretty much stuck with Wayland (the modern display protocol still, still progressing as a platform) - which is what you tried first if you used Nobara, whether it’s KDE or GNOME.
Note that PopOS 24.04 (that will be released this fall iirc) will in fact run on Wayland with all new Cosmic desktop (it’s first full DE written from scratch since like 90s) and promises great NVIDIA support - which can definitely be the case given recent updates.
Now on the flickering issues that you experienced, they’re specific to the NVIDIA driver and are just being ironed out. There is the new explicit sync Wayland protocol, new NVIDIA driver, patches for XWayland, patches for Mesa, maybe something more. It still might require pulling something that didn’t make it to stable distro repositories, but I think Nobara provides that and for sure will when 40 will get released soon-ish. I don’t have NVIDIA GPU, but I saw conversations on Nobara Discord and they help each other get NVIDIA going so maybe ask there.
The time frame is a bit of a problem here. If you want to avoid tinkering, hold for a little longer and in few months most distros (that ship a Wayland session) will most likely just work with your setup. If you want it now, feel free to get your hands dirty and find a way to run NVIDIA on Wayland with explicit sync support.