The difference between Mass Effect Legendary edition working better than it did on my windows machine and hanging on the launcher forever is literally whether or not I have a controller turned on & connected. I don’t know if I would have ever figured it out if it wasn’t for a random poster on ProtonDB
I was having issues with Jedi Survivor and Steam Input apparently due to the latest EA launcher. Turning the controller on after the game loaded fixed the issue for me.
Game is still having problems even when launched from Steam.
I cannot get Battle.net to launch with any regular Proton version or Experimental. I also can only get it running with GE after version 8-26. (only 3 versions, 8-26, 9-1, and 9-5)
But every version up to 9-5 has the gray screen for a couple seconds, then the game closes with no error message.
I don’t play D4 anymore so I can’t say if this still works, but back when I did, I used to launch it (ie the Battle.net launcher) from Steam, as a non-Steam game.
I also used the latest Proton-GE as the compatibility tool, so that’s something you could try as well.
That never even occurred to me and I used to do this for non steam stuff all the time. I mean without the added learning curve of Linux but still.
I’m gonna try that as soon as it finishes patching. If that works it would be so amazing. Almost too simple to actually work.
Edit- It’s already working better than Lutris. It would have chunks of the UI just turn black sometimes. All the interactable bits would come back if I pointed the mouse at them, but there would be black squares and rectangles all over the place with Lutris and I just chalked it up to a weird quirk that forcing cross compatibility just brought up inherently. Never even questioned it.
Only advice: Don’t install on the same hard drive.
I dont care how many people say “oh it works for me” it works for everyone until it doesnt, and then you spend days fucking about with utilities that you shouldnt be fucking with, and at best it works until it stops working again.
There’s likely little risk that any attack goes after a potential linux partition, but there’s much more risk that either your linux or Windows partition bricks the other.
So I turned off fractional scaling (i did that before as well and nothing changed) and ran more updates and then shut down and rebooted- issue seems to be stopped for the moment.
if it comes back, I will create an update post. Thanks!
Follow up - issue came back. I’m thinking it may be hardware or driver at this point. I am going to mess with that this evening and I will report back.
If that doesn’t work - I will do the os refresh bc I haven’t actually done that yet.
Edit: this is more of a log for myself at this point, but I am refreshing the os now.
edit two, the editing: refresh complete. will update tomrrow.
Hahaha - update on issue, it was my switch, but not the switch, I think WHEN I used the the switch (like toggling between my other machine) it made things mad until I rebooted. Then when I rebooted it was fine until I used the switch again. So I just changed the things I used on the switch and everything is kosher now.
Btrfs is amazing for a steam library. The single best feature is the compression. Games tend to have lot of unoptimized assets which compress really well. Because decompression is typically faster than your disk, it can potentially make games load faster too.
I put a second dedicated nvme drive in my PC just for steam. It’s only 512GB but it holds a surprisingly large library.
I actually found the opposite with my steam library; on ZFS with ZSTD I only saw a ratio of 1.1 for steamapps, not that there’s really any meaningful performance penalty for compressing it.
If you’re messing with ACLs I’m not sure deduplication will help you much; I believe (not much experience with reflinks) the dedup checksum will include the metadata, so changing ACLs might ruin any benefit. Even if you don’t change the ACLs, as soon as somebody updates a game, it’s checksum will change and won’t converge back when everyone else updates.
Even hardlinks preserve the ACL… Maybe symlinks to the folder containing the game’s data, then the symlinks could have different ACLs?
I wrote a blog about it last year with my method of deduplicating. I really need to update that bit because steam keeps writing files that don’t uphold the group permissions, and others get permission errors that need to be fixed by admin. Steam also failed to determine free space on a drive when symlinks were involved.
I even found recently that steam would write files in /tmp/ as one user, and fail when you logged in as another user and tried to write the same file. Multi-user breaks even without messing around.
My current solution doesn’t use symlinks. I just add two libraries for each user. One in their respective home directory, and another shared in /mnt/steam. It means that any user can update a game in /mnt/steam, and it cleanly updates for all users at once.
For example, you would have to defragment your filesystem again with btrfs filesystem defragment -r -v -czstd /. Where zstd is an algorithm and /, a root path. With this command, the default compression level will be used, which is level 3.
Be careful, defragmenting the btrfs file system will/can duplicate the data.
As for a mount point, if you decided to use zstd algorithm with level 1 compression, just add the compress=zstd:1 or compress-force=zstd:1 to the mount options (fstab or while mounting manually)
So I set up my system with btrfs in the last days and I converted two external drives (from ext4) (mainly game) and run defrag and balance, because it was mentioned in a guide to compress the existing files. Was that a bad idea? Didn’t read anything about duplicates.
Defragmentation does not preserve extent sharing, e.g. files created by cp --reflink or existing on multiple snapshots. Due to that the data space consumption may increase.
Which GPU do you have? Which drivers are you using? are you sure you’re using those drivers and they’re not just installed but unused? My first guess is that you have an Nvidia and are using open source drivers (nouveau).
Some performance difference is expected, after all most games are being run through a compatibility layer, and many others were ported as a second thought so they’re not optimized on the same level. Also note that lots of us don’t use Windows, so we’re not comparing experiences, if it runs at an acceptable frame rate with an acceptable graphics settings for what I would expect the GPU to be capable of, then I don’t bother benchmarking it.
Another consideration is whether they are plugged into the graphics card. Common performance “problems” arise when somebody tries to plug into the video-out on the motherboard, so they could be accidentally forcing the use of the iGPU, if present.
If using a somewhat modern distro, this isn’t an issue anymore (unless you run a really old OpenGL game).
I run my PC in this way with little to no performance degradation: monitors go to my motherboard (r5 2400g CPU with vega11 iGPU) and games use my RX 5700XT without having to do anything at all… Pretty smart handling tbh
I just remembered that that package isn’t compatible with Plasma 6 (yet), so maybe it got dropped from the official repos when they officially released 40.
I’m not sure. Didn’t they just move the code that was previously executed in the proprietary kernel module to the new also proprietary userspace driver that’s just connected to the hardware by this new and open source wrapper module? And the other half into firmware? It’s still arbitrary and closed code that gets forwarded to the hardware. And running there it has access to all the memory, screen content etc… I’m not sure if this is a win concerning security. I think it’s pretty much unchanged.
But there are several big advantages. Now the kernel probably won’t get tainted any longer and we can have signed kernels and activate secure boot easily. And that’s maybe a big plus for security. And I hope we’ll get the convenience, too. In the past I had the NVidia driver crap out on me while debugging stuff with recent kernel versions or release candidates. And NVidia was lagging behind, leaving me with a console instead of the desktop environment…
Didn’t they just move the code that was previously executed in the proprietary kernel module to the new also proprietary userspace driver
Probably. And that is exactly what was expected from them since the beginning of their Linux drivers. Kernel is not a place for such big and proprietary piece of code. So this is the important change.
Yes, the driver is still proprietary, but it does not break the kernel any more the way it did.
It’s the part that can legally be distributed with Linux distributions (including in-car OS) due the kernel’s license. The actual functionality is in the proprietary user space driver
It’s not likely that the driver will be mainlined anytime soon, so no. It’s the same as with the proprietary kernel driver, except maybe some being able to patch problems with newer kernel versions by themselves.
I think it’s more like small bugs in the kernel portion will be fixed faster. There are a lot of small patches needed to build the dkms module against the kernel as mainline and stable evolve - they’re often carried in various distro packages until upstream (Nvidia) picks them up for a future release. The open driver should speed that cycle along.
linux_gaming
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.