Since this happens to you often, I'd strongly recommend ruling out hardware issues. First, check you RAM with Memtest86 or similiar tool for a few runs. Bad RAM will eventually corrupt your file system, so do it before you lose any important data. Then check your storage health, and while at it, if your games are not installed on a ext4 file system, make sure you create one for testing. Last, make sure you have enough space on your game library partition.
Next, gather data. Are the games that fail windows or native titles? Wine sometimes crashes and leaves processes running and running the application again fails. Check with 'ps' command or your favorite GUI tool. Check the logs of your game launcher, wine and the game it self. System log aka journal may have some info too. Journal is unlikely to have useful info in this case, but still it's worth to take a look incase it's some wierd issue with network, GPU, etc.
Lutris forums have troubleshooting section. There is a sticky post "Please read before asking for help", that covers the details about logs. Other threads there will be good sources to learn.
Regression aren't fun. To solve them, you need to do proper debugging.
First, take a look into logs. See the Proton readme on Proton logs, and Arch wiki's article of journalctl on system logs. Also games have their own logs. When you have found a suspicious error, copy-paste it to your favorite search engine. Eg. Steam prints errors about game overlay on each start, and those are harmless.
Another option is to take a look into the issue tracker to see, if someone else has the same issue and found a workaround.
Third method is regression testing. It means going back to a working version, and testing each update to find out which one introduces the bug.
If these sound like a lot of work, it's because they are. That's why people often try random stuff that may fix the issue, or break your system, instead doing proper debugging. I personally don't have time for it, so I have given up running rolling release distros.
I hope someone is able to give you the actual fix for your issue.
I would absolutely not want it to work as a controller outside Steam. In initial mode, aka lizard mode, it works as a keyboard and mouse because they want it to be able to boot your OS. That way you can even use it to manage your UEFI settings. Even in bluetooth mode, the og. SC works initially as a mouse. It's designed for HTPCs after all.
It looks like a read error, so could be anything related to it. Permissions don't seem too likely, but possible. Could be a character in the path that some windows compontent doesn't like, or too long path.
You could try to see if moving Proton and the prefix of the game from one drive to another helps, but it just a wild guess, and comes with a risk of breaking other games. So if you are uncertain how to do it, I wouldn't recommend trying.
Yes, I have had wierd issues with Steam and external libraries. Mostly because of permissions and non-acsii characters in the path, but some have been unresolved. Steam is really complicated piece of software. The host OS, Steam linux runtimes and Proton all do their part. Flatpak can resolve and cause issues. That being said, external libraries are well tested on the Deck, and should work fine.
First step with troubleshooting would be logs. Check the Steam troubleshooting page on Arch wiki, and Proton Readme on Valve's github to get you started. You'll need to add PROTON_LOG=1 to launch options to get a log out of Proton. Also issue trackers for Proton and the linux Steam client are valuable resources.
Without logs we're just guessing. In addition to Proton logs, check the system journal aswell. 'journalctl' is the command for it. If I would be forced to guess, GPU driver bugs do often cause system to freeze. While at it, you could enable MagicSysRq if CachyOS hasn't enabled it for you, and use REISUB to try to recover. Arch wiki will guide you with these better than I could.
Yes, just deleting Boxtron folder from compatibilitytools.d should do it. You can always play it safe and move it to another location, eg. ~/backup/. Uninstalling dosbox-staging shouldn't be necessary.
Steam compatibility tools, such as Boxtron, need to install some files in users home directory. These aren't deleted when software is uninstalled with the package manager. You can check the directory ~/.steam/root/compatibilitytools.d to verify.
Add your disk to fstab, and make sure jellyfin user has access to it. Mint may have a GUI tool Disks to manage disks, but reading the Arch wiki article is a good idea.
Another option is using libpurple compatible chat app, and using steam plugin for it. These haven't had much developement effort lately, but worked last time I tried them.
There is Plasma Bigscreen that's a modification for HTPCs. For touch screen based devices, a tiling WM is available for both Gnome and Plasma, though not baked in. IMHO bigger issue for both is a poorly working touch screen keyboard. This is something that SteamOS solves quite well.
There are basicly two ways to go with regressions: bisecting or research.
With bisecting you restore a working backup, and try to isolate the breaking change. In your case you could try updating one package at time and testing. Since these are often GPU related, start with kernel and mesa. When you find the breaking update, you can either report it on your distros issue tracker, or git bisect it further to the breaking change in the source code to increase the change of it getting fixed quick.
With research, you look into relevant bug reporting databases. These include your distros issue tracker, Valve's issue trackers both for Steam and Proton, DXVK issue tracker, freedesktop.org and kernel issue trackers.
These are a lot of work, so most people just try random stuff. That's why you often get suggestions to do so.
My best guess is that you have an GPU that either doesn't support Vulkan, or has driver issues. But we shouldn't guess, that's what logs are for.
For Steam logs, running Steam from terminal as suggested is one way. Do note that error with wrong ELF class for game overlay library when starting any game is normal, since Steam tries to load both 32 and 64 for bit version for each game, and the wrong one will always fail. Arch wiki has more information.
Regardsless what distro you end up with, do your research before bying new hardware. Any hardware, such as keyboard, usb bluetooth adapter or gaming audio headset might be unsupported or supported poorly, and require out-of-kernel drivers, firmware or propietary vendor software, that work only with some kernel versions or certain distros. There often are options that have great linux support and work with any distro, but you'll need to find them.
Pick your prefered update interval between LTS, 6 month point release or rolling based on how much time you have for administration. If you need you PC also for work, a rolling distro might break just when you need it the most. After choosing the update interval, pick the distro with chosen update interval you like the most. Say you know and like Debian but need a rolling distro, then Debian unstable might be a good choice for you. You can also run multiple distros and dual-boot.
Special purpose distros such as gaming distros can be a good choice, but they often have less developer resources and tend to die then the few developers lose their interest.
Regardless of your choice of distro, spend some time to configure regular backups.
Two most common reason for Proton not working are:
Running games from NTFS or other incompatible file system.
Issues with GPU drivers.
Anyway, we are just guessing here without logs.
Set PROTON_LOG environment variable, eg. "PROTON_LOG=1 %command%" in launch options of Steam for the game. Log will show in your home dir. See Runtime config options part of the Proton README for more info.
It's quite common thing for keyboards, see this as an example.
https://github.com/denilsonsa/udev-joystick-blacklist
Since this happens to you often, I'd strongly recommend ruling out hardware issues. First, check you RAM with Memtest86 or similiar tool for a few runs. Bad RAM will eventually corrupt your file system, so do it before you lose any important data. Then check your storage health, and while at it, if your games are not installed on a ext4 file system, make sure you create one for testing. Last, make sure you have enough space on your game library partition.
Next, gather data. Are the games that fail windows or native titles? Wine sometimes crashes and leaves processes running and running the application again fails. Check with 'ps' command or your favorite GUI tool. Check the logs of your game launcher, wine and the game it self. System log aka journal may have some info too. Journal is unlikely to have useful info in this case, but still it's worth to take a look incase it's some wierd issue with network, GPU, etc.
Lutris forums have troubleshooting section. There is a sticky post "Please read before asking for help", that covers the details about logs. Other threads there will be good sources to learn.
I hope you're able to fix your issue.
Regression aren't fun. To solve them, you need to do proper debugging.
First, take a look into logs. See the Proton readme on Proton logs, and Arch wiki's article of journalctl on system logs. Also games have their own logs. When you have found a suspicious error, copy-paste it to your favorite search engine. Eg. Steam prints errors about game overlay on each start, and those are harmless.
Another option is to take a look into the issue tracker to see, if someone else has the same issue and found a workaround.
Third method is regression testing. It means going back to a working version, and testing each update to find out which one introduces the bug.
If these sound like a lot of work, it's because they are. That's why people often try random stuff that may fix the issue, or break your system, instead doing proper debugging. I personally don't have time for it, so I have given up running rolling release distros.
I hope someone is able to give you the actual fix for your issue.
I didn't find anything on Valve's issue tracker with a quick search, but maybe you'd like to investigate deeper.
https://github.com/ValveSoftware/steam-for-linux/issues?q=is%3Aissue+state%3Aopen
You could take a look at game's logs. For Windows titles, enable logs in Proton by adding PROTON_LOG=1 to launch properties, see README for details.
https://github.com/ValveSoftware/Proton/blob/proton_11.0/README.md#runtime-config-options
I would absolutely not want it to work as a controller outside Steam. In initial mode, aka lizard mode, it works as a keyboard and mouse because they want it to be able to boot your OS. That way you can even use it to manage your UEFI settings. Even in bluetooth mode, the og. SC works initially as a mouse. It's designed for HTPCs after all.
It looks like a read error, so could be anything related to it. Permissions don't seem too likely, but possible. Could be a character in the path that some windows compontent doesn't like, or too long path.
You could try to see if moving Proton and the prefix of the game from one drive to another helps, but it just a wild guess, and comes with a risk of breaking other games. So if you are uncertain how to do it, I wouldn't recommend trying.
Sorry I couldn't help more.
Yes, I have had wierd issues with Steam and external libraries. Mostly because of permissions and non-acsii characters in the path, but some have been unresolved. Steam is really complicated piece of software. The host OS, Steam linux runtimes and Proton all do their part. Flatpak can resolve and cause issues. That being said, external libraries are well tested on the Deck, and should work fine.
First step with troubleshooting would be logs. Check the Steam troubleshooting page on Arch wiki, and Proton Readme on Valve's github to get you started. You'll need to add PROTON_LOG=1 to launch options to get a log out of Proton. Also issue trackers for Proton and the linux Steam client are valuable resources.
I hope you get it solved.
If unsure, go with ext4.
Nothing pointing to HW issues jumps out from the logs. It looks more like a GPU driver issue to me. To isolate further, I'd suggest:
Make sure that Proton doesn't use your iGPU for Vulkan.
Try disabling DirectX12 in Steam game lauch settings.
Bit busy right now, so can't look up links on how to do those right now, but I hope you can find out how to do those.
Without logs we're just guessing. In addition to Proton logs, check the system journal aswell. 'journalctl' is the command for it. If I would be forced to guess, GPU driver bugs do often cause system to freeze. While at it, you could enable MagicSysRq if CachyOS hasn't enabled it for you, and use REISUB to try to recover. Arch wiki will guide you with these better than I could.
Yes, just deleting Boxtron folder from compatibilitytools.d should do it. You can always play it safe and move it to another location, eg. ~/backup/. Uninstalling dosbox-staging shouldn't be necessary.
Steam compatibility tools, such as Boxtron, need to install some files in users home directory. These aren't deleted when software is uninstalled with the package manager. You can check the directory ~/.steam/root/compatibilitytools.d to verify.
Add your disk to fstab, and make sure jellyfin user has access to it. Mint may have a GUI tool Disks to manage disks, but reading the Arch wiki article is a good idea.
https://wiki.archlinux.org/title/Fstab
Another option is using libpurple compatible chat app, and using steam plugin for it. These haven't had much developement effort lately, but worked last time I tried them.
There is Plasma Bigscreen that's a modification for HTPCs. For touch screen based devices, a tiling WM is available for both Gnome and Plasma, though not baked in. IMHO bigger issue for both is a poorly working touch screen keyboard. This is something that SteamOS solves quite well.
There are basicly two ways to go with regressions: bisecting or research.
With bisecting you restore a working backup, and try to isolate the breaking change. In your case you could try updating one package at time and testing. Since these are often GPU related, start with kernel and mesa. When you find the breaking update, you can either report it on your distros issue tracker, or git bisect it further to the breaking change in the source code to increase the change of it getting fixed quick.
With research, you look into relevant bug reporting databases. These include your distros issue tracker, Valve's issue trackers both for Steam and Proton, DXVK issue tracker, freedesktop.org and kernel issue trackers.
These are a lot of work, so most people just try random stuff. That's why you often get suggestions to do so.
Sorry I don't have an easy fix for you.
My best guess is that you have an GPU that either doesn't support Vulkan, or has driver issues. But we shouldn't guess, that's what logs are for.
For Steam logs, running Steam from terminal as suggested is one way. Do note that error with wrong ELF class for game overlay library when starting any game is normal, since Steam tries to load both 32 and 64 for bit version for each game, and the wrong one will always fail. Arch wiki has more information.
https://wiki.archlinux.org/title/Steam/Troubleshooting#Debugging_Steam
For Proton logs, set environment variable PROTON_LOG=1. You can do it in Steam launch options, see Proton Readme for more info.
https://github.com/ValveSoftware/Proton?tab=readme-ov-file#runtime-config-options
With hardware and firmware issues system logs often point to right direction. Again Arch wiki has a good tutorial on it.
https://wiki.archlinux.org/title/Systemd/Journal#Filtering_output
Games often have their own logging too if you need to go there. You'll need to look those up, as they vary by game.
I hope this helps.
Regardsless what distro you end up with, do your research before bying new hardware. Any hardware, such as keyboard, usb bluetooth adapter or gaming audio headset might be unsupported or supported poorly, and require out-of-kernel drivers, firmware or propietary vendor software, that work only with some kernel versions or certain distros. There often are options that have great linux support and work with any distro, but you'll need to find them.
Pick your prefered update interval between LTS, 6 month point release or rolling based on how much time you have for administration. If you need you PC also for work, a rolling distro might break just when you need it the most. After choosing the update interval, pick the distro with chosen update interval you like the most. Say you know and like Debian but need a rolling distro, then Debian unstable might be a good choice for you. You can also run multiple distros and dual-boot.
Special purpose distros such as gaming distros can be a good choice, but they often have less developer resources and tend to die then the few developers lose their interest.
Regardless of your choice of distro, spend some time to configure regular backups.
Two most common reason for Proton not working are:
Running games from NTFS or other incompatible file system.
Issues with GPU drivers.
Anyway, we are just guessing here without logs.
Set PROTON_LOG environment variable, eg. "PROTON_LOG=1 %command%" in launch options of Steam for the game. Log will show in your home dir. See Runtime config options part of the Proton README for more info.
https://github.com/ValveSoftware/Proton/blob/proton_10.0/README.md#runtime-config-options
Proton github has a possible workaround.
https://github.com/ValveSoftware/Proton/issues/8010