5.7 kernel package without patches from Valve

The latest 5.7 kernel (5.7.9-1) contains patches from Valve, which are supposed to make Proton games perform better.

These patches are not a part of the mainline Linux kernel, they have not been vetted nor approved by the kernel developers.

Ideally, a kernel with these patches ought to be a separate package, but if that is not possible, there ought to be a package for 5.7 kernel without them. As someone who does not use either Proton or Steam, I have no benefit from these patches, and Valve has a record of being a rather untrustworthy company, and not respecting users' privacy, so an option for users who do not wish to use these kernel patches is, in my opinion, necessary.

Before these patches get included in the mainline kernel, I don't think they can be deemed trustworthy. And while they are a welcome addition to gamers who accept the risk, there ought to exist a simple option for those who do not.

Following a suggestion of @eugen-b, here is a poll to gauge the (lack of) interest for such a feature.

Would you find such a kernel package useful?

  • Yes
  • No

0 voters


Can you give a link to those patches in the manjaro kernel linux57?

This is one of them, I'm not sure if there are others:

Doesn't Manjaro put a number of patches in their kernels anyway that isn't part of the mainline?

Yes. But I'm not sure if there were patches made by Valve before. I'm not saying that there is anything malicious in there, my bet would be that it is perfectly harmless.

However, it is a patch contributed by a company who has been known to do shady stuff, and that combined with the fact that it's not part of the mainline, naturally raises concerns. I would just like to have an easy option to not have that code running, at least until it becomes part of the mainline (if it ever does).

and yet it


What specifically is in the patch which makes you think it is shady or untrustworthy or not respecting your privacy?

Unless you have specific concerns then if

you can use Kernel 5.4 and leave the hyperbole alone.

1 Like

The fact it originates from Valve, a corporation known for privacy violations, and the fact is not a part of the mainline kernel. It's a red flag. I never stated that I think that there is anything malicious in it, just that I am unsure of it and I'm not comfortable risking it.

I do not think I am being hyperbolic. The feature request I'm making seems perfectly reasonable to me: to have a 5.7 kernel package without additions by Valve which are not vetted by the kernel developers, in order to make my life easier (and for others who share my concerns) so I do not have to compile the kernel myself, or use a kernel from the Arch repos.

I'm sorry, but I really do not understand why you are calling that hyperbolic, and why you think that this is an appropriate response to such a concern.

1 Like

The Manjaro kernel isn't a vanilla mainline kernel to begin with. It has a decent number of patches from a number of contributors.

While I understand that you don't like Steam, putting a specific patch into question based on who wrote it seems like a logical fallacy. I mean, the Manjaro kernel also contains patches from Canonical. Wouldn't those patches also need to be removed by that logic?

If you want a mainline kernel, you could always build one yourself.


Perhaps, if I had the resources to vet that patch myself or some other reassurance that it is harmless. Given that I do not have that, and knowing the history of Valve's transgressions against privacy, I do not think my concern is completely crazy and unreasonable.

I never said I wanted a mainline kernel, and yes, obviously, there is the option of building it myself. That is what I am going to have to do if this feature request is ignored, which seems like it is going to be. :man_shrugging:

Of course, I would like to not have to do that on every update, hence the request, but if I am the only one with this concern, than I agree, it's not worth catering only to me.

add a poll to your original post if you wish

Am I mistaken, or can't this patch be viewed/analyzed for potential nefariousness? Isn't that one of the beauties of open source?

1 Like

Certainly, if you have the resources to do so. My understanding of how the kernel functions (and especially how Wine functions, which this patch seems to be all about) is insufficient for that. This is some 1000 lines of C code for which I have no clue what they do. In the off chance that there is actually something nefarious in this patch (which I don't think there is, I can't repeat that enough), the likelihood of me finding it is pretty much zero.

Unlike patches that get accepted into the mainline kernel, where dozens, if not hundreds of people look at them before they are approved, and millions of users use them, this was probably only looked at by one or two people who have any understanding of what's going on in there.

Why not make this option a kernel module. And not enable by default. Have the module used when steam is installed. If steam not installed. It should have no effect on the user end.


I think that would be an excellent solution. What I am proposing is much simpler though: just package linux57 with and without the patches from Valve, so that users can choose which one they want with mhwd. I'd be perfectly content with just that...

However, it would be great if your idea was implemented, that really seems like a proper way to do it, because it seems to me that those who are not using Steam have no benefit from it.

First of all the patches are from the consulting company collabora.com which are working with CodeWeavers for Valve to get more proprietary software into Linux, which mostly is games now. For this to happen the kernel needs to be patched.

In the past we already added patches, which enables our users to use snaps or other features not yet added to mainline.

We have good connections as a company with Collobra and CodeWeavers. Adding new features to a non LTS kernel is OK and largely requested by our gamer community.

So even on regular cases the ne patch set improves performance. Adding another 57 kernel series most likely won't happen from our end. We will keep close track on changes made to the patch set and will keep it maintained.

If there are any concerns from our end we will review the situation.


I think, extramodules are not done for fun, they're usually necessary for code which is not compliant with the GPL2 license.

Which? With or without the fsync patches?


because the patch doesn't add a "modulable" feature.. but patch actual kernel code and add some functions.

1 Like

Just curious what they violate? Can you post serious link for this thing? Tried to use google, no luck.

And another thing, don't like patch, compile without it, its easy :slight_smile:

Forum kindly sponsored by