Razer's about to be flooded with complaints that people can't play Fortnite because of their mice. You You don't want to be THAT guy.

Laptop got Broadcom WiFi and needs out of tree drivers? Oh boy, you just made it impossible for many to play Fortnite. Now you either have to use Intel next time or pay Broadcom millions to finally support Linux.

I wouldn't say I'm cautiously optimistic, but I am cautiously HOPING.

User Nostalgia_Realm used GPT-6 Astra to decompile dgvoodoo2 to check crashing of the utility on Linux/Wine environments

I used **GPT-6 Astra** to investigate the supplied dgVoodoo2 binaries. It identified the relevant code and produced a working fix in approximately **17 minutes**. I then personally confirmed that Snail Mail’s Tutorial renders and responds correctly with the patched DLL.

The findings point to **a Wine-specific code path inside dgVoodoo2 as the cause of this regression**. No changes to Wine were needed to remove the reproduced crash.

The relevant code does the following:

1. Walks the process’s loaded-module list and locates `NTDLL.DLL` using an encoded name.
   
2. Reads its export table directly and searches for names containing `wine_get`, such as `wine_get_version`.
   
3. Conceals that substring comparison behind arithmetic and numeric constants, rather than a readable Wine-identification string.
   
4. When Wine is detected, takes a path that skips clearing two graphics-state values. Redirecting execution to the normal clearing path removes the reproduced failure.
   

This was confirmed in **2.82 and 2.87.5**. The corresponding check was absent from the supplied **2.8** D3D8/DDraw binaries. Every intervening release was not individually analysed, so this does not establish the exact release that first introduced it.

The fix is very small once the affected DLLs are unpacked:

- **2.82:** change one branch-displacement byte in each affected D3D8/DDraw DLL so that the state-clearing instructions also execute under Wine.
- **2.87.5:** change one instruction byte per Wine-export detection routine so it returns “not detected.” There are **23 copies across 22 DLLs**, including both copies inside the ARM64X D3D9 DLL. The two D3DImm DLLs lack this check.

With the original DLLs, Snail Mail crashes and a separate DirectDraw test fails during surface creation. With the patches, Snail Mail runs and the DirectDraw test passes drawing, pixel readback, and cleanup. DXVK was still needed for D3D11 translation.

**I strongly suspect deliberate interference with Wine compatibility**, given the obfuscated Wine detection and the harmful path it selects. Intent cannot be established conclusively from this evidence alone, but the Wine detection itself, and its connection to the reproduced failure is concrete. The earlier comment’s more specific D3D12-pointer explanation was not independently established.

He then continues

About this bug report, I am not a coder. I cannot say with 100% certainty that this is a Wine issue. However, the evidence GPT-6 Astra produced seems to point to malice from Dege. He intentionally sabotaged his app to not run via Wine. I'd say this means we can close this bug report and make it a community effort to introduce an open source alternative that can do the same. I think that's a much better use of our time and AI compute ;)

Has not happened yet but I believe it would happen in the future

User Nostalgia_Realm also said he might provide patched dgvoodoo2 builds in his website

People seem to think the new EAC is a magic bullet to solve all their problems while understanding little to nothing about how it actually works and what it means.

As I and many others have pointed out a kernel level anticheat in Linux starts with requiring the use of only pre-approved kernels and kernel modules, and here we are.

No, saying "just jump distros" is not a magic solution. Many people choose distros for very real very practical reasons.

Some might choose Arch spins for it's rolling release paradigm and up to date packagesband flexibility, while others might choose fodora for its corporate grade stability/predictability, while others might choose Debian for its bullet proof stability and security (unless you run change repos then you lose those).

Being told to jump distros by a gaming company of all things is a joke, and sets a very bad presidence. Many people left Windows to get away from a bunch of arbitrary requirements and now people are trying to welcome that concept into Linux.

There's also the issue of modules and out of tree drivers/kernel code.

Need a patch for a new NVME with a quirk? Sorry Tim sweeny didn't approve.

Want that driver for the new GPU that just dropped? Sorry gotta wait for a sweeny approved kernel before you can use it.

What about laptop modules? Users of Tuxedo and other brands use kernel modules to take care of managing board components and other things, now they can't play games unless they give up keyboard features and battery life?

What about BchacheFS users? Yeah it's a joke to be using an experimental file system but they want to, why does Tim get to say no?

What about Gentoo users? They just forgotten about? Just because I don't use it doesn't mean I'm going to condem them for no reason.

This doesn't just stop at anticheats either. The bigger issue is we have a platform where we own our computer and this is the start of the end of that. If everyone just bends over and accepts this then every company is going to start requiring kernel modules, tpm, and secure boot for everything and we'll be right back to a design we fled from.

All this can only happen if we accept it and the sad part is the immediate reaction from people who just swapped from windows recently seems to be " just surrender your PC so I can play a game bro!".

Kernel level AC hasn't stopped cheaters on Windows and now kids want us to install kernel level ACs onto our Linux machines just to still play against cheaters using windows?

I get people want to play their games but have some self control.

When the "solution" literally causes issues simply using your computer it's not a solution. If I wanted poor laptop support and waiting forever for GPU drivers I'd have chosen BSD.

I have no idea how the mere thought of fortnite makes people (some of which are grown ass adults) want to sabotage their own platform and be told what distros they can and can't use and what hardware they can and can't get full support for by a CEO who hates Linux.

We as a community shouldn't be settling for the worst possible option for game support.

If Blizzard can do a server side anticheat and still have the same if not fewer cheaters than fortnite then why is everyone so gung ho on slapping proprietary spyware in there machines for little to no gain?

People on Twitter were trying to use those points to attack the new launcher and epic trying to give more attention to Linux

Source: https://x.com/GloriousEggroll/status/2110404004115272038

https://x.com/coral9000/status/2110443700522537193?s=20

I've seen quite a few people misunderstanding this announcement and claiming that Epic is bringing kernel-level anti-cheat drivers to Linux.

Epic explicitly confirms that EAC Linux v2 does not install or load a kernel module.

Instead, it uses existing Linux security features, eBPF programs and a systemd service that only runs while the game is running.

That doesn't mean it operates entirely in userspace, though. It still relies on kernel security mechanisms and requires things like Secure Boot, TPM 2.0 and signed kernels.

It's worth actually reading the technical details before assuming it's the same approach used on Windows.

Source: https://onlineservices.epicgames.com/news/introducing-easy-anti-cheat-linux-v2

I'm using Slackware Linux 15.0+ (current). I was able to install and run Caravan SandWitch easily, but the Store page shows nothing.

Also epic is rebuilding Easy Anti-Cheat for Linux (EAC Linux v2) to deliver near-Windows-level protection using signed kernels, Secure Boot, TPM 2.0, and other existing Linux security features starting with a Fortnite, so more multiplayer games can finally support the platform without enabling widespread cheating.

https://onlineservices.epicgames.com/news/introducing-easy-anti-cheat-linux-v2

Download launcher here

https://launcher.epicgames.com/

From FAQ:

What should I know about Linux support?

The new Epic Games Launcher runs natively on Linux, but many games are Windows-only builds and may need a compatibility layer. Check each game’s Linux compatibility before installing.

We support Ubuntu 22.04 LTS or newer, Fedora 43 or newer, and Debian 12 or newer. Other distributions may work but aren’t officially tested or supported.

Use the Send feedback button in the launcher to report issues.

After reading the recent updates about the Epic Games Launcher and Fortnite coming to Linux, I could understand the reasoning behind things like enabling IOMMU, blocking kexec, and even the trusted kernels + modules signed with a known key. (I'm not a fan since I sign my own kernels and modules, but I digress)

Although, I saw lots of replies on Twitter about people complaining about the Secure Boot requirement. Why? Maybe I've just gotten too used to the command line, but doesn't sbctl handle the key creation and the signing of the contents in the ESP well? And, I thought most user friendly distros automatically setup Secure Boot nowadays?

Regardless of your intentions to play video games with anti-cheats, I'd say that securing the early boot chain is something everyone should do.

i have never been encountered this in my 3 years of linux. i just start it from start menu, and i tried to launch from terminal (i wrote "steam") still no output. how should i approach this problem?

i'm on LMDE 7 with only backported mesa.

steam version 1:1.0.0.83~ds-3 (system package)

6.12.111+deb13-amd64, Mesa 26.1.6-1~bpo13+1

5700X3D, RX6800x 32GB ram

asking before i FAFO further.

For context: Epic Games is reworking Easy Anti Cheat for Linux, for details read this: https://onlineservices.epicgames.com/news/introducing-easy-anti-cheat-linux-v2

This is IMO how Anti-Cheat should be handled, to best respect all parties involved (Gamers, game developers, regular PC users, ...)

On Windows, Anti Cheat has long been a race to the bottom (figuratively and literally). Cheaters try to undermine games, first with debuggers, then kernel modules, then DMA devices, ... while AC developers are fighting back with more and more invasive methods (rootkits, kernel drivers, always-on AC, ...). Regular gamers and users are the ones loosing heavily, as a single mistake this close to hardware has detrimental consequences. False bans because of wrong CPUs, accidental privilege escalations straight into the kernel, bricked hardware, ... are all possibilities.

Meanwhile on Linux, AC has long been very weak compared to Windows, as it runs exclusively in userspace. It couldn't do much more than asking the kernel nicely "please don't let other programs debug me". While great for the average user as this (obviously) isn't a rootkit, it makes cheating reasonably easy in comparison. This results in the average gamer encounters more cheaters, publishers not willing to port to Linux as a result, ...

The new Epic AC goes a new way: It uses a lot of tech (mostly spearheaded by systemd, Android and cloud / embedded environments) to ensure an "even playing field" where the core of the OS (hardware, firmware, bootloader, kernel) is trusted by all parties (users and games) to not contain any rootkits. All parts that are signed and "locked" by your distribution are easily auditable, by both Epic and you. On top of this, the regular userspace AC suffices to give the game very strong guarantees that nothing fishy is going on below, while also ensuring to users that they can still use their without having to trust Epic with their live savings, as all parties can mutually trust the same, open source code running below them.

I think this is an incredibly elegant way of handling AC, and is how it should've always been done (and has always been done outside of Windows, Android, iOS and most consoles use this "mutual trusted base" approach already, albeit not open source there.)

What do you think about Epics new AC?

Edit: Reading my post again, I want to make clear that I'm not shilling Epic in general. I really like how they are handling Easy AC v2, and it feels nice that Linux is being taken seriously by a company other than Valve, but I too have many issues with Epic.

I have tried diffrent proton versions but nothing seems to work. happens on both the steam version and the non steam launcher. Edit: turns out I used an outdated dwproton version by accident. It launch now

I first started using Linux with Mint, on a 2011 asus laptop, 8gb of ram, an hdd, a 2nd gen i7, and a 560M. It was terrible at the time to figure out what gpu flags to pass, I didn't have a big steam library, but Minecraft was punching 70fps on modern versions and playing what I consider heavy mods at about 30fps. It was nice, Windows it started at a baseline of about 30-40fps on modern, then modded was a no.

Then I got a desktop, 16gb ram, ryzen 5 3600, and an rtx 2060, and a solid state drive, that's all that's relevant for now. I grew out my steam library and got my most interesting test game, Satisfactory. Satisfactory includes a built in decent-enough hardware benchmark, and has potential to stress my cpu and gpu, and load times are noticable. With my desktop, I first started out on Windows 10 (So far 10 -> Mint -> 10) and found it alright, I couldn't customize though, and alt tab out of kerbal space program took ages, so I eventually switched to Linux Mint again.

On windows I could get about 100fps on modded Minecraft, around 300-400 with no mods, and Satisfactory benchmarked their "Medium" setting, and started lagging around Phase 3. Kerbal Space Program was not bench marked, but alt tab out of fullscreen took forever.

So, Mint, how does mint do? I tried Satisfactory on proton 9, because it's the top of the list. I was able to benchmark high settings, and my cpu was overall less stressed, and Satisfactory took less time to load. On top of that, Minecraft was now about 10-20fps better on modded, and able to push 700fps on no mods. Kerbal Space Program alt tab didn't take forever. Also got Portal 1 and 2 on here, which both ran 300fps, which is the limit, at max settings. Only issue was I had to change launch options to use proton after I got a 2nd and 3rd monitor. During this Mint stint I upgraded to 24, then 32, then 40gb of ram.

Eventually at some point I managed to completely break my display environment, and tried to switch to Windows 11. I had no time to benchmark games because I couldn't change my CRT res without a BSOD due to my amd gpu acting as a display adapter for vga and dvi-i. I had Windows 11 for about 3 hours tops, the whole time it was slow and clunky and had so many damn popups. No benchmarking time.

Then I swapped to Debian, same performance.

Then I had to pack the desktop, so I was back to the asus. Chucked an SSD in it, 20gb of ddr3, and tried Debian. I was getting about the performance I was getting before in Minecraft, Vulkan was still a no, but now I had more games to try. With the asus again I was able to get 120fps on Portal 2, dipping toward 90fps in some sections. No possible way to make satisfactory boot. It could also run KSP, but time was slower than realtime almost constantly in atmosphere, though in space it was fine, albiet my lap was warm.

Then I got the desktop back and tried Arch I finally realized proton experimental was a thing, and I was able to push a straighter fps graph on Satisfactory, nothing big yet. Meanwhile Minecraft didn't have noticeable gains, nor did other games. Biggest improvement was load times all being far lower than anything else I had tried, notably so.

However, I wanted to see if Cachy provided good improvements, I didn't expect much, but I was blown away. I tried cachy kernel and cachy proton. I boot into any game now and it feels like my mouse is attached to my movement, instead of the delay, it's like barely visible but highly sensible. Then I ran Satisfactory hardware benchmark. My 2060 is now doing ultra settings on an unreal engine 5 game at a very stable 60fps. Absolutely insane.

Across my journey of Win10 -> Mint -> Win10 -> Mint -> Win11 -> Debian -> Arch, one thing was constant, Linux surprising me about performance whatever I put it on, and feeling far more responsive. Other constant was Windows feeling like a prison. My DE journey is Win10 -> XFCE -> Cinnamon -> Win10 -> Cinnamon -> Win11 -> Gnome -> KDE -> (Laptop) KDE -> IceWM -> LQXT -> (Arch) XFCE -> I3wm. Overall happiest with IceWM but it has multimonitor issues.

Overall, I noticed a general trend on this subreddit of just posting things are broken, so I wanted to post my experience of everything working beautifully and swell, since nobody really posts about that?

it's called My Beautiful Faraway, a short, surreal, melancholic walking sim inspired by older adventure games where you have to explore, pay attention to small details, and figure things out on your own without much guidance.

the gameplay is pretty simple: mostly walking around, talking to strange characters, and solving occasionally unconventional puzzles. a first playthrough takes around 3 hours, but there are multiple endings, optional content, and plenty of things you might miss.

the game is made in godot and has a native linux version, so there's no need for proton or any other compatibility layers. i also tried to make sure it works well with different hardware and controllers :)

steam page: https://store.steampowered.com/app/4516190/

The Oculus Rift S now runs natively on Linux SteamVR. No Windows, no Oculus software, no Meta account.

What works:

- Rock-solid headset and controller tracking, full 6DoF

- Room Setup inside the headset: floor and boundary, remembered between sessions

- Passthrough

- Controller haptics

- Your Linux desktop inside the SteamVR dashboard: open Steam, a browser or anything else without taking the headset off

- Settings app with a live view from the headset

- Plays normal SteamVR games: install, open Steam, click SteamVR

Install on Arch, no compiling:

curl -LO https://github.com/lbgos/rift-s-linux/releases/download/r28/rift-s-linux-bin-28-1-x86_64.pkg.tar.zst

sudo pacman -U rift-s-linux-bin-28-1-x86_64.pkg.tar.zst

Then reconnect the headset, open Steam and start SteamVR. AUR packages are coming once AUR registration reopens. Other distros can build from source.

Tested on Arch, KDE Plasma 6 Wayland, RTX 3090.

Source: https://github.com/lbgos/rift-s-linux

Free and open source. Bug reports welcome, especially from AMD GPUs and non-KDE desktops.

The recent news is concerning. The more concerning issue however is that propel think this is only about Fornite, it's not. this is about every current and future ESC game

These are all the current Linux supported games, give or take, that users will lose access too after epic "sugests' they update to EAC Linux v2.

7 Days to Die

Armored Core VI: Fires of Rubicon

Back 4 Blood

BattleBit Remastered

Brawlhalla

Breachers

Caliber

Chivalry 2

Dead by Daylight

Deceive Inc.

Dragon Ball FighterZ

Dragon Ball Xenoverse 2

Dune: Awakening

Elden Ring

Enshrouded

Fall Guys

For Honor

Friends vs Friends

Goose Goose Duck

Guilty Gear -Strive-

Halo: The Master Chief Collection

Hell Let Loose

Insurgency: Sandstorm

iRacing

JoJo's Bizarre Adventure: All-Star Battle R

MotoGP 24

MultiVersus

Palworld

Phasmophobia

RIDE 5

Rust

S.T.A.L.K.E.R. 2: Heart of Chornobyl

Sea of Thieves

Sniper Elite 5

Squad

Starship Troopers: Extermination

The Division 2

The Isle

The Outlast Trials

V Rising

Warhammer 40,000: Space Marine 2

Warhammer: Vermintide 2

Watch Dogs 2

Then think about all the future games we won't have access to because EAC is easy and convenient for the developer. I guess we all better use only a few supported distros. oh wait.. 5 years for now it's only 1 supported distro that Microsoft just bought... oh well I guess this is good news...

Valve decided that Vulkan needed a few fixes and updated it yesterday, of course, that came with its new batch of bugs, and now my game runs for between 2 and 10 minutes before freezing and going completely unresponsive.

I have some really old dvds one with NFS:the run and one with gta 4 and I was wondering if I can install them using litrus in any way( it dosen't have to be litrus) .

CachyOS
Kernel 7.2
Ryzen 5 5600G
16GB RAM
GTX 1660Ti

Game is on a m.2 nvme (ext4)

I have this problem where the loading time is 8-10 minutes long, when loading the game or teleporting somewhere, it doesn't happen with GE-Proton but that recently stopped working cuz the game updated their anti-cheat, I'm launching the game via steam, tried with the NTSync command but still it takes a lot of time to load the game, is it because the game runs on vulkan?

Some help would really be appreciated!

My mouse cursor leaves the monitor that fallout is running on, which makes it really hard to play the game if i ever want to turn left. There's an old post on this that i tried the solutions from, to no avail. I'm running Cachyos, using proton-cachyos-11.0 for my compatibility layer. I know it's possible to maybe attempt some kind of fix by tweaking .ini files but i'm not experienced enough to try that without some kind of guide. Any suggestions are appreciated. please, don't stay silent if you think i've tried it, because, once again, im not all that smart at this yet