Spyke
linux_gaming·Linux GamingbyI Cast Fist

Setting up Armbian on an Orange Pi 5 was a much greater hassle than I anticipated - my journey (long post)

Some time ago, I asked about desktop environments that could be controlled with a game controller - https://programming.dev/post/54830683

I decided to start with DietPi, seeing as it's a much more minimal image than the minimal Armbian. RKDevTools burned it to the nvme just fine^[I absolutely hate that the program uses a 2-step disconnect/connect to the usb, which led to many a failed attempt to burn the image. What I mean is: first it writes the uboot image, then it enters a "Waiting for loader" state where it has to send a signal to the board and/or wait for it to boot under LOADER mode. For whatever reason, I had a very high failure rate in this step, whether due to cable or usb port, I'm not sure, but it was a fucking headache. I really wish you could do it step by step in order to avoid this kind of problem]. DietPi works fine, retroarch runs fine. Great.

Next, I install Kodi. For some reason, it doesn't show me the screen: the terminal stays on screen, showing the entire log output, pressing keyboard keys make sounds of selecting options, but the graphical part of Kodi is nowhere. 2 restarts later, attempting with root and the normal user, same problem. A cursory search on the internet gave me nothing (dietpi kodi terminal). Fuck me.

I then install KDE. Similar to Kodi, it simply doesn't launch. As I installed via the metapackage, I expected it would've installed with either lightdm or sddm (the login screen manager). In either case, running the command to start kde from the terminal simply gave me an error. Like with Kodi, I couldn't find this or a similar problem on a search (dietpi kde won't start) and it wouldn't run either as root or normal user.

Oh, DietPi also took forever to finish booting up because it would take its sweet time checking eth0, then wlan0 (10s on each), then nearly a minute with journalctl.

Fuck that shit.

Armbian with KDE was the next option. Sure, I wanted to avoid a bloated desktop environment, but if it worked out of the box, I could just remove packages later. Lo and behold, it did! Setting up the controller to work was easy, too, yes! But boy, what a load of cruft! Luckily, Armbian offers, under armbian-config command, an option to downsize the full KDE to a minimal install. So I did.

By the way, did you know that Armbian uses a different network stack if you don't use the minimal install? And that the package is apparently removed from the full KDE install if you downsize it? I didn't until it happened. Guess how happy i was in finding out that Armbian removed THE ONE FUCKING PACKAGE THAT ALLOWED ME TO DOWNLOAD ANY OTHER FUCKING PACKAGE. Of course I didn't immediately figure out what happened, it took some searching because the apt update error insisted it couldn't reach ports.ubuntu.com despite me being connected to my wifi, despite the config file still existing, despite a couple of restarts. Only after I found the bit of Armbian explaining this idea of using a different network stack in a different flavor was when I checked and voilá, I had no program to actually turn on and connect to a network. You would think that there would at least be some warning somewhere, or that the default systemd.network package would be installed anyway but stay disabled in this default, but nope, just get rekt noob, fuck you.

Already feeling like going back to oPi's own android rom, I trudged on and went with Armbian minimal. If that one failed or fucked itself over for no reason, I would give up. It does use a bit more memory and runs more processes than dietPi, but it doesn't fuck around during boot, it's fast, which is a huge plus. Before installing KDE minimal, I try to make a snapshot using timeshift. For whatever reason, it doesn't work. It simply gets stuck with RSYNC doing fuck-all. Under normal circumstances, it should show the progress percentage. In my case, it would show 0.0%, then the line would disappear after a couple of seconds. Leaving it there for 20 minutes resulted in nothing, despite the total used space at the time being under 3GB. There goes my plan for avoiding rkdevtools yet again. Sigh.

I fire up armbian-config and install minimal KDE. It works! I reboot just to be sure it wasn't a fluke and yes, it still works! Time to configure some stuff and... Where's the settings program? Why is there no settings? Nothing to configure keyboard, power management, locale... What the fuck? Turns out that a minimal install of KDE does not install systemsettings, which is KDE's package for configuring lots of stuff. I guess my notion of "minimal should include THE FUCKING SETTINGS" is wrong, but I digress. Once I figured the package and installed it, everything was fine. For 5 minutes.

To my dismay, plasma-bigscreen isn't a package available in the repo and the fucking page only offers a x86_64 package for download. So that option was out.

I start installing some packages, like retroarch again, also Firefox. I launch the good ol' browser and the screen immediately goes black, then shows the boot sequence. Huh. My first thought is that the board was overheating, as I forgot to properly connect the heatsink. All set, Firefox opens for 3 seconds then I'm rebooted again. Fuck me. I turn off the board, wait a bit, turn on, try again and FF crashes again. It's not temperature and I have no fucking clue what could be instead. The solution was installing flatpak bazaar and then using brave browser (ugh, I know). It crashed once, but after I had like 10 tabs open. I also tried Librewolf but it crashed the system after i typed one thing to search.

Now, since I want to use this without needing a keyboard, I set up the controller again - the first time also happens to freeze the settings window for unknown reasons. Anyway, I successfully set up SDDM to auto login (after installing its setting package, because why would a minimal install need settings, right?), then do a CTRL ALT F4 to try retroarch in a different terminal. It runs fine, but when I quit, it immediately starts again. I quit again, then I see a bunch of repeated apt commands being tried again. I reboot.

You know the meme that getting audio running on Linux is a fucking mess worse than X11? There is truth to that. For reasons known only to bug gremlins, my audio stopped working^[It's possible the reason was one of the apt commands that ran during my retroarch test above, which begs the question of why the fuck the terminal went crazy and tried to run those commands right after quitting the program I ran and without my fucking input]. Reboot, still no sound. Thanks to the memes, I at least know which packages to look for: pipewire, alsa and pulseaudio. Armbian installed pulseaudio, but not some of its settings. I go ahead and install some more packages, reboot again and finally get it working again, though the sound test window still complains that it couldn't find an audio driver.

Now, let's see if retroarch actually works. Hm, I'm sure it was supposed to have an option to download cores. As a matter of fact, it does, but it's hidden by default in the linux install, so I go to /home/fist/.config/retroarch and manually edit retroarch.cfg so it'll show the option to download cores. Only it doesn't work and also breaks the UI. The log complain it can't write to the folder, though the UI breaking isn't logged, it's just a neat side effect. After some fucking around and manual downloads - which also refuse to be installed due to write permissions - I set a folder in /home/fist/libretro as the one for retroarch to look for the cores and throw all the cores there, including copies of the ones installed via apt.

It's finally working, though I've yet to stress test Dolphin (flatpak version) or Flycast, which should be the more demanding emulators. One of the reasons for the change was that the orange android's version of dolphin was insufferable with detecting controls and would often crash after a while. If that repeats here, well, I'll feel it was all for nothing.

I'm not too keen on KDE taking ~1.8GB of RAM either, so I might experiment with alternatives, like getting Kodi or Flex (which I'll have to use the rpi package) to run instead of it, although trying to logout immediately logs back in with KDE again - due to my SDDM config.

So, the tally of problems I encountered:

  1. No plasma-bigscreen for aarch64
  2. kodi wouldn't start its graphics (dietpi)
  3. kde wouldn't start (dietpi)
  4. slow boot (dietpi)
  5. armbian removing the network control package without a fallback
  6. timeshift wouldn't work (armbian)
  7. minimal KDE doesn't install system settings (armbian)
  8. couldn't connect 2 bluetooth controllers at the same time (armbian)
  9. Firefox/Librewolf consistently crash the system (armbian)
  10. KDE activating the lock screen despite no option toggled to do so (armbian)
  11. audio stopped working (armbian)
  12. Retroarch refusing to download cores; failing to install cores from a directory (armbian)

I understand the concept of rough edges and that, for ARM in general, it should be expected from linux distros, but some of the problems I faced are less rough edges and more stupid fucking design - I mean this especially on problems 5 and 7

View original on programming.dev
43
linux_gaming·Linux GamingbySibbo

What is the Detail Valley or Beamng Drive of ship simulations?

You all probably know the typical vehicle simulation game: pay 20 bucks, get three different cars/trains/tracks/airports/planes/..., and for anything more you have to pay another 10 bucks a piece. The games are pure rip offs meant to extract as much money as possible at minimum value provided to the customer.

But then there are games that are sold as one single complete product and are of high quality. Such as Derail Valley or Beamng Drive. Those are products I really value and that manage to impress over and over again. They are continuously in development and feature a detailed simulation, open world, various game modes, detailed difficulty settings and more. This makes them playable forever and ever without getting boring.

I never played a ship simulation before. Does something in the same spirit exist for ships? Doesn't matter if small boats or big cruise or transport ships.

View original on nord.pub
27
linux_gaming·Linux Gamingbycm0002

Linux Gaming, It’s Just Getting Started

With the July Steam survey clearing the 4% desktop mark, corporate tech is finally starting to look our way. GOG, Epic, and NVIDIA are pushing native or Flatpak tools, and even EA is rumbling about Proton anti-cheat support.

It’s easy to get excited, but let’s be real, a few corporate launchers and job listings aren't a victory. Valve and the open-source community did all the heavy lifting to get us here; big tech is only showing up now because the numbers are too big to ignore. Still, it's a fascinating milestone.

Thoughts on whether we'll ever see real movement on the anti-cheat front, or are we always going to be locked out of the big multiplayer titles?

Linux Gaming, It’s Just Getting Startedhttps://unknownuniverse.uk/linux-foss/linux-gaming/Open linkView original on libretechni.ca
19
linux_gaming·Linux GamingbyCannonGoBoom

GE-Proton11-4 Released

Patch notes in spoiler

::: spoiler spoiler This is AKA the "Controller fixup" release.

First the non-controller related changes:

Wine And Graphics

  • Updated the Wine base and rebased the GE patch sets.

  • Updated DXVK, DXVK-NVAPI, VKD3D, and VKD3D-Proton.

  • Rebased OptiScaler/upscaler support.

  • Refreshed the Wine-Wayland/EM-11 patch set with fullscreen, focus, scaling, pointer, IME, colorspace, and deadlock fixes.

  • Stopped automatically showing DXVK shader compiler text unless explicitly requested through DXVK_HUD.

Video And Audio

  • Fixed a race in Media Foundation source-reader cleanup that could break Street Fighter 6 cutscenes unless debug logging was

    enabled.

  • Rebased the GE FFmpeg/WineDMO video playback patches onto the updated Wine base.

  • Added socket validation needed to avoid the Killing Floor 3 video-related crash.

  • Continued the long-running WinePulse timing recovery work for audio streams.

  • Packaged the PipeWire ALSA plugin for both x86_64 and aarch64 as it's useful for some games and the DS5 haptics audio device enumeration

Controller Support

  • Finalized DualShock 4, DualSense, and DualSense Edge haptics, controller-speaker audio, and hotplug handling.

  • Fixed controller audio and endpoint handling when switching between Sony controller models.

  • Added support for Sony controller functionality in non-Sony titles such as Assassin’s Creed Shadows, Mirage, Valhalla, and

    Black Flag Resynced.

  • Added DualSense-to-DualShock 4 spoofing.

  • Added Sony HID-to-XInput conversion, including conventional two-motor rumble translation.

  • Added an ISteamInput006 compatibility fallback for games that require Steam Input.

  • Fixed Black Desert controller detection and startup crashes.

  • Added Monster Hunter Wilds controller and USB audio handling.

Game Fixes

  • Fixed the Star Citizen unsupported-OS message-box crash and its condition check.

  • Disabled executable ASLR for Assassin’s Creed Revelations to handle its dynamic executable relocation behavior.

  • Improved the Monster Hunter Wilds save import fix so missing Steam userdata paths no longer cause Protonfixes errors.

  • Added or updated fixes for Dungeon Town, Heroes Chronicles, ESO, Heroes of Newerth Reborn, LEGO Marvel Super Heroes 2, and

    several other titles.

  • Made the ICU forwarder stubs prefer native DLLs to fix a launcher crash in Cyberpunk 2077

  • Removed old game-drive exceptions and added stricter Steam library path validation.

  • Added numeric UMU_ID fallback, so umu-123456 can supply app ID 123456 when SteamGameId is unavailable.

ARM64

  • Backported LLVM-mingw ARM64X support.

  • Updated the ARM64 Steam Runtime SDK.

  • Enabled ARM64X DXVK and VKD3D-Proton modules.

  • Fixed Meson linker flag propagation for cross-compiled projects.

Next, a deeper explanation of the new controller options:

These are mainly introduced for usage outside of steam, although they can also be useful within steam when steam-input isn't working as well as it could or when wine-wayland is being used and subsequently steam controller profile switching can't be used due to the overlay not working in wine-wayland.

First, disable Steam Input:

  1. Open the game’s Steam Properties.

  2. Select Controller.

  3. Set the per-game override to Disable Steam Input.

NOTE: When running outside Steam, Steam Input is already absent.

OPTION 1: DS4 Spoof

PROTON_SONY_DUALSENSE_AS_DUALSHOCK4=1 %command%

Function: Wine presents the DualSense or Edge as a real DS4, including the DS4 device identity and report layout. This normally

preserves the game’s native PlayStation mappings and DS4 icons. This is useful for games that have full DS4 support but are missing DS5/DS5 Edge support.

Example use cases:

  • Assassin’s Creed Odyssey

  • Assassin’s Creed Origins

  • Assassin’s Creed III Remastered, including Liberation Remastered

OPTION 2: XInput Convert

PROTON_SONY_HIDRAW_XINPUT=1 %command%

Function: Wine converts DS4, DualSense, or DualSense Edge input into a correctly mapped XInput controller. Conventional XInput rumble is translated back to the Sony controller. This does not alter the game’s artwork, so the game may continue displaying Xbox or otherwise incorrect icons. This is for games whose Sony controller handling produces incorrect mappings, commonly because their controller profiles or icon support are incomplete. Typical incorrect game behavior will detect the controller, but show Xbox icons due to PS icons not being implemented in the game, and mappings also being incorrect.

Examples:

  • Assassin’s Creed II

  • Assassin’s Creed Revelations

  • Assassin’s Creed IV: Black Flag

  • Black Desert Online

OPTION 3: Steam Input Fallback


  PROTON_SONY_HIDRAW_XINPUT=1 \

  PROTON_STEAMINPUT_XINPUT_FALLBACK=1 \

  %command%

Function: Provides a compatible fake Steam Input device and forwards XInput controllers and mappings to it. For Sony

controllers, it works with XInput Convert: the Sony input is first mapped correctly to XInput, then exposed through the fake

Steam Input device. For non PS controllers that already register themselves as XInput devices, it just forwards the device as the Steam input device. This is For games with a hard dependency on Steam Input that need to run without the Steam client or with steam input disabled. It is also useful under Wine-Wayland when Steam Input profile switching cannot operate because the Steam overlay is unavailable or broken.

Example:

  • Monster Hunter Wilds

These modes are automatically enabled for the currently known affected Steam app IDs, but the environment variables remain

available for testing and newly discovered games.

None of these options should be needed for games that have proper, full DS4 + DS5 + DS5 Edge support.

PROTON_SONY_HIDRAW_XINPUT=1 Should be most useful for older games that either only have partial PS controller support without proper icons, or no PS controller support at all.

PROTON_STEAMINPUT_XINPUT_FALLBACK=1 Should rarely need to be used. As far as I know the only use case I've found is Monster Hunter Wilds, which is a steam-only PC game anyway, so steam input should work correctly there to begin with. In case it doesn't this will work with steam input disabled on the game (for example if you want to use wine-wayland -and- have full controller support). :::

GE-Proton11-4 Releasedhttps://github.com/GloriousEggroll/proton-ge-custom/releases/tag/GE-Proton11-4Open linkView original on lemmy.world
82