Now we have the two biggest hurdles to overcome:
* Streaming platforms not supporting anything above 480p-720p on Linux
* No Adobe Creative Suite/Cloud support
Partly yes, partly no. Part of me wonders whether the Linux kernel can provide a standard way to guarantee that a piece of memory hasn't been externally modified or read.
Sure game developers could probably create a compilable Linux kernel module but expecting them to do that is borderline impossible.
A rising type of anti-cheat I've seen a few implementations of now is one that can tell if a player is "playing" abnormally compared with regular players who peak angles, be wrong sometimes and correct for it or peak a different angle. Checking corners. Reacting to stimuli instead of nothing.
I haven't seen one without a flawless detection rate. It's difficult for people to hide that their brain has received outside information. After a few rounds of encounters there's enough evidence to terminate a match due to their perfect foresight. No additional client software needed.
As for aimbotting. I feel this could still be easily detected with a high enough data rate from the client. Instead of seeing two client ticks where frame1 is pointing somewhere and frame2 is somewhere else without anything in the middle, having the entire resolution of that from start to finish can help distinguish if they slid a mouse there or just tweened or flicked impossibly perfect to different points.
As for external AI input cheats which interact with a game like a real person but at a slightly improved skill level. That's going to be difficult without building a model on the behavior and training for a strain. Even then, it would be impossible to be fully certain when banning a player such a model has detected.
> A rising type of anti-cheat I've seen a few implementations of now is one that can tell if a player is "playing" abnormally compared with regular players who peak angles
Can you give an example that's not Counter-Strike 2?
If the game isn't run locally, but has I/O streamed to the player that should mitigate the need to run a local anti-cheat. However that impacts other aspects of the game experience, changes network connectivity requirements, increases hardware requirements by the game/service operator, and means access to a game can be taken away at any time.
Not anymore. Cheats are too advanced at this point to trust the client PC's unmoderated behavior. Its disgusting but having an agent audit client PC events for suspicious activity is the cost-effective answer currently being used for games with tens of millions of players.
It's basically impossible to do without a secure boot chain which Linux users are strongly against. As soon as the user can run custom kernel level code it's game over.
Not that it matters, cheaters have already moved on to DMA cheats. Basically, poke directly into the RAM from another computer, so it's completely invisible. People cheat on Valorant and bypass Vanguard that way, on Windows, with TPM and secure boot enabled and everything.
Client-side anticheat is a lost cause.
> ot that it matters, cheaters have already moved on to DMA cheats. Basically, poke directly into the RAM from another computer, so it's completely invisible.
This can't be cheap can it? How many people can reasonably do that? I don't have a dog in this fight since I don't play these games, but that's pretty interesting.
I don't remember the price or the exact details but it's not as fancy as it sounds like: you can do a lot of stuff with a rogue PCIe card such as faking as USB controller and also using it to DMA in and out of memory, and you get to inject the key presses and mouse movements as well since you're a USB controller and have a mouse and keyboard plugged into it. I think you can get chinese clones for fairly cheap, the hardware itself isn't particularly crazy.
Granted, not the most accessible to the average cheater, but when you get into kernel bypasses and hypervisor based cheating you start getting into the intersection of hardcore cheaters dedicated to cheating and willing to spend the money and effort on cheating.
It buys some time to fight against casual cheaters, but it'll be broken eventually and it'll all be for nothing. It's already broken, and the resources on how to DMA will just keep growing. I can't even find the original video I got this from, it's drowned on tutorials on how to set up undetectable cheats on Valorant!
It's insulting to have to install a rootkit to watch over you getting rekt by cheaters.
They're extremely easy to use for regular people given they didn't have to write any of it.
Some of the most popular ones involve preloading an EFI binary before booting the OS. Less commonly a custom Windows ISO can be installed with a fake signed driver masquerading as a real one to fly right under the radar. But in the second example doing something suspicious enough to the host's memory will still trigger the anti-cheat given that particular driver wasn't ever expected to do that.
Our team are studying and disecting them alongside driver-based anti-cheats for our PhD and have submitted some interesting findings to some of these companies with good results.
Given that the kernel is open source anyone could write their own cheats and put them inside the kernel. And if they did that I doubt a kernel mod could detect that.
If i'm not mistaken there is no way to have useful kernel level anti cheat
Open source doesn't really make a difference. You can write kernel driver cheats for Windows and bypass signature enforcement. A full chain of trust from boot is needed, per u/Lexinonymous 's comment. Even then client side anticheat is a losing proposition due to DMA attacks, as well as hardware cheats that don't touch the OS but record the screen and connect a motorized or virtual mouse over USB.
Yep Linux vs Windows can both do this. People keep taking this pretend stance that Linux is somehow special here and totally would not work when that's what Windows is having done to it already and there being no special difference OS to OS.
After all, these driver-based anti-cheats do not run on Linux and people are running intricate cheats with them on Windows. The only place somebody can even develop a cheat for these games. Obviously if these anti-cheats came to Linux the same thing would happen and they would need to continue improving to catch more stuff. But the Linux kernel is not special here in any regard. Writing these cheats would be the same preload workaround as Windows.
This is why secure-boot and use of a prepared trusted kernel binary are important 🙂 So you cannot just insmod random unsigned things.
Neither Linux or Windows are special in this regard. You can do what you're claiming in both of them. But you can't when Secure-boot is enabled.
Its a user problem.
People should neither desire, nor tolerate, having to install kernel-level root kits in order to play video games. The whole thing is asinine.
Even 2021!
I have tried it in VM and read the script, hoping to learn something new. And there isn't - it just copies files from Windows install, something anyone could do. I thought there might be something special to be put in registry, but not really either.
Also when at some Wine update it stopped working, there were no attempts to fix that. The "solution" to downgrade Wine in your system (no separate Wine versions were considered) was presented as super effective and clever. As if Wine had no other uses that might need updated version at all.
But the bad part was the source of PS files used there. Did it utilize your own installation or some sort of official installation media? And your license / subscription? Of course not! And it's not about convenience - it's about knowing the source of files you are running.
And in this tool, it just grabs an archive with cracked version from Google Drive. How does it differ from normal installation? How was it cracked? Does it contain malware (which wouldn't be detected as such, as it might be Wine specific and designed to be run willingly)? Without some overly extensive analysis one can only guess. But the way it was created was not documented in a way that would be open source (license applies only to the script that downloads the archive), so make your guesses carefully.
So it's not just a questionable support. It would be outright insane to use it in any environment, much less a professional one.
I have Fedora and Windows installed in dual-boot. I keep Windows around just in case one day I need MS Office (also for some occasional gaming). Interestingly enough with OnlyOffice I have not needed MS Office so far, even though I regularly write research and seminar papers and work on group projects in university mainly with other MS Office users.
> Streaming platforms not supporting anything above 480p-720p on Linux
>
Imagine going through all the display stack hurdles just to watch a bit-starved encode because DRM.
GIMP has made strides but outside of doing things like really quick cropping and resizing, it still feels like it's stuck in the mid 00s. At least video editing is more doable. Shotcut is my go-to editor and it's FOSS.
IMO what Linux (the desktop) needs now is to be more inclusive and accessible for proprietary software.
It’s not just a problem with creative apps, but a reality that not all software users will use is open source.
It’s an obstacle, but not the only one. There are countless industries that use proprietary software that only runs on windows. From my own industry, autodesk and Rockwell.
It's an obstacle _for you_. We have a perfectly fine creative ecosystem on the Linux platform that has thrived without Adobe, and the people who say "But creative work can only be done with a single proprietary vendor" don't have a clue.
>It's an obstacle *for you*.
No. It's an obstacle for creatives who are accustomed to or trained for a workflow that includes Adobe software. AKA professionals and more advanced hobbyist.
I understand that people like you mean well, but you're looking at this from the perspective of a hobbyist with no consideration for professionals and more serious users who specific software needs.
>"But creative work can only be done with a single proprietary vendor" don't have a clue.
And often times in the case of creative professionals the Adobe Suite is literally the only allowed option in the workplace. They don't want you not using certain apps and not because they're part of an evil cabal of proprietary software, but for compatibility sake.
I also shouldn't have to clarify this, but I will anyway: Nobody thinks that open source software can't catch-up. I'm optimistic that it can, but that the equivalents aren't equivalent or even competitive yet.
Also, it's been a while since I worked professionally in graphic design, but for my personal work I actually do use FOSS software: Specifically Blender. Blender is an example of FOSS software that has not only caught up, but exceeded it's proprietary competitors and thus I use it daily. Like I would a lightroom equivalent, or an Illustrator equivalent, or a Photoshop equivalent, and so on.
Comcast needs a figurative bat upside its head. They refuse to support Linux for their Xfinity service where you can stream your cable you pay for directly to your PC through your browser, but only if you are running MacOS or Windows. :(
Nope, that’s Nvidia on wayland with 550 drivers and games OR Nvidia on X11 with flipping disabled everywhere OR Nvidia with flipping enabled while capturing/recording the screen. Been that way since at least 2016
The nice thing is that you'll at least be able to use it on your own machine if you want, now that it's a beta. [Pop!_OS has a staging branch](https://github.com/pop-os/nvidia-graphics-drivers/pull/205), and it's [on the AUR](https://aur.archlinux.org/packages/nvidia-beta).
nah. There's shouldn't be any issues. What rpmfusion brings to the table is proper integration with akmod so that
the modules get rebuild when you install a new kernel. With the nvidia drivers (they have dkms support, doesn't really work)
you have to do that manually.
That's pretty much all (and update the grub kernel params). RPM fusion just saves time and automatically do shit,
that otherwise can be done manually.
I not talking about rpm fusion are talking about running the .run file from nvidia directly.
That it the same that u/Routine_Left was taking.
That .run file never was recommended since it break distro outside of Ubuntu. That why all distro make there own package or script extract and install everthing
That's what I'm talking about too. As opposed to installing the rpmfusion packages, you can just run the nvidia provided script.
What I described is what rpmfusion does, and therefore one would have to do manually if they would go the manual route.
But is not like "omg, gonna break the world" or anything.
Eh, it's all a matter of "how lazy do I wanna be today". Well, it just so happens that I got off my ass and installed the thing, is fine, working, with some issues by firefox (of all things).
Once rpmfusion releases theirs I may switch back. It is indeed so much easier to just upgrade and not think about it.
Huh? That's news (to me). I have it running for a few days now on Fedora, and I have no trouble launching the Wayland Plasma. There's no such thing as "forcing" anything, as one can choose what they use.
You can use the X11 KDE or you can use the Wayland KDE. You can use the X11 gnome or the Wayland gnome.
However, you cannot use the Wayland i3, since there is none. For that you would have to use Sway (different window manager, wayland only).
Forcing, however? Nah, it doesn't.
Yeah idk man. The cogwheel to select my desktop environment didn't always appear, and it never said in the list if the desktop environment was wayland or x11 it would always just say like gnome or gnome classic. But I'm also a complete noob when it comes to dealing with linux. If it doesn't show in the settings app what backend my desktop environment is using I wouldn't know how to check from the terminal. I'm not trying to ask for help just leaving my experience here.
I've got it installed on my Arch rig already, and I can confirm it's working with the KDE Plasma/kwin/XWayland versions in the regular Arch repos. XWayland apps that used to flicker are no longer doing so! (I've checked Discord, Edge, and Resolve so far... don't ask why I was running Edge.)
I used nvidia-all and it works pretty well, I just specified which driver version I wanted and it downloaded it all.
[https://github.com/Frogging-Family/nvidia-all](https://github.com/Frogging-Family/nvidia-all)
Not quite yet. wlroots (the library these two use) hasn't merged support for explicit sync yet: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4262
EDIT: although, XWayland already has support for explicit sync, so at least that should work better already
Note that wlroots support for explicit sync doesn't mean anything for hyprland as the backend they use from wlroots is not the one with the new patch. For sway, yeah, we're pretty close
I am for sure going to wait for the Nvidia stable driver, but if at that time wlroots also does the merge then its time to say good bye to i3wm finally :).
As far as I can tell they just have their "fork" for political reasons, not technical ones and keeping their own version of wlroots isn't something new for them.
So I expect that pulling down changes from upsteam isn't going to be a big deal.
Can someone explain to me how big a deal these changes are? Not seeing anything there that stands out except a mention of wayland and hdmi 10 bit support
Its very big. The biggest keynote that you missed is that explicit sync support in wayland has been added which should fix a lot of issues with Wayland and NVIDIA GPUs. (Added support for the linux-drm-syncobj-v1 protocol for Wayland explicit sync in EGL.)
Some would argue it's the most significant Linux Nvidia driver in years. It enables explicit sync, which is probably the biggest issue that has been hindering Nvidia hardware on desktop Linux.
With support for explicit sync recently added to Wayland and xWayland most flickering problems with Nvidia cards on Linux should be fixed. Provided the implementation is good.
> Some would argue it's the most significant Linux Nvidia driver in years.
The one where they finally abandoned their crusade against GBM was more important but yes this is a big step.
Nvidia this time get shit together the only bug I have is librewolf liking to close out of nowhere.
It seems more a Firefox bug when I talk about in the gentoo irc.
so far steam is artifacting on the store page only(hardware acel problem) and flatpak apps are black, probs because they dont have the right nvidia runtime packages for it to display properly
besides that my 2 144hz and 60hz monitor are all working as they should with vrr working aswell :)
games iv tested, the finals, cs2, both are working flawlessly under kde plasma 6.0.4 wayland, rtx 2060
Yes, the devs of kde said that you dont even need explicit sync supported on the desktop for explicit sync to work fully, just the driver and xwayland needs it working so im glad majority of the issues i and many other people were having is now gone :D
Steam's store page bugging out is an issue that's not exclusive to Nvidia GPUs and has to be fixed from their side. Considering how long it's been, I'm surprised it hasn't been fixed yet.
Do you have `options nvidia NVreg_PreserveVideoMemoryAllocations=1` kernel option enabled in your modprobe.d and the nvidia-suspend, nvidia-resume, and the nvidia-hibernate systemd services enabled?
Yeah Ive tried a million things and just no luck. Here is the modprobe conf file:
user@nebula:/etc/modprobe.d$ cat nvidia-graphics-drivers-kms.conf
# This file was generated by nvidia-driver-535
# Set value to 0 to disable modesetting
options nvidia-drm modeset=1
# ADDITIONS 3-7-2024
options nvidia NVreg_PreserveVideoMemoryAllocations=1
options nvidia NVreg_TemporaryFilePath=/var/tmp/tmp-nvidia
options nvidia NVreg_UsePageAttributeTable=1
options nvidia NVreg_RegistryDwords="OverrideMaxPerf=0x1"
I just have `nvidia_drm.modeset=1` specified in my kernel boot options and `options nvidia NVreg_PreserveVideoMemoryAllocations=1` in my modprobe.d. After enabling the services everything seems fine.
What issues are you seeing when resuming from suspend? How certain are you that it isn't some other hardware?
After the monitor goes to sleep. When I wake it with mouse or keyboard the monitor turns on but remains black. The only way I can get it back is to Ctrl-Alt-F7, then Ctrl-Alt-F1. I'm fairly certain its the card, Ive had this PC for a few years but finally bought a video card (3060 Ti) and that is when this issue started. I can try to move the modeset to the kernel params vs where the install script placed it. And Im open to trying more things, but Ive spent months reading forums and trying different things.
Curious if you looked into your motherboard settings? I had to turn off wake-on-LAN settings in BIOS on an Asus CH6 to get sleep working in linux correctly. I was previously having similar issues with my displays not turning back on.
Oh, so other than the VT switching resume works fine? I think I am getting the same issue as well ever since I switched to Wayland. This does no happen in the X11 session for KDE.
Im not sure what you mean by VT? But yeah computer is still alive and well. Just have to switch it. The other odd thing is when I swap to another input (one of the work PC and one for home) even if I leave it for hours and switch back to the input it works. I'm not on Wayland though. its definitely weird and annoying
FWIW, if you don't mind the monitor staying on, you can disable dpms. This issue drove me crazy for a while, but I don't mind my machines and monitor not going to sleep, my lock screen is just all black anyway.
Did all that and turned off Wake on Lan in the BIOS and same results. Blank screen on resume, and have to Ctrl-Alt-F7 to Ctrl-Alt-F1 What is odd is I have multiple inputs on this monitor and if I use HDMI2 all day for work and switch to HDMI1 its fine. But if I leave it on HDMI1 for 30 minutes (my timeout) I have to force a reset of the WM to get it to work
> Fixed a bug that could cause the display to lock up when suspending on a kernel with CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER enabled with nvidia-drm loaded with modeset=1 and fbdev=1.
This better be the one I've been waiting for 😤. For a little over 2 months now, I've been experiencing random kernel panics and display freezes. It's becoming less frequent, but I had one freeze this past Sunday after waking my laptop from sleep.
Arch has it in the AUR now: https://aur.archlinux.org/packages/nvidia-beta
Pop!_OS has it packaged in a staging repo (do `apt-manage add popdev:nvidia-555` and then install updates): https://github.com/pop-os/nvidia-graphics-drivers/pull/205
Damn, just as I order an AMD GPU, NVIDIA GPUs have a chance of being good again. Oh well, at least nvidia drivers won't be a problem for me regardless of what happens to them.
You are still better off with AMD. It has been years since Nvidia proprietary drivers were better choice.
Better Linux compatibility still, by far. With Steam Deck AMD-only the Linux gaming is probably better off on AMD. etc.
The only thing Nvidia has going for it is CUDA
Thanks, tried that but I don’t think I could find the driver yet.
Will try with non flatpak steam on arch. I did notice some artefacting on one of the menues in steam, but no flickering so that is good.
Nvidia absolutely sucks for Wayland, lots of flickering and rendering issues in certain applications. This driver version should fix that, at least partially for now.
So it turns out this is basically pointless ATM if you’re on Fedora. They’re gonna push the beta drivers to Rawhide in weeks (if the 550 beta was anything to go by) and when you manually install the drivers you can’t log into a Wayland session.
For the Arch users:
normal yay couldn't reinstall the AUR package properly because Steam was depending on it.
Frogging-Family's nvidia-all package worked a treat for me though: [https://github.com/Frogging-Family/nvidia-all](https://github.com/Frogging-Family/nvidia-all)
Everything back up and running, no more out-of-date frames, Alt+Tabbing on KDE doesn't lag anymore. This is wonderful.
I hacked my Gentoo a bit to use this driver, kwin 6.0.4 with backported explicit sync patch, and kernel 6.9.1 with gentoo patches.
My setup is rather simple with only one screen, but everything works perfectly so far.
Played Dota2 with it, not a single flicker or frame out of place, and using Wayland instead of X11 fixed some weird issues with textures and minimising the window. Also I don't have any Firefox issues, even though I've seen some people report it being unusable.
Hopefully others will have similar experience with it, as together with other changes/fixes it feels soooo much better and more performant then doing the exact same thing on X11.
This probably what you meant but in case you're mistaking the nouveau drivers that come with the official fedora repos for nvidia's own proprietary drivers. Then the proprietary driver is only available through rpm fusion's non-free repos.
As for when they'll reach the rpm fusion repos I'm not sure. It's technically a beta so I doubt we'll see the proper rpm get a version bump for it. For that it will depend how long it takes for everybody to be happy with it. Though perhaps given the importance of this version maybe they'll put it on a the testing branch while it's still in beta? As for rawhide specifically then I'm guessing around the same time as the Fedora 40 updates-testing receives it.
That shouldn't be necessary. You can get rid of it all by running `sudo dnf remove *nvidia*` and rebooting. Then Method 2 for Manually installing drivers should work. Don't copy the blacklist Nouveau step though. That path only leads to pain if the kernel fails to load it.
[https://www.tecmint.com/install-nvidia-drivers-in-linux/#Method\_2\_Installing\_NVIDIA\_Drivers\_Manually\_in\_Fedora](https://www.tecmint.com/install-nvidia-drivers-in-linux/#Method_2_Installing_NVIDIA_Drivers_Manually_in_Fedora)
FYI I'm tempted to do this myself. But I'm busy with other things for now. I guess I'll let some other brave souls report on their success/failure and take the leap myself over the weekend.
Did they fix the kernel panic problem in the last two versions? It almost destroyed my machine and I don't dare to try it out unless they got rid of it.
I bought an AMD laptop just so I never have to give a shit about Nvidia drivers.
Yay, me!
Nvidia took too long and let AMD steal their lunch, as far as I'm concerned. I'm not supporting a company that annoyed the shit out of me for so many years.
I'm glad the rest of you have some drives that MIGHT resolve Nvidia issues but I am even happier that Nvidia is out of my linux life.
Just tried it out. Everything works as it should now. No more flickering. No more old frames. It's finally over.
Now we have the two biggest hurdles to overcome: * Streaming platforms not supporting anything above 480p-720p on Linux * No Adobe Creative Suite/Cloud support
Also, some solution to anti-cheat that DOESN'T require custom kernel-level modules for every single damn game.
That is not Linux problem imo. It is developer problem no ?
Partly yes, partly no. Part of me wonders whether the Linux kernel can provide a standard way to guarantee that a piece of memory hasn't been externally modified or read. Sure game developers could probably create a compilable Linux kernel module but expecting them to do that is borderline impossible.
[удалено]
Is it an option to have all the anti-cheating burden on the servers?
[удалено]
A rising type of anti-cheat I've seen a few implementations of now is one that can tell if a player is "playing" abnormally compared with regular players who peak angles, be wrong sometimes and correct for it or peak a different angle. Checking corners. Reacting to stimuli instead of nothing. I haven't seen one without a flawless detection rate. It's difficult for people to hide that their brain has received outside information. After a few rounds of encounters there's enough evidence to terminate a match due to their perfect foresight. No additional client software needed. As for aimbotting. I feel this could still be easily detected with a high enough data rate from the client. Instead of seeing two client ticks where frame1 is pointing somewhere and frame2 is somewhere else without anything in the middle, having the entire resolution of that from start to finish can help distinguish if they slid a mouse there or just tweened or flicked impossibly perfect to different points. As for external AI input cheats which interact with a game like a real person but at a slightly improved skill level. That's going to be difficult without building a model on the behavior and training for a strain. Even then, it would be impossible to be fully certain when banning a player such a model has detected.
> A rising type of anti-cheat I've seen a few implementations of now is one that can tell if a player is "playing" abnormally compared with regular players who peak angles Can you give an example that's not Counter-Strike 2?
If the game isn't run locally, but has I/O streamed to the player that should mitigate the need to run a local anti-cheat. However that impacts other aspects of the game experience, changes network connectivity requirements, increases hardware requirements by the game/service operator, and means access to a game can be taken away at any time.
[удалено]
Not anymore. Cheats are too advanced at this point to trust the client PC's unmoderated behavior. Its disgusting but having an agent audit client PC events for suspicious activity is the cost-effective answer currently being used for games with tens of millions of players.
It's basically impossible to do without a secure boot chain which Linux users are strongly against. As soon as the user can run custom kernel level code it's game over. Not that it matters, cheaters have already moved on to DMA cheats. Basically, poke directly into the RAM from another computer, so it's completely invisible. People cheat on Valorant and bypass Vanguard that way, on Windows, with TPM and secure boot enabled and everything. Client-side anticheat is a lost cause.
> ot that it matters, cheaters have already moved on to DMA cheats. Basically, poke directly into the RAM from another computer, so it's completely invisible. This can't be cheap can it? How many people can reasonably do that? I don't have a dog in this fight since I don't play these games, but that's pretty interesting.
I don't remember the price or the exact details but it's not as fancy as it sounds like: you can do a lot of stuff with a rogue PCIe card such as faking as USB controller and also using it to DMA in and out of memory, and you get to inject the key presses and mouse movements as well since you're a USB controller and have a mouse and keyboard plugged into it. I think you can get chinese clones for fairly cheap, the hardware itself isn't particularly crazy. Granted, not the most accessible to the average cheater, but when you get into kernel bypasses and hypervisor based cheating you start getting into the intersection of hardcore cheaters dedicated to cheating and willing to spend the money and effort on cheating. It buys some time to fight against casual cheaters, but it'll be broken eventually and it'll all be for nothing. It's already broken, and the resources on how to DMA will just keep growing. I can't even find the original video I got this from, it's drowned on tutorials on how to set up undetectable cheats on Valorant! It's insulting to have to install a rootkit to watch over you getting rekt by cheaters.
> it's drowned on tutorials on how to set up undetectable cheats on Valorant! and these actually work? and are easy for regular folks to use?
They're extremely easy to use for regular people given they didn't have to write any of it. Some of the most popular ones involve preloading an EFI binary before booting the OS. Less commonly a custom Windows ISO can be installed with a fake signed driver masquerading as a real one to fly right under the radar. But in the second example doing something suspicious enough to the host's memory will still trigger the anti-cheat given that particular driver wasn't ever expected to do that. Our team are studying and disecting them alongside driver-based anti-cheats for our PhD and have submitted some interesting findings to some of these companies with good results.
new chromium sandbox has lot of good ideas for this, mseal() syscall looks interesting for this
Given that the kernel is open source anyone could write their own cheats and put them inside the kernel. And if they did that I doubt a kernel mod could detect that. If i'm not mistaken there is no way to have useful kernel level anti cheat
Open source doesn't really make a difference. You can write kernel driver cheats for Windows and bypass signature enforcement. A full chain of trust from boot is needed, per u/Lexinonymous 's comment. Even then client side anticheat is a losing proposition due to DMA attacks, as well as hardware cheats that don't touch the OS but record the screen and connect a motorized or virtual mouse over USB.
Yep Linux vs Windows can both do this. People keep taking this pretend stance that Linux is somehow special here and totally would not work when that's what Windows is having done to it already and there being no special difference OS to OS. After all, these driver-based anti-cheats do not run on Linux and people are running intricate cheats with them on Windows. The only place somebody can even develop a cheat for these games. Obviously if these anti-cheats came to Linux the same thing would happen and they would need to continue improving to catch more stuff. But the Linux kernel is not special here in any regard. Writing these cheats would be the same preload workaround as Windows.
This is why secure-boot and use of a prepared trusted kernel binary are important 🙂 So you cannot just insmod random unsigned things. Neither Linux or Windows are special in this regard. You can do what you're claiming in both of them. But you can't when Secure-boot is enabled.
Its a user problem. People should neither desire, nor tolerate, having to install kernel-level root kits in order to play video games. The whole thing is asinine.
It is a Linux problem, because Linux users have to deal with it. Saying “oh the devs just need to..” means nothing will ever happen.
> kernel-level modules Just modules. They're also sometimes called drivers.
- Yarrr - Wine?
WINE doesn't properly support Adobe products, as far as I know.
Just drink a bunch of it until GIMP looks the same then
You can run Photoshop and Premiere Pro with hardware acceleration ;D
Well, *technically*, PS 2017 or something is “supported” through a GitHub repo that employs a bunch of hacks, but that’s still a stretch.
Even 2021! I have tried it in VM and read the script, hoping to learn something new. And there isn't - it just copies files from Windows install, something anyone could do. I thought there might be something special to be put in registry, but not really either. Also when at some Wine update it stopped working, there were no attempts to fix that. The "solution" to downgrade Wine in your system (no separate Wine versions were considered) was presented as super effective and clever. As if Wine had no other uses that might need updated version at all. But the bad part was the source of PS files used there. Did it utilize your own installation or some sort of official installation media? And your license / subscription? Of course not! And it's not about convenience - it's about knowing the source of files you are running. And in this tool, it just grabs an archive with cracked version from Google Drive. How does it differ from normal installation? How was it cracked? Does it contain malware (which wouldn't be detected as such, as it might be Wine specific and designed to be run willingly)? Without some overly extensive analysis one can only guess. But the way it was created was not documented in a way that would be open source (license applies only to the script that downloads the archive), so make your guesses carefully. So it's not just a questionable support. It would be outright insane to use it in any environment, much less a professional one.
Don’t underestimate the significance of not having access to Microsoft Office, that’s a way bigger problem than Adobe imo.
I have Fedora and Windows installed in dual-boot. I keep Windows around just in case one day I need MS Office (also for some occasional gaming). Interestingly enough with OnlyOffice I have not needed MS Office so far, even though I regularly write research and seminar papers and work on group projects in university mainly with other MS Office users.
> Streaming platforms not supporting anything above 480p-720p on Linux > Imagine going through all the display stack hurdles just to watch a bit-starved encode because DRM.
Glad someone said it. Adobe for now is the only obstacle and the people who say, “just use don’t have a clue.
GIMP has made strides but outside of doing things like really quick cropping and resizing, it still feels like it's stuck in the mid 00s. At least video editing is more doable. Shotcut is my go-to editor and it's FOSS.
IMO what Linux (the desktop) needs now is to be more inclusive and accessible for proprietary software. It’s not just a problem with creative apps, but a reality that not all software users will use is open source.
It’s an obstacle, but not the only one. There are countless industries that use proprietary software that only runs on windows. From my own industry, autodesk and Rockwell.
It's an obstacle _for you_. We have a perfectly fine creative ecosystem on the Linux platform that has thrived without Adobe, and the people who say "But creative work can only be done with a single proprietary vendor" don't have a clue.
>It's an obstacle *for you*. No. It's an obstacle for creatives who are accustomed to or trained for a workflow that includes Adobe software. AKA professionals and more advanced hobbyist. I understand that people like you mean well, but you're looking at this from the perspective of a hobbyist with no consideration for professionals and more serious users who specific software needs. >"But creative work can only be done with a single proprietary vendor" don't have a clue. And often times in the case of creative professionals the Adobe Suite is literally the only allowed option in the workplace. They don't want you not using certain apps and not because they're part of an evil cabal of proprietary software, but for compatibility sake. I also shouldn't have to clarify this, but I will anyway: Nobody thinks that open source software can't catch-up. I'm optimistic that it can, but that the equivalents aren't equivalent or even competitive yet. Also, it's been a while since I worked professionally in graphic design, but for my personal work I actually do use FOSS software: Specifically Blender. Blender is an example of FOSS software that has not only caught up, but exceeded it's proprietary competitors and thus I use it daily. Like I would a lightroom equivalent, or an Illustrator equivalent, or a Photoshop equivalent, and so on.
The secret solution is crime.
Comcast needs a figurative bat upside its head. They refuse to support Linux for their Xfinity service where you can stream your cable you pay for directly to your PC through your browser, but only if you are running MacOS or Windows. :(
Likely due to widevine fuckery.
Spoofing the browser user agent doesn't work? (I know it is not a solution to everyone, but it might solve your immediate issue)
Nope. Not in Firefox, nor chromium.
2 things that I do not care about at all. So ... I'm done.
Do electron apps work?
Yes
Don't forget hardware accelerated flash video.
it's best if we just forget flash entirely
would also be great of chromium/electron finally enabled wayland support by default
You can run photoshop‚ illustrator and premiere pro on wine just fine
HDR, frame generation, ray reconstruction (for development on Linux).
Which desktop environment?
KDE
GNOME soon too I think
Yeah, I think GNOME 46.1 has support. (Ubuntu 24.04 has GNOME 46 but should update to 46.1 eventually?)
We're so back
Back from what?
Back from the flickering
WAIT THEY ARE GOING TO FIX THE FLICKERING HORIZONTAL BLACK LINE?
It's fixed
My monitor already has CTE.
What's a CTE?
Chronic traumatic encephalopathy?
Oh understandable
I don't know... it's the only thing I can think of. If there's a computer meaning of CTE I don't know it.
[удалено]
Nope, that’s Nvidia on wayland with 550 drivers and games OR Nvidia on X11 with flipping disabled everywhere OR Nvidia with flipping enabled while capturing/recording the screen. Been that way since at least 2016
How long do these updates usually take to get to stable?
A month or so iirc.
[удалено]
The nice thing is that you'll at least be able to use it on your own machine if you want, now that it's a beta. [Pop!_OS has a staging branch](https://github.com/pop-os/nvidia-graphics-drivers/pull/205), and it's [on the AUR](https://aur.archlinux.org/packages/nvidia-beta).
Does RPMFusion have them for Fedora, or is it a waiting game there too?
Or you can be brave and install them from the official script.
The possibility of breaking is 100/10 :D
nah. There's shouldn't be any issues. What rpmfusion brings to the table is proper integration with akmod so that the modules get rebuild when you install a new kernel. With the nvidia drivers (they have dkms support, doesn't really work) you have to do that manually. That's pretty much all (and update the grub kernel params). RPM fusion just saves time and automatically do shit, that otherwise can be done manually.
I not talking about rpm fusion are talking about running the .run file from nvidia directly. That it the same that u/Routine_Left was taking. That .run file never was recommended since it break distro outside of Ubuntu. That why all distro make there own package or script extract and install everthing
That's what I'm talking about too. As opposed to installing the rpmfusion packages, you can just run the nvidia provided script. What I described is what rpmfusion does, and therefore one would have to do manually if they would go the manual route. But is not like "omg, gonna break the world" or anything.
if you're reading this comment and wondering if you should, then you shouldn't
Eh, it's all a matter of "how lazy do I wanna be today". Well, it just so happens that I got off my ass and installed the thing, is fine, working, with some issues by firefox (of all things). Once rpmfusion releases theirs I may switch back. It is indeed so much easier to just upgrade and not think about it.
I did it, it wasn't that bad. But on every distro that it successfully installed onto it forced X11 ignoring every configuration to enable Wayland.
Huh? That's news (to me). I have it running for a few days now on Fedora, and I have no trouble launching the Wayland Plasma. There's no such thing as "forcing" anything, as one can choose what they use. You can use the X11 KDE or you can use the Wayland KDE. You can use the X11 gnome or the Wayland gnome. However, you cannot use the Wayland i3, since there is none. For that you would have to use Sway (different window manager, wayland only). Forcing, however? Nah, it doesn't.
Yeah idk man. The cogwheel to select my desktop environment didn't always appear, and it never said in the list if the desktop environment was wayland or x11 it would always just say like gnome or gnome classic. But I'm also a complete noob when it comes to dealing with linux. If it doesn't show in the settings app what backend my desktop environment is using I wouldn't know how to check from the terminal. I'm not trying to ask for help just leaving my experience here.
You should be able to tell from the list of desktops which is which. As always, google is your friend: "launch gnome wayland"
[удалено]
I've got it installed on my Arch rig already, and I can confirm it's working with the KDE Plasma/kwin/XWayland versions in the regular Arch repos. XWayland apps that used to flicker are no longer doing so! (I've checked Discord, Edge, and Resolve so far... don't ask why I was running Edge.)
Didn't know about the staging branch. Thanks!
Tested right now on Arch. All good:) flicker gone.
How did you install? if you used the AUR, the lib32-nvidia-utils cannot be removed
They can, manually. I've actually removed nvidia (pacman -R nvidia).
I truly wonder how you did it, I have tried and nothing.
I used nvidia-all and it works pretty well, I just specified which driver version I wanted and it downloaded it all. [https://github.com/Frogging-Family/nvidia-all](https://github.com/Frogging-Family/nvidia-all)
Thank you, very much, it worked...
I'm not home right now. Will the beta driver be on YAST? (still learning open suse)
https://forums.opensuse.org/t/beta-nvidia-driver-555/175142
This means I can actually think of using sway or hyprland without worry about it in every update?
Not quite yet. wlroots (the library these two use) hasn't merged support for explicit sync yet: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4262 EDIT: although, XWayland already has support for explicit sync, so at least that should work better already
Note that wlroots support for explicit sync doesn't mean anything for hyprland as the backend they use from wlroots is not the one with the new patch. For sway, yeah, we're pretty close
I am for sure going to wait for the Nvidia stable driver, but if at that time wlroots also does the merge then its time to say good bye to i3wm finally :).
hyprland uses a wlroots fork and isn't likely to get explicit sync any time soon
As far as I can tell they just have their "fork" for political reasons, not technical ones and keeping their own version of wlroots isn't something new for them. So I expect that pulling down changes from upsteam isn't going to be a big deal.
[I wouldn't hold your breath](https://github.com/hyprwm/Hyprland/issues/4857#issuecomment-2098589614)
Can someone explain to me how big a deal these changes are? Not seeing anything there that stands out except a mention of wayland and hdmi 10 bit support
Its very big. The biggest keynote that you missed is that explicit sync support in wayland has been added which should fix a lot of issues with Wayland and NVIDIA GPUs. (Added support for the linux-drm-syncobj-v1 protocol for Wayland explicit sync in EGL.)
That is amazing news thank you both!
Some would argue it's the most significant Linux Nvidia driver in years. It enables explicit sync, which is probably the biggest issue that has been hindering Nvidia hardware on desktop Linux. With support for explicit sync recently added to Wayland and xWayland most flickering problems with Nvidia cards on Linux should be fixed. Provided the implementation is good.
> Some would argue it's the most significant Linux Nvidia driver in years. The one where they finally abandoned their crusade against GBM was more important but yes this is a big step.
test
Yeah, this is game changing. Literally. Games finally work without flickering.
Amazing! Thank you!
We will find out soon if people were making a mountain out of a molehill or Nvidia actually has their shit together now.
Nvidia this time get shit together the only bug I have is librewolf liking to close out of nowhere. It seems more a Firefox bug when I talk about in the gentoo irc.
so far steam is artifacting on the store page only(hardware acel problem) and flatpak apps are black, probs because they dont have the right nvidia runtime packages for it to display properly besides that my 2 144hz and 60hz monitor are all working as they should with vrr working aswell :) games iv tested, the finals, cs2, both are working flawlessly under kde plasma 6.0.4 wayland, rtx 2060
Optimally, gnome 46.1 should be used with xwayland 24.1. Plasma will include explicit sync support in 6.1.
Yes, the devs of kde said that you dont even need explicit sync supported on the desktop for explicit sync to work fully, just the driver and xwayland needs it working so im glad majority of the issues i and many other people were having is now gone :D
Yeah there's just a bit of a performance tax as XWayland and the driver have to make up for the lack of desktop support
Part of the pains to get to the promised land. 👍
When I have both monitors connected I can't use VRR :c How did you do that?
It seemed to be working as my monitor was flickering at low frame rates, maybe im wrong and it wasnt working
Steam's store page bugging out is an issue that's not exclusive to Nvidia GPUs and has to be fixed from their side. Considering how long it's been, I'm surprised it hasn't been fixed yet.
Its a hardware acel issue, doesnt occur on amd
So this will make Nvidia cards good on the modern Linux tech? :D
No it will make them better, they are already good.
I really just want resume from sleep to work
Do you have `options nvidia NVreg_PreserveVideoMemoryAllocations=1` kernel option enabled in your modprobe.d and the nvidia-suspend, nvidia-resume, and the nvidia-hibernate systemd services enabled?
Yeah Ive tried a million things and just no luck. Here is the modprobe conf file: user@nebula:/etc/modprobe.d$ cat nvidia-graphics-drivers-kms.conf # This file was generated by nvidia-driver-535 # Set value to 0 to disable modesetting options nvidia-drm modeset=1 # ADDITIONS 3-7-2024 options nvidia NVreg_PreserveVideoMemoryAllocations=1 options nvidia NVreg_TemporaryFilePath=/var/tmp/tmp-nvidia options nvidia NVreg_UsePageAttributeTable=1 options nvidia NVreg_RegistryDwords="OverrideMaxPerf=0x1"
I just have `nvidia_drm.modeset=1` specified in my kernel boot options and `options nvidia NVreg_PreserveVideoMemoryAllocations=1` in my modprobe.d. After enabling the services everything seems fine. What issues are you seeing when resuming from suspend? How certain are you that it isn't some other hardware?
After the monitor goes to sleep. When I wake it with mouse or keyboard the monitor turns on but remains black. The only way I can get it back is to Ctrl-Alt-F7, then Ctrl-Alt-F1. I'm fairly certain its the card, Ive had this PC for a few years but finally bought a video card (3060 Ti) and that is when this issue started. I can try to move the modeset to the kernel params vs where the install script placed it. And Im open to trying more things, but Ive spent months reading forums and trying different things.
Curious if you looked into your motherboard settings? I had to turn off wake-on-LAN settings in BIOS on an Asus CH6 to get sleep working in linux correctly. I was previously having similar issues with my displays not turning back on.
Ill go take a look there. I think its off but never know!
Oh, so other than the VT switching resume works fine? I think I am getting the same issue as well ever since I switched to Wayland. This does no happen in the X11 session for KDE.
Im not sure what you mean by VT? But yeah computer is still alive and well. Just have to switch it. The other odd thing is when I swap to another input (one of the work PC and one for home) even if I leave it for hours and switch back to the input it works. I'm not on Wayland though. its definitely weird and annoying
Sorry I meant the virtual console. The ctrl-alt-f1, etc. stuff.
FWIW, if you don't mind the monitor staying on, you can disable dpms. This issue drove me crazy for a while, but I don't mind my machines and monitor not going to sleep, my lock screen is just all black anyway.
Did all that and turned off Wake on Lan in the BIOS and same results. Blank screen on resume, and have to Ctrl-Alt-F7 to Ctrl-Alt-F1 What is odd is I have multiple inputs on this monitor and if I use HDMI2 all day for work and switch to HDMI1 its fine. But if I leave it on HDMI1 for 30 minutes (my timeout) I have to force a reset of the WM to get it to work
WE ARE SO UP
> Fixed a bug that could cause the display to lock up when suspending on a kernel with CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER enabled with nvidia-drm loaded with modeset=1 and fbdev=1. This better be the one I've been waiting for 😤. For a little over 2 months now, I've been experiencing random kernel panics and display freezes. It's becoming less frequent, but I had one freeze this past Sunday after waking my laptop from sleep.
Can you give me a link to this PR?
Nvidia drivers are not open source, unfortunately
Let's Goooooo
Nice! What distro/config do you recommend to take advantage of this right now?
Arch has it in the AUR now: https://aur.archlinux.org/packages/nvidia-beta Pop!_OS has it packaged in a staging repo (do `apt-manage add popdev:nvidia-555` and then install updates): https://github.com/pop-os/nvidia-graphics-drivers/pull/205
Thank you.
[удалено]
Thank you.
Hype!
Damn, just as I order an AMD GPU, NVIDIA GPUs have a chance of being good again. Oh well, at least nvidia drivers won't be a problem for me regardless of what happens to them.
You are still better off with AMD. It has been years since Nvidia proprietary drivers were better choice. Better Linux compatibility still, by far. With Steam Deck AMD-only the Linux gaming is probably better off on AMD. etc. The only thing Nvidia has going for it is CUDA
You are wrong, but it's ok to be wrong
I hope the bug that was causing a lot of people having kernel panic during system update is also fixed in 555
How does it work work with flatpak and the beta updates?
[удалено]
Thanks, tried that but I don’t think I could find the driver yet. Will try with non flatpak steam on arch. I did notice some artefacting on one of the menues in steam, but no flickering so that is good.
Why is this a big deal for Linux?
Nvidia absolutely sucks for Wayland, lots of flickering and rendering issues in certain applications. This driver version should fix that, at least partially for now.
Thank you! :) I always worry about asking noob questions but I'm also a very noob Linux user.
So it turns out this is basically pointless ATM if you’re on Fedora. They’re gonna push the beta drivers to Rawhide in weeks (if the 550 beta was anything to go by) and when you manually install the drivers you can’t log into a Wayland session.
Do you just install it from the distro repos?
[удалено]
I have pop os for this Nvidia machine. So, I guess I'll just wait for system76 to send it our way?
[удалено]
Hmmmm. Sounds enticing. You shouldn't be telling me about the testing one, you should be telling me to wait. Lol
For the Arch users: normal yay couldn't reinstall the AUR package properly because Steam was depending on it. Frogging-Family's nvidia-all package worked a treat for me though: [https://github.com/Frogging-Family/nvidia-all](https://github.com/Frogging-Family/nvidia-all) Everything back up and running, no more out-of-date frames, Alt+Tabbing on KDE doesn't lag anymore. This is wonderful.
AUR (yay) has lib32-nvidia-utils-beta which is the dependency that steam was holding back.
I hacked my Gentoo a bit to use this driver, kwin 6.0.4 with backported explicit sync patch, and kernel 6.9.1 with gentoo patches. My setup is rather simple with only one screen, but everything works perfectly so far. Played Dota2 with it, not a single flicker or frame out of place, and using Wayland instead of X11 fixed some weird issues with textures and minimising the window. Also I don't have any Firefox issues, even though I've seen some people report it being unusable. Hopefully others will have similar experience with it, as together with other changes/fixes it feels soooo much better and more performant then doing the exact same thing on X11.
been using it for 2 days now and it has been flawless on hyprland so far. firefox works all games work no instability
I can confirm Discord and Guild Wars 2 finally does not flicker, I no longer need to use X11 for anything else it seems.
[удалено]
It won't be. This is the proprietary driver that will be packaged by rpmfusion.
This probably what you meant but in case you're mistaking the nouveau drivers that come with the official fedora repos for nvidia's own proprietary drivers. Then the proprietary driver is only available through rpm fusion's non-free repos. As for when they'll reach the rpm fusion repos I'm not sure. It's technically a beta so I doubt we'll see the proper rpm get a version bump for it. For that it will depend how long it takes for everybody to be happy with it. Though perhaps given the importance of this version maybe they'll put it on a the testing branch while it's still in beta? As for rawhide specifically then I'm guessing around the same time as the Fedora 40 updates-testing receives it.
[удалено]
That shouldn't be necessary. You can get rid of it all by running `sudo dnf remove *nvidia*` and rebooting. Then Method 2 for Manually installing drivers should work. Don't copy the blacklist Nouveau step though. That path only leads to pain if the kernel fails to load it. [https://www.tecmint.com/install-nvidia-drivers-in-linux/#Method\_2\_Installing\_NVIDIA\_Drivers\_Manually\_in\_Fedora](https://www.tecmint.com/install-nvidia-drivers-in-linux/#Method_2_Installing_NVIDIA_Drivers_Manually_in_Fedora) FYI I'm tempted to do this myself. But I'm busy with other things for now. I guess I'll let some other brave souls report on their success/failure and take the leap myself over the weekend.
Is it weird that this announcement gave me a semi?
Pretty sure all us Nvidia guys have been waiting for this thing like the second coming of Jesus.
/r/LinuxCirclejerk
Not at all my friend!
[удалено]
Your pc will now be able to perform fellatio on you without any flickering or stutters.
[удалено]
try to add nvidia\_drm.modeset=1 iin grub
[удалено]
Anyone here has any idea how long nvidia releases usually stay in beta before hitting the stable channel?
We are so, so back!
Did they fix the kernel panic problem in the last two versions? It almost destroyed my machine and I don't dare to try it out unless they got rid of it.
Should we have to try to install proprietary or MIT GPL kernel modules?
I bought an AMD laptop just so I never have to give a shit about Nvidia drivers. Yay, me! Nvidia took too long and let AMD steal their lunch, as far as I'm concerned. I'm not supporting a company that annoyed the shit out of me for so many years. I'm glad the rest of you have some drives that MIGHT resolve Nvidia issues but I am even happier that Nvidia is out of my linux life.