Fix AMD Vega GPU resets

If you have an AMD Vega 56 or 64 you may have had some issues using the amdgpu driver, namely random GPU resets leaving you with a blank or colored screen and freezing the computer after a few minutes. It seems that too aggressive memory reclocking is the culprit, but I found a solution in the Freedesktop bug tracker:

Stick this in your systemd, e.g. to /etc/systemd/system/amdgpu-pp.service:

[Unit]
Description=AMD PP adjust service
[Service]
User=root
Group=root
GuessMainPID=no
ExecStart=/opt/amdgpu-pp.sh
[Install]
WantedBy=multi-user.target

Then in /opt/amdgpu-pp.sh:

#!/bin/bash
echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level
echo "1 2 3" > /sys/class/drm/card0/device/pp_dpm_mclk

chmod +x that bugger and enable/start the service:

systemctl enable amd-pp.service
systemctl start amd-pp.service

There, done! I have never had any GPU resets after this. Thank you, haro41, for this workaround.

Fix Popping with Pulseaudio when Playing Audio After a Period of Silence

When I got all fancy and moved to the 5.x kernel and Pulseaudio 12.2, I had one big new problem: My sound card would make an ugly popping noise every time it started playing sound again. Very, very 90s.

Fortunately, this can be fixed. Thanks to hateball for this solution. Stick this in your ~/.config/pulse/default.pa:

.include /etc/pulse/default.pa
unload-module module-suspend-on-idle

And kill/restart pulseaudio with pulseaudio -k.

Stolen from the Arch wiki.

A Quick Look at openSUSE For Gaming

I’ve been trying SUSE as my main distribution and that’s something that hasn’t happened in my life since 1996. Even worse, this distro impressed me, a hardcore Debian nerd, quite a lot.

But why go distro hopping at all? Because Canonical very boldly decided to drop support for using 32-bit executables (and libraries) in Ubuntu starting as early as October 2019. That means that potentially thousands of games will no longer work, and it prompted Valve to drop support for Ubuntu in Steam. Valve is arguably the most important contributor to Linux gaming, so this is a big deal and a good enough reason to look at distros other than Ubuntu.

I had only switched to Ubuntu four months ago, so now it might be time to switch again.

Continue reading “A Quick Look at openSUSE For Gaming”

Final Fantasy XV: A charming catastrophe

None of the systems that Final Fantasy XV throws at you really work on their own. The fast travel system is not fast at all. The combat can be anything from confusing to floaty, from frustrating to disappointingly easy. The world that’s presented, a melange of present-day hyperrealism, sci-fi and fantasy, shouldn’t work at all. Leveling up can only be done while resting, magic spells need to be constructed from scratch before use and the controls and camera are sometimes terrible, sometimes passable. You’d think this game would be a huge disappointment, but strangely, it develops a rough charm that’s impossible to pin on any one thing.

TLDR: 7/10. Problematic but weirdly enthralling. Read on for the details. Minimal spoilers (character names and backstory) ahead.

Continue reading “Final Fantasy XV: A charming catastrophe”

Making Steam’s magic work when using a Dual Shock 4 controller

A few kernel versions (or Steam versions) ago, my Dual Shock 4 controller spontaneously stopped working in Steam. Big Picture mode said “no controller detected” and only games that had their own native DS4 support managed to still use it.

Looks like you need some udev rules to make sure all things are good. For my wired DS4v2 I stuck this:

SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666"
KERNEL=="uinput", MODE="0660", GROUP="myusername", OPTIONS+="static_node=uinput"
KERNEL=="hidraw*", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="09cc", MODE="0666"

into /etc/udev/rules.d/99-ds4.rules. And reloaded udev. Thanks Xard and others from Freenode’s #gamingonlinux for the pointers.

Wanna use a Mayflash DolphinBar with Dolphin on Linux? You’ll need this udev rule

This is what I needed, I put it in /etc/udev/rules.d/80-dolphinbar.rules:

SUBSYSTEM=="hidraw", ATTRS{idVendor}=="057e", ATTRS{idProduct}=="0306", MODE="0666"

I can’t remember where I found this, I’m pretty sure I didn’t figure this out for myself. If you need a DolphinBar, Aliexpress should have you covered. It could be that the vendor code differs for yours, so make sure to watch dmesg when you plug it in.

Yet another way to get a tear-free, stutter-free desktop with Plasma/KDE and Nvidia

So the proprietary Nvidia driver is a large, steaming, smelly pile of shit. At least that’s the impression you get when you read what developers say about it. There’s a bug here and a workaround there, and we haven’t even started talking about the messy situation that is EGLstreams yet. So why do people use Nvidia cards on Linux? Because so far, they give good bang for the buck, use relatively little energy for what they do and work with all commercial games. I’m pretty sure those are the reasons, anyway.

But Nvidia at least on Plasma/KDE has some serious problems with tearing and stutter — I have three Nvidia setups and they all are unsatisfying out of the box. If you use ForceCompositionPipeline like I recommended earlier, you will probably run into stutter issues. But I think I found the perfect setup now, stutter-free and tearing-free for desktop use as well as perfect for gaming.

There are two alternatives:

Method 1: Solve it by switching the GL yield mechanism to USLEEP

Add the following to ~/.config/plasma-workspace/env/kwin.sh:

#!/bin/sh
export __GL_YIELD="usleep"

Thank mahenou on Steam for suggesting I try this again. The first time I did, it was probably too late in the environment for Kwin to pick it up. It’s important that the var is set when Kwin initializes.

Method 2: Solve it by forcing triple buffering

Add the following to ~/.config/plasma-workspace/env/kwin.sh:

#!/bin/sh
export KWIN_TRIPLE_BUFFER=1

And chmod +x the file. Then add the following to an Xorg config snippet, for example /etc/X11/xorg.conf.d/20-nvidia.conf:

Section "Device"
        Identifier      "Videocard0"
        Driver          "nvidia"
        Option          "TripleBuffer" "true"
EndSection

Finally, enable compositing and vsync

Then make sure you have compositing enabled in System Settings -> Display and Monitor -> Compositor. If you are very doubtful, do a restart. After that you should have a perfect, tear-free and stutter-free desktop experience. I had to disable compositing manually with Alt-Shift-F12 before starting games with the triple buffering method. This was unnecessary with the __GL_YIELD method.

I can’t truthfully explain why this works, but I know it works around a bunch of bugs and unexpected default settings in the Nvidia driver. Also, Kwin is now able to compute the right timings and handle triple buffering instead of rendering half-finished frames like a fucking moron when it still believed Nvidia was doing triple buffering by default.

For me this has been wonderful. The desktop is smooth as if I were using a proper graphics card like an AMD RX 580 with Mesa. Games run exceedingly well, and there is no stutter or delay like with ForceCompositionPipeline. Not even in videos. It’s all just perfect.

This is a mix of hints received from several people on Reddit and Steam that I unfortunately forgot the names of, as well as info from the Arch Linux wiki. I’d like to thank all these people for their knowledge.

Starting a second year of game-buying abstinence

The last time I tried this went OK, but I think it didn’t really cure me yet. This is evidenced by my growing list of games on Steam, mostly coming from sales and bundles.

So for this second attempt at game-buying abstinence, I follow all the rules from my earlier attempt and add some additional restrictions:

  • No looking at bundles
  • No looking at sales

I found out that psychologically, what always gets me are very good deals (-75% or such). I might not actually play that game or anything from a bundle for several years  because my backlog is so long, but I always end up buying it anyway. That’s idiotic — if I waited two more years without buying any games, whatever is at -75% now will likely be even cheaper by the time I actually have time to play it. And my backlog should be shorter.

Of course it’s the crafty pricing psychologist that Valve hired in 2011 who is to blame for my failing. Not me! How could it be me?

Not even looking at any sales should help with this. As I found out last time, you can disable all sales notifications in Steam’s interface settings, and also skip directly to your library view instead of going to the store first. This helps more than you might think.

I’ll report in a year. Maybe I can make an improved list of suggestions.

Using Xbox 360-compatible controllers properly inside WINE

Update: There are now easier ways to manage this, for example through Lutris. If you manage your WINEs in Lutris, you simply have a checkbox whether to include dumbxinputemu or not.

If you need to use WINE to play some Windows games, the lack of Xinput support might get on your nerves. WINE maps joystick devices to Dinput. That works for some older games, but buttons need to be mapped manually, and many newer games don’t detect the controllers at all because they expect Xinput.

I tried to get by this issue using x360ce, but this is a fickle beast already when run natively on Windows; even more so in WINE. What worked really well for me was dumbxinputemu. Sometimes dumb things are the best.

To use it, determine if you’re running a 64-bit or a 32-bit game, then copy at least the matching xinput1_3.dll from the latest release to the same directory as the game’s binaries. In the case of Steam, that’s probably somewhere inside Steam/steamapps/common. Then make sure your WINE is set to prefer the native version of the DLL via winecfg:

In the “New override for library” dropdown select “xinput1_3”, then “Edit…” that entry to set it to “native” only. If you have a very new game, you might need to do repeat all these steps for xinput9_1_0.dll. This worked surprisingly reliably for me, no more double-detection of joysticks, no more wrong labels for buttons inside games, no more fiddly x360ce that works sometimes but then mysteriously breaks. Everything behaves as it shoud. Thank you, kozec.