F44 Change Proposal: Enable NTSYNC kernel module for all users [system-wide]

Project Discussion Change Proposals
, ,
1

:link: Enable NTSYNC kernel module for all users

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

:link: Summary

This proposal aims to enable the NTSYNC kernel module by default for all users, which can improve compatibility and performance when running Windows applications (especially games) via Wine/Proton.

:link: Owner

Affected packages: Kernel, dracut or systemd (not sure), but it’s just the addition of one file.

:link: Detailed Description

The NT synchronization primitive driver, known as NTSYNC, is a mechanism used by Wine applications get better compatibility and more performance when running applications (especially games).

This proposal aims to enable the NTSYNC kernel module by default for all Fedora Linux users. It is present on stable kernel versions starting from 6.14.

As far as I (the proposal creator) am aware, this is apparently better than other existing implementations (such as E-SYNC and F-SYNC). This is also the only one to be considered into integration for upstream Wine.

Currently, the kernel driver works as expected (as far as I know), but the code on Wine’s side is still a pending merge request. However, community-made Proton versions such as GE-Proton (made by GloriousEggRoll) already have NTSYNC enabled by default if the kernel module is loaded.

From my personal testing I haven’t see any problematic behavior when enabling this module. It also fixes some problematic games that don’t work well with either E-SYNC or F-SYNC methods (such as Bioshock games and Call of Duty Black Ops I and II).

The intention is to make Fedora Linux the first distribution to start enabling this module as to innovate in the Linux world.

As far as I am aware, the default state of the module (to be enabled or disabled by default) is a decision that can be made upstream on the kernel side for everyone, or just downstream by a distro for its users. Since Fedora focuses on innovation, I think this is the correct place for it.

I very recently discovered the change process, so I am sorry for filling out out-of-date, but I think this change is mostly harmless for now.

For Fedora, this process would mean creating a file in /usr/lib/modules-load.d/ named “ntsync.conf” to load the “ntsync” kernel module.

Some reference links:

Kernel technical documentation: NT synchronization primitive driver — The Linux Kernel documentation
Article on GamingOnLinux: NTSYNC for Proton / Wine now in Linux kernel 6.14 that "Should make many SteamOS users happy" | GamingOnLinux
Wine merge request: ntdll: Implement in-process synchronization via the Linux "ntsync" driver. (!7226) · Merge requests · wine / wine · GitLab

:link: Feedback

I have not gathered any feedback. However, this proposal, even if approved, would only be applicable to custom builds of Wine/Proton, since upstream Wine does not fully support it (yet), so any build that contains the possibility of using NTSYNC is a custom and experimental build.

When the merge request is eventually approved in upstream Wine, Fedora would already have the kernel module for all users available to use.

There is some feedback available in the GloriousEggRoll’s Discord server for users testing the kernel driver in the latest version (10-10) of GE-Proton.

:link: Benefit to Fedora

See “Detailed Description” and “Feedback” section.

:link: Scope

  • Proposal owners: EpicTux123 (EpicTux123@proton.me)

  • Other developers: N/A

  • Release engineering: #12831

  • Policies and guidelines: N/A (probably not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy: I think it is aligned.

:link: Upgrade/compatibility impact

:link: Early Testing (Optional)

“Do you require ‘QA Blueprint’ support?” I have no idea.

:link: How To Test

Modprobe the “ntsync” module and/or create a file in /etc/modules-load.d/ to load it automatically.

:link: User Experience

Better performance and compatibility with Windows applications (especially games) through Wine.

:link: Dependencies

N/A as far as I am aware.

:link: Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) Revert the change to load the kernel module by default.
  • Contingency deadline: N/A. It is a system-wide change, but this can be easily reverted.
  • Blocks release? NO

:link: Documentation

See “Detailed Description” section. There are some links there.

:link: Release Notes

NTSYNC kernel module is now enabled by default

The NTSYNC kernel module has been enabled by default. It is present on kernel stable versions starting from 6.14. This provides better performance and compatibility for Windows applications running through Wine/Proton (especially games). Currently, this is only available for certain custom Wine/Proton builds, but Fedora is making the kernel module available ahead of the eventual merge in upstream Wine.

Last edited by @alking 2025-08-07T13:34:35Z

Last edited by @alking 2025-08-07T13:34:35Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

I’m interested in NTSYNC for Wine, but would rather the module be enabled as a global default once Wine gets the support, instead of enabling it now primarily for Steam/Proton. I believe NTSYNC to be more widespread-beneficial for users with the general Wine support, whereas Steam/Proton users can enable it in the meantime if knowingly wanting it.

Realistically if it’s only beneficial for Proton/Wine I don’t think the NTSYNC module should be enabled by-default at all though, but instead enabled on-demand with the install of Steam/Wine (Firefox/LO desktop use doesn’t benefit from an extra kernel module loaded).

Ubuntu 25.04 ships it, but apparently not enabled by-default.

4

I guess the question is on what time frame does wine expect to merge the patches?

and is this a reasonable downstream patchset to carry in rawhide leading up to F43 if it helps upstream test it and get it merged? The contingency would be to drop the wine patches and disable this module?

Something to discuss with the individuals maintaining the wine packages perhaps?

5

Loading extra modules increases attack surface.
Please make this part of the Wine or Proton packages, so only users who actually need and install it, get the module loaded by default.
As a good option, you can create a package with a specfile like this:

Name: wine-ntsync
...
Supplements: wine
Supplements: proton
...
%files
%{_usr}/lib/modules-load.d/wine-ntsync.conf
3 Likes
6

Fedora expressly prohibits packaging kernel modules outside of the main kernel package, What can be packaged :: Fedora Docs.

7

I think the suggestion was more accurately worded as perhaps packaging a modprobe config that enabled the module that other applications could require to enable the kernel module when specific workloads are present.

2 Likes
8

Something I was worrying about got mentioned!

  1. Call of Duty: Black Ops II (202970) · Issue #808 · ValveSoftware/Proton · GitHub
  2. Call of Duty: Black Ops II (202970) · Issue #808 · ValveSoftware/Proton · GitHub

I was just now googling around for NTSYNC on Fedora because of https://youtu.be/SU2mFqCOh5A and found out this post of yours.

So tl;dr it’s not “on by default”. I could turn it on, but honestly, I don’t want to risk something bricking later on, so I’ll leave it off.

First or not doesn’t really matter. THE important thing is that it has to work on everyone’s machines WITHOUT needing a Tech Guy to un-brick a PC.

That said, almost all Linux Devs are kinda allergic to “UIs with big buttons saying turn this on and turn this off”.

It’s completely normal for Servers or no-nonesense-workstations_for_hackermasters to not have this stuff,
but for a Distro aimed at grandpas/mas, normal people, gamers or young users (children under parental control) to push UI buttons (thus with limited freedom, which is GOOD when hackerman knowledge is not present) which just “do the things by automatically running commands in the background” (as any other good Operating System does) is not only much more desirable, but also objectively easier than first knowing what to do, and second having do cast the incomprehensible serie of spells every time one wants to check stuff out.

.

“SUDO APT Dale a tu cuerpo alegría, Macarena. Que tu cuerpo es pa’ darle alegría y cosa buena. Dale a tu cuerpo alegría, Macarena. HEY Macarena, AY!”
:left_speech_bubble:

wizard casting spells 2
wizard casting spells 2894×599 103 KB

3 Likes
9

Hi there people, proposal owner here to reply to some points made by you guys.

Point 1) When should we enable it?

The module will only get visibility if some distro pushes for it, and Fedora is the one that mostly pushes for innovation.

The kernel module itself is ready, but the code upstream on Wine it’s not (it’s a pending merge request). Enabling it now would facilitate usage of custom Wine/Proton builds to benefit from it. There is no harm done if it’s enabled by default since default Wine does not include such patches at this time.

Point 2) Enabling it increases attack surface.

Well, yes, that I cannot deny. However, I believe such module would be enabled by default when the relevant code is merged on Wine, so that everyone can benefit. Enabling it now can increase adoption ahead of the official upstream merge.

Point 3) How should we enable it? / Enable it only on specific packages

This should be enabled globally. Requiring the user to install an extra “wine-ntsync” package would be bad UX IMO, and practically the same requirement as requiring to modprobe via terminal (it would be just a different command (package install) instead of using modprobe directly).

There are no Proton packages on Fedora. Proton is a self-contained thing that includes everything with it by default. Official Proton and community-built Proton versions are built this way. An average person wouldn’t be able to benefit from it by just using Proton without having the knowledge to modprobe it. Like another member said, it’s much easier just to make this enabled by default for the user.

Currently, it would only affect custom community-built Wine that include such patches, which should make the attack surface very low (a specific distro, be a gamer and a specific custom Wine/Proton build).

Point 4) It’s not on by default.

Upstream Proton is not focusing on implementing NTSYNC because they already have F-SYNC which is more or less very capable of handling most games. However, it causes problems in some games, which are fixed by NTSYNC, and NTSYNC is the only official way for Wine to accept it.

Upstream Proton will only accept this when Wine merges it, which could take a long time. Anyone on kernel 6.14 can already benefit from it by using modprobe and a custom Wine/Proton version. By enabling it first, Fedora would push this feature forward, giving it more visibility.

In summary:

  • The kernel code itself is fine. The attack surface should be minimal given the circumstances. What is pending is the upstream Wine code.
  • Someone needs to push this first (take the initiative), because upstream Proton does not have plans to do so this early. Fedora being the one would make more sense, as it is known for pushing new features to the Linux world before other distros.
  • It requires a custom Wine/Proton build, so enabling it just for a specific package wouldn’t suffice, and enabling it globally wouldn’t affect anyone that does not use such custom builds.
  • Enabling it only on specific packages wouldn’t benefit Proton users because Proton users don’t rely on system Wine packages. There is no Proton package on Fedora due to how Proton builds are distributed.

I hope this answers all of your questions. If not, please let me know.

By the way, FESCo decided this should be postponed to F44 due to the deadline, so any suggestion to get this into F43 will probably be denied. (See Issue #3455: Fast Track: Could this change proposal be re-categorised as a self-contained change for F43? - fesco - Pagure.io )

10

@alking Can you edit the first post to include a link to the Change Page on the wiki? Thanks

11

This change proposal has now been submitted to FESCo with ticket #3472 for voting.

To find out more, please visit our Changes Policy documentation.

12

@epictux123 Regarding the package path - couldn’t just the main wine package have

Recommends: wine-ntsync

? In that case, every user with wine installed would also get the ntsync loaded, without getting it on for users not caring/knowing/needing wine. Also, all the wine loaders like lutris/bottles could do the same.

1 Like
13

Enabling it only on specific packages wouldn’t benefit Proton users because Proton users don’t rely on system Wine packages. There is no Proton package on Fedora due to how Proton builds are distributed.

The same would be true for custom Wine builds outside the Fedora packaging system as well. Requiring an extra package just to enable the module would be the same as creating the automatic module loading (modprobe) yourself, so it would not really help.

For it to benefit all cases, it has to be enabled globally. It requires a custom Wine/Proton build, so enabling it just for a specific package wouldn’t suffice, and enabling it globally wouldn’t affect anyone that does not use such custom builds.

14

Here is a link for it: Changes/NTSYNC - Fedora Project Wiki (I cannot edit the first post.) Hope that helps.

15

Some extra information:

Per August 2025 data on https://store.steampowered.com/hwsurvey?platform=linux , we have 2.18% of Linux people on Fedora Workstation and 1.93% on the KDE Plasma edition (and who knows how many on Flatpak), of the total of ~3% of Steam users on Linux (that agree to sent hardware survey data). Although we don’t have absolute numbers, it’s safe to assume a high number considering Steam 25+ million monthly users.

Technically Steam is not on Fedora’s repos, but it is on a RPM Fusion repo that is enabled when you click “Enable third-party packages” in the first-time setup.

16

A few points from my pov:

  1. The fact that many Steam users are Fedora users does not mean that many Fedora users are Steam users. Many Fedora users don’t even use Fedora on a desktop (monitor-attached) system.
  2. The claim that having a specific package to be install (or a file to be adde in /etc/modprobe.d) is “too complex” for someone that is custom building of Wine is not something that we can cater too much for.
  3. RPMfusion’s Steam package (or any other installer method) can easily create the file as well, so there is no problem on that aspect.
1 Like
17

I installed wine-staging on openSUSE Tumbleweed from WineHQ’s repo. I installed ntsync-autoload separately which pulled-in ntsync-autoload-udev-rules.

Staging 10.14 didn’t show anything with lsof /dev/ntsync, but today I updated to 10.15 which does show stuff (quick test of Guild Wars 2):

COMMAND    PID         USER FD   TYPE DEVICE SIZE/OFF NODE NAME
start.exe 3561 espionage724 12r   CHR 10,260      0t0  142 /dev/ntsync
wineserve 3563 espionage724 25r   CHR 10,260      0t0  142 /dev/ntsync
services. 3569 espionage724 11r   CHR 10,260      0t0  142 /dev/ntsync
winedevic 3572 espionage724 10r   CHR 10,260      0t0  142 /dev/ntsync
plugplay. 3582 espionage724 10r   CHR 10,260      0t0  142 /dev/ntsync
svchost.e 3588 espionage724 10r   CHR 10,260      0t0  142 /dev/ntsync
winedevic 3594 espionage724 10r   CHR 10,260      0t0  142 /dev/ntsync
conhost.e 3612 espionage724 11r   CHR 10,260      0t0  142 /dev/ntsync
Gw2-64.ex 3614 espionage724 11r   CHR 10,260      0t0  142 /dev/ntsync
explorer. 3616 espionage724 10r   CHR 10,260      0t0  142 /dev/ntsync
rpcss.exe 3623 espionage724 10r   CHR 10,260      0t0  142 /dev/ntsync
CrGpuMain 3691 espionage724 10r   CHR 10,260      0t0  142 /dev/ntsync
CrUtility 3700 espionage724 10r   CHR 10,260      0t0  142 /dev/ntsync
CrUtility 3702 espionage724 10r   CHR 10,260      0t0  142 /dev/ntsync
CrRendere 3705 espionage724 10r   CHR 10,260      0t0  142 /dev/ntsync
CrRendere 3828 espionage724 10r   CHR 10,260      0t0  142 /dev/ntsync

Fedora 42 also has Staging 10.15 on WineHQ WineHQ Downloads: /wine-builds/fedora/42/x86_64/

1 Like
18

Well, if I am not missing anything - steam from rpmfusion could start doing the same Recommends: wine-ntsync as well as all the wine managers that allow users to install different flavours of wine.

Users directly pulling built/changed wine(s) without using any managing app already have to do manual steps from the cli, so installing/modprobing shouldn’t be an issue for them.

Am I missing something here?

19

What kind of data is stored at /dev/ntsync, and is that data isolated from other Wine apps?

I ran two apps in separate prefixes and both had their processes shown in lsof /dev/ntsync.

If sensitive data could end up in /dev/ntsync and isn’t isolated from being read from other Wine apps, I don’t think the module should be globally enabled.

20

This change has been rejected by FESCo and will not be included in Fedora Linux 44.
To find out more about how our changes policy works, please visit our docs site.