Pretty horrible technology, and unfortunately a good majority of the gaming industry by revenue relies on it.
Sure, except that anyone can just compile a Linux kernel that doesn't allow that.
Anti-cheat systems on Windows work because Windows is hard(er) to tamper with.
Is it possible to do this in a relatively hardware-agnostic, but reliable manner? Probably not.
I don't really care about games, but i do care about messing up people and companies that do such heinous crimes against humanity (kernel-level anti-cheat).
Although even then I'd still have qualms about paying for the creation of something that might pave the path for hardware vendors to work with authoritarian governments to restrict users to approved kernel builds. The potential harms are just not in the same league as whatever problems it might solve for gamers.
- Want to play these adversarial games
- Don't care about compromising control of hypervisor
- Don't simply have a dedicated gaming box
A hypervisor that protects against this already exists for Linux with Android's pKVM. Android properly enforces isolation between all guests.
Desktop Linux distros are way behind in terms of security compared to Android. If desktop Linux users ever want L1 DRM to work to get access to high resolution movies and such they are going to need such a hypervisor. This is not a niche use case.
I would never use a computer I don't have full control over as my main desktop, especially not to satisfy an external party's desire for control. It seems a lot more convenient to just use a separate machine.
Even mainstream consumers are getting tired of DRM crap ruining their games and movies. I doubt there is a significant Linux users would actually want to compromise their ownership of the computer just to watch movies or play games.
I do agree that Linux userland security is lackluster though. Flatpak seems to be a neat advancement, at least in regard to stopping things from basically uploading your filesystems. There is already a lot of kernel interfaces that can do this like user namespaces. I wish someone would come up with something like QubesOS, but making use of containers instead of VMs and Wayland proxies for better performance.
I honestly think you would be content as long as the computer offered the ability to host an arbitrary operating system just like has always been possible. Just because there may be an optional guest running that you can't fully control that doesn't take away from the ability to have an arbitrary guest you can fully customize.
>to satisfy an external party's desire for control.
The external party is reflecting the average consumer's demand for there not being cheaters in the game they are playing.
>It seems a lot more convenient to just use a separate machine.
It really isn't. It's much more convenient to launch a game on the computer you are already using than going to a separate one.
It's a little funny that the two interests of adtech are colliding a bit here: They want maximum control and data collection, but implementing control in a palatable way (like you describe) would limit their data collection abilities.
My answer to your question: No, I don't like it at all, even if I fully trust the hypervisor. It will reduce the barrier for implementing all kinds of anti-user technologies. If that were possible, it will quickly be required to interact with everything, and your arbitrary guest will soon be pretty useless, just like the "integrity" bullshit on Android. Yeah you can boot your rooted AOSP, but good luck interacting with banks, government services (often required by law!!), etc. That's still a net minus compared to the status quo.
In general, I dislike any methods that try to apply an arbitrary set of criteria to entitle you to a "free" service to prevent "abuse", be it captchas, play integrity, or Altman's worldcoin. That "abuse" is just rational behavior from misaligned incentives, because non-market mechanisms like this are fundamentally flawed and there is always a large incentive to exploit it. They want to have their cake and eat it too, by eating your cake. I don't want to let them have their way.
> The external party is reflecting the average consumer's demand for there not being cheaters in the game they are playing.
Pretty sure we already have enough technology to fully automate many games with robotics. If there is a will, there is a way. As with everything else on the internet, everyone you don't know will be considered untrusted by default. Not the happiest outcome, but I prefer it to losing general purpose computing.
I'm talking about the entire chip. You are unable to implement a new instruction for the CPU for example. Only Intel or AMD can do so. You already don't have full control over the CPU. You only have as much control as the documentation for the computer gives you. The idea of full control is not a real thing and it is not necessary for a computer to be useful or accomplish what you want.
>and your arbitrary guest will soon be pretty useless
If software doesn't want to support insecure guests, the option is between being unable to use it, or being able to use it in a secure guest. Your entire computer will become useless without the secure guest.
>Yeah you can boot your rooted AOSP, but good luck interacting with banks, government services (often required by law!!), etc.
This could be handled by also running another guest that was supported by those app developers that provide the required security requirements compared to your arbitrary one.
>That "abuse" is just rational behavior from misaligned incentives
Often these can't be fixed or would result in a poor user experience for everyone due to a few bad actors. If your answer is to just not build the app in the first place, that is not a satisfying answer. It's a net positive to be able to do things like watch movies for free on YouTube. It's beneficial for all parties. I don't think it is in anyone's best interest to not do such a thing because there isn't a proper market incentive in place stop people from ripping the movie.
>If there is a will, there is a way.
The goal of anticheat is to minimize customer frustration caused due to cheaters. It can still be successful even if it technically does not stop every possible cheat.
>general purpose computing
General purpose computing will always be possible. It just will no longer be the wild west anymore where there was no security and every program could mess with every other program. Within a program's own context it is able still do whatever it wants, you can implement a Turing machine (bar the infinite memory).
They certainly aren't perfect, but they don't seem to be hell-bent on spying on or shoving crap into my face every waking hour for the time being.
> insecure guests
"Insecure" for the program against the user. It's such a dystopian idea that I don't know what to respond with.
> required security requirements
I don't believe any external party has the right to require me to use my own property in a certain way. This ends freedom as we know it. The most immediate consequences is we'd be subject to more ads with no way to opt out, but that would just be the beginning.
> stop people from ripping the movie
This is physically impossible anyway. There's always the analog hole, recording screens, etc, and I'm sure AI denoising will close the gap in quality.
> it technically does not stop every possible cheat
The bar gets lower by the day with locally deployable AI. We'd lose all this freedom for nothing at the end of the day. If you don't want cheating, the game needs to be played in a supervised context, just like how students take exams or sports competitions have referees.
And these are my concerns with your ideal "hypervisor" provided by a benevolent party. In this world we live in, the hypervisor is provided by the same people who don't want you to have any control whatsoever, and would probably inject ads/backdoors/telemetry into your "free" guest anyway. After all, they've gotten away with worse.
We already tried out trusting the users and it turns out that a few bad apples can spoil the bunch.
>It's such a dystopian idea that I don't know what to respond with.
Plenty of other devices are designed so that you can only use it in safe ways the designer intends. For example a microwave won't function while the door is open. This is not dystopia despite potentially going against what the user wants to be able to do.
>I don't believe any external party has the right to require me to use my own property in a certain way.
And companies are not obligated to support running on your custom modified property.
>The bar gets lower by the day with locally deployable AI.
The bar at least can be raised from searching "free hacks" and double clicking the cheat exe.
>who don't want you to have any control whatsoever
This isn't true. These systems offer plenty of control, but they are just designed in a way that security actually exists and can't be easily bypassed.
>and would probably inject ads/backdoors/telemetry into your "free" guest anyway.
This is very unlikely. It is unsupported speculation.
You say this as if the user is a guest on your machine and not the other way around.
It's not a symmetrical relationship. If companies don't trust me, they don't get my money. And if I don't trust them, they don't get my money.
The only direction that gets them paid is if I trust them. For that to happen they don't have to go out of their way to support my use cases, buy they can't be going out of their way to limit them either.
> designed in a way that security actually exists
When some remote party has placed countermeasures against how you want to use your computer, that's the opposite of security. That's malware.
The user is a guest on someone else's network though. You may be a guest to Netflix and they require you to prove your machine is secure for them to provide you 1080p video. You are free to do whatever you want with your own machine, but Netflix may not want to give you 1080p video files if they don't trust your machine.
>When some remote party has placed countermeasures against how you want to use your computer, that's the opposite of security. That's malware.
I think it's fair to have computers that allow you to disable integrity protections and do whatever you want. You just shouldn't be able to attest that your system is running 1 set of software when in reality it's running something else. It's fraud.
There's already a body of laws that incentivize against violating copyright. It lunacy to stack on additional ones in service of the same goal. That's like saying that it's both illegal to speed, and it's also illegal to tell your friends that you'll be there in 15 minutes when you'd have to speed to get there sooner than 20, whether or not you actually do the speeding.
Devices are not legal persons, they can't sign contracts on your behalf, nor can they commit fraud on your behalf. If a bogus is attestation is necessary in service of interoperability, that's a technical detail not a legal one. If what you want is copyright enforcement, focus on the crime not the circumstance under which a such a crime is possible.
That way you could use an official kernel from Fedora, Ubuntu, Debian, Arch etc. A custom one wouldn't be supported but that's significantly better than blocking things universally.
I'm not aware that a TPM is capable of hiding a key without the OS being able to access/unseal it at some point. It can display a signed boot chain but what would it be signed with?
If it's not signed with a key out of the reach of the system, you can always implement a fake driver pretty easily to spoof it.
These attestation methods would probably work well enough if you pin a specific key like for a hardened anti-evil-maid setup in a colo, but I doubt it'd work if it trusts a large number of vendor keys by default.
It also means that if you do get banned for any reason (obvious cheating) they then ban the EK and you need to go source more hardware.
It's not perfect but it raises the bar significantly for cheaters to the point that they don't bother.
The idea is you implement a fake driver to sign whatever message you want and totally faking your hardware list too. As long as they are relatively similar models I doubt there's a good way to tell.
Yeah, I think there are much easier ways to cheat at this point, like robotics/special hardware, so it probably does raise the bar.
Basically TPM includes key that's also signed with manufacturer key. You can't just extract it and signature ensures that this key is "trusted". When asked, TPM will return boot chain (including bootloader or UKI hash), signed by its own key which you can present to remote party. The whole protocol is more complicated and includes challenge.
I feel like this is way overstated, it's not that easy to do, and could conceptually be done on windows too via hardware simulation/virtual machines. Both would require significant investments in development to pull of
And then you have BasicallyHomeless on YouTube who is stimulating nerves and using actuators to "cheat." With the likes of the RP2040, even something like an aim-correcting mouse becomes completely cheap and trivial. There is a sweet-spot for AC and I feel like kernel-level might be a bit too far.
This isn't complicated.
Even the Crowdstrike falcon agent has switched to bpf because it lowers the risk that a kernel driver will brick downstream like what happened with windows that one time. I recently configured a corporate single sign on to simply not work if the bpf component was disabled.
Anticheat and antivirus are two similar but different games. It's very complicated.
At the same time, Vulkan support is also getting pretty widespread, I think notably idTech games prefer Vulkan as the API.
Id Software do prefer Vulkan but they are an outlier.
https://godotengine.org/article/dev-snapshot-godot-4-6-dev-5...
DX12 worked decently better than openGL before, and all the gamedevs had windows, and it was required for xbox… but now those things are less and less true.
The playstation was always “odd-man-out” when it came to graphics processing, and we used a lot of shims, but then Stadia came along and was a proper linux, so we rewrote a huge amount of our render to be better behaved for Vulkan.
All subsequent games on that engine have thus had a vulkan friendly renderer by default, that is implemented cleaner than the DX12 one, and works natively pretty much everywhere. So its the new default.
- https://forums.developer.nvidia.com/t/directx12-performance-is-terrible-on-linux/303207/432
- https://indico.freedesktop.org/event/10/contributions/402/attachments/243/327/2025-09-29%20-%20XDC%202025%20-%20Descriptors%20are%20Hard.pdf
- https://www.youtube.com/watch?v=TpwjJdkg2RE
The problem is on multiple levels, so everything has to work in conjunction to be fixed properly.But even then, when everyone is trying out a new indie game there’s a chance it won’t work on non-Windows. It’s happened to me.
I'm far from an authority on this topic but from my understanding both Sony/MS have introduced mkb support, but so far it looks to be an opt-in kind of thing and it's still relatively new.
The problem is more the audience. Console players generally expect to be able to just connect the console to the TV, sit on the sofa and play with the official controller. That’s all the game are required to support to be published on the platform.
Even if you were willing to play at a desk, you’d be matchmaking into a special (and small) mouse pool on the console game. Anyone willing to go through so much faff will accept the extra annoyances of a PC, even with kernel anti cheat.
I am very pro-Linux and pro-privacy, and hope that the situation improves so I don’t have to continue to compromise.
Valve doesn't employ kernel AC but in practice others have taken that into their own hands - the prevalence of cheating on the official CS servers has driven the adoption of third-party matchmaking providers like FACEIT, which layer their own kernel AC on top of the game. The bulk of casual play happens on the former, but serious competitive play mostly happens on the latter.
And for what it's worth, I'm pretty sure Valorant is the most played competitive shooter at the moment.
The best Valve could do is offer a special locked down kernel with perhaps some anticheat capabilities and lock down the hardware with attestation. If they offer the sources and do verified builds it might even be accepted by some.
Doubt it would be popular or even successful on non-Valve machines. But I'm not an online gamer and couldn't care less about anticheats.
Making a Valve-only Linux solution would take a lot of the joy of this moment away for many. But it would also help Valve significantly. It's very uncomfortable to consider, imo.
For competitive gaming, I think attested hardware & software actually is the right way to go. Don’t force kernel-level malware on everyone.
It's a bit like complaining that these days people just want to watch TV, instead of writing and performing their own plays.
This led to legit players that were just good being banned by salty mods, or cheaters that were subtle enough to only gain a slight edge not being banned.
Other games did similarly. Quake 3 Arena added Punkbuster in a patch. Competitive 3rd party Starcraft 1 server ICCUP had an "anti-hack client" as a requirement.
Cheats were a problem. Not even a nascent problem, but already established. Bad enough that VAC was released in 2002, Punkbuster in 2000...
In competitive gaming you cannot just find a stable friends group to play against: you need competition, and a diverse one. We somewhat palliated this by physically playing in LAN, but that still limits to a radius around you and it's cumbersome when you can just find an opponent online (we had manual matchmaking on IRC before modern matchmaking existed).
The problem is that cheating can be very subtle if done correctly. The difference between "that guy is better that me" and "that guy can see through walls" is pretty much undetectable through non-technical means if the cheater is not an idiot. This poisons the competitive scene.
Competitive gaming is huge. It was big back in the day but now it's a monster. Just check the largest categories on Twitch: LoL, TFT, WoW, CS, Valorant...
Who said anything about meaning? People being shit at the game invalidates that the game ruleset is competitive?
This is like saying we need to institute drug testing at all parks to play football. Cheating in sports is a problem that very few players are concerned with. Caring about who wins isn't even common. Most are just kicking a ball around with their mates.
Yeah I'm the one in a bubble because I think players that play competitive games expect competitive integrity, regardless of their skill level.
And they don't even need it all the time either. I did once participate in a CS:S tournament, so I guess I was "competitive", but half the time I was on gun game or ice world or surf maps. My friends and I played normal Warcraft 3 against each other, but otherwise I pretty much only played custom maps, which were apparently popular enough to spawn an entire new genre. I never ran into problems queueing for something like preschool wars or wintermaul. When we did queue for ladder sometimes it was like 10 minutes to find a match.
To your earlier point about e.g. Valorant: my mom invited me to play on weekends with her and my sister. I know my mom is 0% competitive. This was not some serious thing. I couldn't play with them because I'm not going to buy another computer just to run it. That's the absurdity here.
The International (a DOTA 2 competition) has like $40m in prizes. EWC in 2025 was $70m. 99.6 million people watched the League of Legends World Championship final. And we're not even talking about the millions of dollars of sponsorship involved.
That's great your mom isn't competitive in Valorant, but massively irrelevant. It's like me saying "I play flag football with friends, there is no competitive football."
Anti-cheat is important because this is how the best players are discovered, this is how they're recruited. If a game is 50%+ cheaters, the game will die... DOTA2 would cease to exist today as a big deal. Same with Valorant.
Aside from competitive gaming, GTA V online makes $1 BILLION in ARR. That would be $0 if the game was flooded with cheaters.
Now this isn't me defending kernel level anti-cheat, I think there are better ways to do it and some games do a great job here.
But man, calling GTA V online and competitive e-sports a "tiny bubble" is like calling the NFL a "tiny bubble".
Millions of people play American football casually vs a couple thousand in the NFL, and football isn't a very popular sport to actually play. We don't need to drug test everyone at the park. We don't need to require everyone to play with official league equipment. Again, >99.9% of football players are not in the NFL. The NFL is a tiny bubble in the world of people who play football.
And it's trivial for e-sports tournament organizations with millions of dollars in prizes to spend $50k on a set of standard, controlled computers to play on. Cheating shouldn't be a problem when money is on the line because the only time a player touches the machine is at the tournament. You use standard league equipment during league games. Otherwise who cares?
As far as I know, GTA V does have cheaters and has since the beginning, so it's apparently an example of how it doesn't matter.
Even so, no game ever is 50% cheaters, or anywhere near that. Even games like Gunz: The Duel where the netcode was so garbage that hits were decided on the computer of the person being shot still didn't have many cheaters. Probably less than 1% of players. The overwhelming majority are just having fun. Cheats are boring after like 5 minutes.
"Competitive tennis cannot possibly be huge"
"Competitive coding cannot possibly be huge"
People play competition sports. They except no, or minimal amounts of cheating. Your personal feelings about it don't matter. The kid that plays basketball with 12 years olds on saturday mornings has the right to not have to deal with cheaters, and it doesn't matter if he's in the top .0001% or a shitty player that cannot distinguish his hands from his ears.
Have a quick look at the ladder on Counter Strike, or Faceit, or ranked play on League of Legends/Valorant/Whatever: it's not a niche. These games requiring kernel AC no matter the type of play is another subject, but people play to compare themselves to other, massively.
People who get intensely serious about 12 year olds playing basketball because their kid will be in the NBA some day so everyone needs to take the game very seriously so their kid can practice have rightly always been mocked. The entire point is to have fun.
I've played in Friday night sports leagues where people were drinking during the tournaments (and sometimes that's the point, c.f. sloshball). There are absolutely tons of people that do not take even the "competitions" seriously, and even more that aren't even serious enough to join a league.
Video games being something people play at home, I'd probably be surprised if there weren't more people that regularly play any given esports title under the influence of marijuana or alcohol than there are those who take it as a serious thing[0].
On competitive coding, Advent of Code removed the global leaderboard exactly because "people took things too seriously, going way outside the spirit of the contest".
[0] A quick search turns up this poll in the competitive halo subreddit where 40% say they play high. I doubt that's a good sample, but I'm sure the true number is not insignificant: https://www.reddit.com/r/CompetitiveHalo/comments/10mvihq/we...
And no, it's not "parents who think their kid will be in the NBA", it's that children who register in a club want to play competitively. On a country of 70 million, we have about 5 million registered players in different sports, the majority of which take integrity to heart.
[0] A poll on a subreddit, on a dead game with absolutely zero serious competitive scene does not count as "serious research". Yes, players play shitfaced also. The vast majority do not queue for competitive games and just fuck around in normals. Whether that's on modern games with dedicated queues for comp play, or games with dedicated leagues like ETF2L, Faceit and others.
I could almost get on board with the idea of invasive kernel anti-cheat software if it actually was effective, but these games still have cheaters. So you get the worst of both worlds--you have to accept the security and portability problems as a condition for playing the game AND there are still cheaters!
FPSs can just say 'the console is the competitive ranked' machine, add mouse + keyboard support and call it a day. But in those games cheaters can really ruin things with aimbots, so maybe it is necessary for the ecosystem, I dunno.
Nobody plays RTSs competitively anymore and low-twitch MMOs need better data hiding for what they send clients so 'cheating' is not relevant.
We are at the point where camera + modded input devices are cheap and easy enough I dunno if anti-cheat matters anymore.
the bloggers/journalists calling it malware is doing the conversation a disservice. The problem is only really the risk of bugs or problems with kernel level anti-cheat, which _could_ be exploited in the worst case, and in the best case, cause outages.
The classic example recently is the crowdstrike triggered outtage of computers worldwide due to kernel level antivirus/malware scanning. Anti-cheat could potentially have the exact same outcome (but perhaps smaller in scale as only gamers would have it).
If windows created a better framework, it is feasible that such errors are recoverable from and fixable without outages.
I'm already salty about the binary blobs required by various pieces of firmware.
For most people, a computer is just another appliance. They don't consider the security implications that this appliance can leak credit cards and such.
But I think they ought to. I also suspect that the current state of affairs is largely due to lack of understanding.
> as long as it doesn't try to update its firmware
I agree. But that isn't what we're talking about here. Things that can't update their firmware generally don't need you to upload a binary blob to them on startup.
Case in point from a few years back - Fall Guys. Silly fun, sloppy controls, a laugh. And then you get people literally flying around because they've installed a hack, so other players can't progress as they can't make the top X players in a round.
So to throw it back - it is just a game, it's so sad that a minority think winning is more important than just enjoying things, or think their own enjoyment is more important than everyone else's.
As an old-timer myself, we thought it was despicable when people replaced downloaded skins in QuakeWorld with all-fullbright versions in their local client, so they could get an advantage spotting other players... I suppose that does show us that multiplayer cheating is almost as old as internet gaming.
Competition vs other human beings is the entire point of that genre, and the intensity when you’re in the top .1% of the playerbase in Overwatch/Valorant/CSGO is really unmatched.
> pub servers
Most of these popular competitive games probably don't even have community servers of any kind. Maybe some games like RTSes have custom matches, but they're not used much for the standard game mode, at least not for public lobbies.
Also, for more casual play, don't players have rankings so that you play with others about your level? Cheaters would alll end up just playing with other cheaters in that case, wouldn't they?
That would require essentially turning it into a console or Android.
Hardware support would inevitably be somewhat limited but that's still better than the situation with either consoles or kernel anticheat.
Yeah, that's the entire point. The whole distro in this scenario would be signed reproducible FOSS builds. No untrusted binaries would be permitted to run. State of entire filesystem verified except specific directories. Think Android without the app store and no user provided APKs permitted.
Valve already manages SteamOS so this isn't as crazy as it might initially sound.
Although it does occur to me now that one of the newer GPLs has an anti-tivo provision. Not sure if this would run afoul of that. It's access to a subset of a service that would be restricted (competitive matches), everything else would still work.
The issue isn’t binary, but a spectrum. Studios clearly believe that there is less cheating when using kernel level anti-cheats. They have the data so they would know. This is an existential threat to their profit so we can trust they use the most effective tool. Anecdotally, I and many others also experience less cheating in games using kernel level anti-cheat. I’m not saying no cheating. I’m saying less cheating. That’s very important for me and many others.
Valve has stated they are working on kernel level anti-cheat “tools”, but they haven’t yet revealed a method. The entire concept is antithetical to the Linux security model so it requires significant refactoring. That’s a huge investment in not just capex and opex because the fork becomes much more difficult to maintain over time. I think they’ll do their best to work in user space, but I don’t think they’ll succeed and will have to bite the bullet. SteamOS will become more and more its own fork, including consumer-friendly features which Linux fans typically don’t care about.
This is my case with my relatively new/high-end RTX 4080 and OLED monitor. So until I upgrade both, I use HDMI to be able to drive a 1440p 240hz 10-bit HDR signal @ 30 Gbps.
I finally got the 240hz 4K uncompressed but it required buying a $1300 Asus OLED monitor and the RTX 5090. It looks amazing though, even with frame gen. Monster Hunter had some particularly breathtaking HDR scenes. I think it uses DisplayPort 2.1? Even finding the cable is difficult, Microcenter didn’t have them in April and the only one that worked was the one that came with the monitor.
DP1.4 though, so you're still going to need compression.
DP however can't transfer audio, which doesn't matter for a desktop but matters a lot for a TV.
No, it's not, the protocol is completely different (DP is packet-based while HDMI traditionally was not, though AFAIK HDMI 2.1 copied DP's approach for its higher speed modes). When you use a passive DP-HDMI cable (which AFAIK is not fully passive, it has level shifters since the voltages are different), it works only because the graphics card detects it and switches to using the HDMI protocol on that port; if it's not a dual-mode port (aka "DP++" port) it won't work and you'll need an active DP-HDMI adapter.
> DP however can't transfer audio, which doesn't matter for a desktop but matters a lot for a TV.
On the desktop I'm using to type this message, I use the speakers built into the DP-connected monitor (a Dell E2222HS). So yes, DP can and does transfer audio just fine. If it couldn't, then active DP to HDMI adapters wouldn't be able to transfer audio too.
The only thing DP doesn't have AFAIK is ARC, which might matter for a few more exotic TV use cases, and HEC, which AFAIK nobody uses.
https://www.techpowerup.com/335152/china-develops-hdmi-alter...
(Some games support 120, but it's also used to present a 40hz image in a 120hz container to improve input latency for games that can't hit 60 at high graphics quality.)
In my case I have an htpc running linux and a radeon 6600 connected via hdmi to a 4k @ 120hz capable tv, and honestly, at the sitting distance/tv size and using 2x dpi scaling you just can't tell any chroma sub-sampling is happening. It is of course a ginormous problem when on a desktop setting and even worse if you try using 1x dpi scaling.
What you will lose however is the newer forms of VRR, and it may be unstable with lots of dropouts.
Most single player games (Spider-Man, God of War, Assassin's Creed etc) will allow a balanced graphics/performance which does 40 in a 120hz refresh.
(I assume VRR = Variable Refresh Rate)
Most TVs will not let you set the refresh rate to 100hz. Even if my computer could run a game at 100hz, without VRR, my choices are either lots of judder, or lowering it to 60hz. That's a wide range of possible refresh rates you're missing out on.
V-Sync and console games will do this too at 60hz. If you can't reach 60hz, cap the game at 30hz to prevent judder that would come from anything in between 31-59. The Steam Deck actually does not support VRR. Instead the actual display driver does support anything from 40-60hz.
This is also sometimes an issue with movies filmed at 24hz on 60hz displays too: https://www.rtings.com/tv/tests/motion/24p
I thought audio might be the reason, for as far as I can tell, displayport supports that too.
It took a long time to move from the old component input over to HDMI. The main thing that drove it was the SD to HD change. You needed HDMI to do 1080p (I believe, IDK that component ever supported that high of a resolution).
Moving from HDMI to display port is going to be the same issue. People already have all their favorite HDMI devices plugged in and setup for their TVs.
You need a feature that people want which HDMI isn't or can't provide in order to incentivize a switch.
For example, perhaps display port could offer something like power delivery. That could allow things like media sticks to be solely powered by the TV eliminating some cable management.
It already does. A guaranteed minimum of 1.65W at 3.3V is to be provided. Until very recently, HDMI only provided a guaranteed minimum of something like 0.25W at 5V.
5W is what I'd think is about the minimum for doing something useful. 25W would actually be usable by a large swath of devices. The raspberry pi 4, for example, has a 10W requirement. Amazon's fire stick has ~5W requirement.
Sure. But it's ~6.6x more than what HDMI has historically guaranteed. It's pretty obvious to anyone with two neurons to spark together that the problem here isn't "amount of power you can suck out of the display port". If it were, DP would have swept away HDMI ages ago.
Nobody said it was.
I gave that out as and example of a feature that DP might adopt in order to sway TV manufacturers and media device manufactures to adopt it.
But not for nothing, 0.25W and 1.67W are virtually the same thing in terms of application. Just because it's "6.6x more" doesn't mean that it's usable. 0.25W is 25x more than 0.01W, that doesn't make it practically usable for anything related to media.
You really can't power an HDMI (or DisplayPort) active cable on 0.25W. You can on 1.67W. This is why in mid-June 2025 the HDMI consortium increased the guaranteed power to 1.5W at 5V. [0] It looks pretty bad when active DP cables (and fiber-optic DP cables) never require external power to function, but (depending on what you plug it into) the HDMI version of the same thing does.
> Nobody said it was.
You implied that it was in a bit of sophistry that's the same class as the US Federal Government saying "Of course States' compliance with this new Federal regulation is completely voluntary: we cannot legally require them to comply. However, we will be withholding vital Federal funds from those States that refuse to comply. As anyone can plainly see, their compliance is completely voluntary!".
DP 1.4 could have offered 4kW over its connector and TVs would still be using HDMI. Just as Intel and Microsoft ensured the decades-long reign of Wintel prebuilt machines [1], it's consortium that controls the HDMI standard that's actively standing in the way of DP deploying in the "home theater".
[0] "HDMI 2.1b, Amendment 1 adds a new feature: HDMI Cable Power. With this feature, active HDMI® Cables can now be powered directly from the HDMI Connector, without attaching a separate power cable." from: <https://web.archive.org/web/20250625155950/https://www.hdmi....>
[1] The Intel part is the truly loathsome part. I care a fair bit less about Microsoft's dirty dealings here.
This is a very bad faith interpretation of my comment. I did not imply it and I'm not trying to use CIA tricks to make people implement it as a feature.
Are you upset that I gave an example?
For the same sorts of reasons that made it so for decades nearly every prebuilt PC shipped with an Intel CPU and Windows preinstalled: dirty backroom dealings. But in this case, the consortium that controls HDMI are the ones doing the dealings, rather than Intel and Microsoft.
"But Displayport doesn't implement the TV-control protocols that I use!", you say. That's totally correct, but DisplayPort has the out-of-band control channel needed to implement that stuff. If there had been any real chance of getting DisplayPort on mainstream TVs, then you'd see those protocols in the DisplayPort standard, too. As it stands now, why bother supporting something that will never, ever get used?
Also, DP -> HDMI active adapters exist. HDR is said to work all the time, and VRR often works, but it depends on the specifics of the display.
Outrageous that a ubiquitous connection protocol is allowed to be encumbered in this way.
It is not really a roadblock, more like a bump, and it is not the only bump by far. Some games just don't run on Linux, or quite terribly and they don't have a big enough community for people to care. Sometimes one of your pieces of hardware, maybe an exotic controller, doesn't like linux. Sometimes it is not the fault of the game at all, but you want to do something else with that PC and it isn't supported on Linux, and you don't want to dual boot. Overall, you will have less problems with gaming on Windows, especially if you don't really enjoy a trip to stackoverflow and the command line, but except for anti-cheat maybe, there is no "big" reasons, just a lot of small ones.
And sure, it is improving.
Sadly becoming less and less an option given recent news. And if you run a laptop like me, you may not be able to choose your ports.
Assuming that cheats work by reading (and modifying) the memory of the game process you can you can attach a kprobe to the sys_ptrace system call. Every time any process uses it, your eBPF program triggers. You can then capture the PID and UID of the requester and compare it against a whitelist (eg only the game engine can mess with the memory of that process). If the requester is unauthorized, the eBPF program can even override the return value to deny access before the kernel finishes the request.
Of course there are other attack vectors (like spoofing PID/process name), but eBPF covers them also.
All of this to say that Linux already has sane primitives to allow that, but that, as long as devs don't prioritize Linux, we won't see this happening.
but how does the anti-cheat know that the kernel is not modified such that it disables certain eBPF programs (or misreports cheats/spoofs data etc)?
This is the problem with anti-cheat in general (and the same exists with DRM) - the machine is (supposedly) under the user's total control and therefore, unless your anti-cheat is running at the lowest level, outside of the control of the user's tampering, it is not trustworthy. This leads to TPM requirements and other anti-user measures that are dressed as pro-user in windows.
There's no such thing in linux, which makes it inoperable as one of these anti-cheat platforms imho.
I believe the goal is to make it so uncomfortable and painful that 99.999% of the users will say fuck it and they won't do it. In this case users need to boot a custom kernel that they download from the internet which might contain key-loggers and other nasty things. It is not just download a script and execute it.
For cheat developers, instead, this implies doing the modifications to allow those sys-calls to fly under the radar while keeping the system bootable and usable. This might not be trivial.
(The following was refined by an LLM because I didn't remember the details of when I was pondering this a while back)
All your anti cheats are eBPF programs hooked to the bpf() syscall itself.
Whenever any process tries to call BPF_PROG_DETACH or BPF_LINK_DETACH, your monitors check if the target is one of the anti cheats in your cluster of anti-cheats.
If an unauthorized process (even Root) tries to detach any of your anti-cheat processes, the eBPF program uses bpf_override_return to send an EPERM (Permission Denied) error back to the cheat.
(End LLM part)
Of course, you can always circumvent this by modifying and compiling the kernel so that those syscalls when targeting a specific PID/process name/UID aren't triggered. But this raises the difficulty of cheating a lot as you can't simply download a script, but you need to install and boot a custom kernel.
So this would solve the random user cheating on an online match. Pro users that have enough motivation can and will cheat anyway, but that is true also on windows. Finally at top gaming events there is so much scrutiny as you need to play on stage on vetted PCs that this is a non-issue
But given Linux kernel is monolithic and you can enforce signing of kernel modules too, using TPM to make sure the Kernel isn't tampered with is honestly the way to go.
Modern games already employ a bunch of VM-like techniques for tamper protection.
This has effectively killed PC game piracy.
First, let's ask ourselves how many PCs have users play games with anti-cheat frameworks. I'm absolutely no expert, but if it's more than, what? 10%? let's even say 20% - I'd be surprised.
> and unfortunately a good majority of the gaming industry by revenue relies on it.
Well, it used to be the case that game makers relied on copy protection in floppy discs, and movie distributors on DVD/BluRay copy protection. Conditions changed and they adapted.
The idea that you need intrusive surveillance in order to make games fair is absurd. If you need fair games, you need referees and moderation, which means you need to train and pay competent people and establish open and transparent rules and tools. You can also give your refs latitude, so if someone is obviously cheating, they have the power to do something about it. You should also require and implement publicly transparent and auditable actions with recourse for players to prevent abuses of power.
That's expensive. It's much easier to create a terms of service with vague guidelines, implement a totally intrusive, absurdly invasive rootkit that does some bare minimum scanning for known cheats and patterns, which establishes an arms race and provides bad actors a nice little point of ingress when the responsible company inevitably fails to protect their users competently.
Just like media platforms, if you cannot moderate at the scale at which you're operating, then it shouldn't be legal to operate at that scale.
People should stop giving money to companies that don't deserve it. No game is worth sacrificing your integrity for. "Just trust us, we know what we're doing" is a huge red flag, and it should be criminal to do what they do.
AI refs are going to be a very real possibility in the near future that can be just as fair and competent as humans, so the "necessity" for rootkits won't be a valid argument for much longer. It'll still be expensive, but multiplayer gaming fairness shouldn't ever serve as a reason for nuking privacy.
Stock price growth is their core business because that is how large firms operate.
MS used to embrace games etc because the whole point was all PCs should run Windows. Now the plan is to get you onto a subscription to their cloud. The PC bit is largely immaterial in that model. Enterprises get the rather horrible Intune bollocks to play with but the goal is to lock everyone into subs.
I thought all of them more or less have operated under Ponzinomics ever since Jack Welch showed that that worked in the short term.
I’m not really into this AI shenanigans, but it seems to me that if you want people to use /your/ bot, you gotta give it to people in the most seamless and efficient way possible, and that does not translate well to a desktop OS.
I don’t think they would have dethroned iOS or even Android had they stayed their ground, but they probably would’ve had a stronger base to build upon for their Copilot nonsense. Those that used Windows Phone used it because they loved it, Copilot could’ve garnered some good rep from those already sold on Microsoft’s platform; instead, they’re trying to shove it down people’s throats even though very few people actually use Windows because they actively like it, most use it because it’s the “default” OS and they do not (and care not to) know any better.
That resulted in Windows 8.
More recently they've freaked out about ads, app stores, and SaSS revenue, which has resulted in lots of dark patterns in the OS.
The one thing I haven’t been able to get working reliably is steam remote play with the Linux machine as host. Most games work fine, others will only capture black screens.
This is a far better user experience for Battlefield players than in Windows.
Have you ever actually attempted to play that half-assed buggy piece of shit?
The strength of Linux and Free software in general is not in that it's completely built by unpaid labor. It's built by a lot of paid, full-time labor. But the results are shared with everyone. The strength of Free software is that it fosters and enforces cooperation of all interested parties, and provides a guarantee that defection is an unprofitable move.
This is one of the reasons you see Linux everywhere, and *BSD, rarely.
I doubt it's a large reason. I'd put more weight on eg Linus being a great project lead and he happens to work on Linux. And a lot of other historical contingencies.
This flow is basically the bread and butter for the OSS community and the only way high effort projects get done.
Conventional companies just have a lot more money, and it's easier for them to internally 'coordinate' when they want something to get done.
That said, yes, there are certain things that the broader/volunteer FOSS community simply isn't any good at.
Granted, I don't play online games, so that might change things, but for years I used to have to make a concession that "yeah Windows is better for games...", but in the last couple years that simply has not been true. Games seem to run better on Linux than Windows, and I don't have to deal with a bunch of Microsoft advertising bullshit.
Hell, even the Microsoft Xbox One controllers work perfectly fine with xpad and the SteamOS/tenfoot interface recognizes it as an Xbox pad immediately, and this is with the official Microsoft Xbox dongle.
At this point, the only valid excuses to stay on Windows, in my opinion, are online games and Microsoft Office. I don't use Office since I've been on Unixey things so long that I've more or less just gotten used to its options, but I've been wholly unable to convince my parents to change.
I love my parents, but sometimes I want to kick their ass, because they can be a bit stuck in their ways; I am the one who is expected to fix their computer every time Windows decides to brick their computer, and they act like it's weird for me to ask them to install Linux. If I'm the one who has to perform unpaid maintenance on this I don't think it's weird for me to try and get them to use an operating system that has diagnostic tools that actually work.
As far as I can tell, the diagnostic and repair tools in Windows have never worked for any human in history, and they certainly have never worked for me. I don't see why anyone puts up with it when macOS and Linux have had tools that actually work for a very long time.
I didn’t see a performance increase moving to Linux for the vast majority of titles tested. Certainly not enough to outweigh the fact that I want EVERY game to work out of the box, and to never have to think if it will or won’t. And not all of my games did, and a not insignificant number needed serious tweaking to get working right.
I troubleshoot Linux issues all day long, I’ve zero interest in ever having to do it in my recreation time.
That’s a good enough reason for me to keep my windows box around.
I use Linux and OSX for everything that isn’t games, but windows functions just fine for me as a dumb console and I don’t seem to suffer any of these extreme and constant issues HN users seem to have with it from either a performance or reliability standpoint.
For some reason amongst other people, these bits of debugging just "don't count". I don't know why.
I have a console. They can not offer performance I can tolerate. I require 120+ fps for most titles in order to not get motion sickness from modern displays.
> I've had plenty of bullshit fighting with DLL files and registry keys to get games working on Windows in the past.
I've had no such fighting. Shit, the last time I touched a registry to "fix" anything in windows was probably XP.
> I don't know why.
Probably because not everyone has the same experience. None of the major operating systems is free of issue, but in the same vein, neither have caused me particularly more headaches than another.
Game studios will keep buying Windows and Visual Studio licenses, target DirectX, and let Valve do whatever they need for game content.
I firmly believe that Nvidia doesn't want the general public to ever have better hardware than what is current as people could just run their own local models and take away from the ridiculous money they're making from data centers.
In step they're now renting their gaming GPUs to players with their GeForce now package.
The market share for Nvidia of gamers is a rounding error now against ai datacenter orders. I won't hold my breath about them revisiting their established drivers for Linux.
You're underestimating them. They don't even want rich professional users to own hardware that could compete with their datacenter cash cow.
Take RTX 6000 Pro, a $10k USD GPU. They say in their marketing materials that these have fifth-generation tensor cores. This is a lie, as you can't really use any 5th-gen specific features.
Take a look at their PTX docs[1]. The RTX 6000 Pro is sm_120 in that table, while their datacenter GPUs are sm_100/sm110. See the 'tcgen05' instructions in the table? It's called 'tcgen05' because it stands for "Tensor Core GEN 05". And they're all unsupported on sm_120.
[1] - https://docs.nvidia.com/cuda/parallel-thread-execution/#rele...
EAC has the support for Linux, you just have to enable it as a developer.
I know this, I worked on games that used this. EAC was used on Stadia (which was a debian box) for the division, because the server had to detect that EAC was actually running on the client.
I feel like I bring this up all the time here but people don’t believe me for some reason.
This does not mean it supports the full feature set as from EAC on Windows. As an analogy, it's like saying Microsoft Excel supports iPad. It's true, but without VBA support, there's not going to be many serious attempts to port more complicated spreadsheets to iPad.
https://github.com/JacKeTUs/linux-steering-wheels
Hopefully vr headset support will get better
I haven’t found a tool that can access all the extra settings of my Logitech mouse, not my Logitech speakers.
OpenRGB is amazing but I’m stuck on a version that constantly crashes; this should be fixed in the recent versions but nixpkgs doesn’t seem to have it (last I checked).
On the other hand I did manage to get SteamVR somewhat working with ALVR on the Quest 3, but performance wasn’t great or consistent at all from what I remember (RTX 3070, Wayland KDE).
Alternatively, given you’re running NixOS you can just override the `src` of the derivation with a newer version. This is part of the point of running NixOS: making small modifications to packages in the fly.
I did try overriding the src for OpenRGB but as I’m on unstable, something else in the dependency chain must have broken as the post-install patches weren’t applying IIRC.
Wasn’t urgent but I’ll likely get back to it at some point.
You don’t want a vendor you have to publically shame to get them to do the right thing. And that’s MS if any single sentence has ever described them without using curse words.
Sadly, those exclusions are pretty big asks for the common folk. That's always what it comes down to. Some killer tool you need for whatever reason that either doesn't work on Linux, or is severely compromised.
I'm very comfortable with Linux, but my work still requires Unreal Engine. And good luck getting that going in Linux. So I'm stuck with dual booting at the bare minimum.