I just updated the Flatpak release to 1.0rc2 so new installs in Bazzite, SteamOS, etc. should be the same as downloading the AppImage from openrgb.org. Remember to set up udev rules in either case.
Profiles are a bit of a mess in the current builds, but should work resuming from suspend. Hibernation may not work because the USB ports are likely powered off along with the entire system and thus the USB connection may not be reestablished properly. If this is the case, not much we can do until hidapi supports hotplugging (this has been something we wanted to support for a long time bit I don't want to depend on a fork of hidapi)
There are a handful of mostly-older games that had native Linux ports by third-party porting houses which broke save compatibility between the Windows and Linux versions of the game. However, these old Linux native ports are generally absolute garbage and you're better off running the Windows version via Proton, which does have compatibility with your Windows saves as it is running the same exact game version. It seems most games with native Linux versions released by the actual developer are fine, it's just when they offload the Linux version to a porting house that it can get messy. Those old third-party ported games were typically from the original SteamOS/Steam on Linux era (2012-2015 or so) before Proton became a thing though.
Might be because I added a systemd service recently, so OpenRGB may run as a background service. However, the device configuration in the GUI is for the local instance, not the remote one (as the service runs OpenRGB as root so it uses root's configuration). You can disable the service with systemctl disable openrgb and reboot and see if that fixes it. As part of the API/SDK rework I'm doing before 1.0 I want to add a settings interface so the GUI can change some settings on the server to fix this issue.
Honestly, not even mad. Sucks for the victims, but we need hackers poking holes in kernel anticheats. Show the game companies that kernel anticheat is a waste of effort and maybe this horrific plague of gaming will die off.
If Bungie is behind it I have zero interest without even knowing what it is. Destiny 2 was an OK game, but its god awful anticheat bans Linux users. That is a sure-fire way to make me pretend your game doesn't exist. Client side anticheat is a plague. Do it properly on the server side.
Until any competing store releases a Linux client, I can't really argue against Steam. They are a gatekeeper and almost a monopoly, but they're also the most benevolent and pro-consumer gatekeeper that we have in the PC gaming distribution space. As long as all the competition continue to be Windows-only and, in some cases, actively work against Linux users, I don't want Valve's digital fiefdom to fall.
I've been experimenting with both of these and recently wrote up a guide for installing FEX on postmarketOS (as I am testing it on my phone and tablet) but the steps should work for Pi as well.
https://wiki.postmarketos.org/wiki/Steam
I also just made a video tutorial/demo on YouTube. I ran Half Life 2 and Tomb Raider (2013). I'm not sure how capable the Pi 4 GPU is in comparison to the Adreno GPUs I tested.
Box86/64 and FEX can both run Steam on ARM. Lighter games should be playable on RPi4 and 5.
APIs can be complex too. Look at how much stuff the Win32 API provides from all the kernel calls, defined data structures/types, libraries, etc. I would venture a guess that if you documented the Win32 API including all the needed system libraries to make something like Wine, it would also be 850 pages long. The fact remains that a documented prototype for a software implementation is free to reimplement but a documented prototype for a hardware implementation requires a license. This makes no sense from a fairness perspective. I'm fine with ARM not giving away their fully developed IP cores which are actual implementations of the ARM instruction set, but locking third parties from making their own compatible designs without a license is horribly anticompetitive. I wish standards organizations still had power. Letting corporations own de-facto "standards" is awful for everyone.
In the mobile Linux scene, Qualcomm chips are some of the best supported ones. I don't love everything Qualcomm does, but the Snapdragon 845 makes for a great Linux phone and has open source drivers for most of the stack (little thanks to Qualcomm themselves).
RISC V is just an open standard set of instructions and their encodings. It is not expected nor required for implementations of RISC V to be open sourced, but if they do make a RISC V chip they don't have to pay anyone to have that privilege and the chip will be compatible with other RISC V chips because it is an open and standardized instruction set. That's the point. Qualcomm pays ARM to make their own chip designs that implement the ARM instruction set, they aren't paying for off the shelf ARM designs like most ARM chip companies do.
view more:
next ›