F44 Change Proposal: NTSYNC-Contained [SelfContained]

Project Discussion Change Proposals
, ,
1

NTSYNC-Contained

Wiki

Announced

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.

Summary :open_book:

This proposal aims to enable the NTSYNC kernel module for select packages by package recommendation (Recommends/Suggests), which can improve compatibility and performance when running Windows applications (especially games) via Wine/Proton.

This change supersedes the previous change: Changes/NTSYNC - Fedora Project Wiki.

Owner :open_book:

  • Name: [[User:Epictux123|EpicTux123]]
  • Email: EpicTux123@proton.me
    Affected packages: Kernel, dracut or systemd (not sure), but it’s just the addition of one file.

Detailed Description :open_book:

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

This proposal aims to enable the NTSYNC kernel module for select packages. It is present on stable kernel versions starting from 6.14.

Affected packages would be:

  • Wine main package
  • Steam package (RPM Fusion)
  • FLOSS game launchers on Fedora’s or RPM Fusion’s repos (Lutris, Heroic Games Launcher etc.)
  • Any other package that requires or recommends the Wine package

A package named wine-ntsync would be created in the Fedora’s repos. Its only intention would be to add the file /usr/lib/modules-load.d/ntsync.conf with the content ntsync to enable the NTSYNC kernel module at boot.

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 detected as 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.

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

Since the creation of the previous change, progress has been made upstream such as server: Create an inproc sync for user APC signaling. (!9014) ¡ Merge requests ¡ wine / wine ¡ GitLab.

Feedback :open_book:

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. Installing the wine on Fedora, even with this change approved, wouldn’t make use of it, since it requires experimental patches that are pending for merge in upstream. This proposal would mainly benefit GE-Proton (and other community-made Proton versions) users.

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

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

Benefit to Fedora :open_book:

See “Detailed Description” and “Feedback” section.

Scope :open_book:

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

  • Other developers: N/A

  • Release engineering: N/A

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

  • Alignment with the Fedora Strategy: I think it does.

Upgrade/compatibility impact :open_book:

No required upgrade/compatibility changes. Could teoretically conflict with an existing file in /usr/lib/modules-load.d/ if the user has created one, but it’s incorrect to create one there since /etc/modules-load.d/ should be used instead.

Early Testing (Optional) :open_book:

How To Test :open_book:

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

User Experience :open_book:

Better performance and compatibility with Windows applications (especially games) through Wine. Currently only applicable for custom builds of Wine/Proton.

Dependencies :open_book:

N/A as far as I am aware.

Contingency Plan :open_book:

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change)

Documentation :open_book:

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

Release Notes :open_book:

NTSYNC kernel module is now enabled by default for Wine packages\n\nThe NTSYNC kernel module has been enabled by default for users of Wine packages. 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 @amoloney 2025-10-14T16:12:45Z

Last edited by @amoloney 2025-10-14T16:12:45Z

1 Like
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

The ‘steam’ package already includes a ntsync module file. The ‘wine’ package will see one in the next update. I’m not sure what the Change Owner was trying to accomplish with this or if they were even a packager. I have never been contacted by this person.

1 Like
4

This also seems to be no longer accurate as of Wine 10.16, which mentions NTSYNC support in its release notes.

5

Hi there. I’ve got in touch with @mooninite via e-mail and it seems this will already be implemented. Coordination is being done with the RPM Fusion’s Steam package mantainer to make sure no problems will occur between Fedora’s Wine and RPM Fusion’s Steam packages.

Not sure about the state of this proposal then. I think it has to be withdrawn or closed as invalid/completed?

Thanks.

6

images
images201×251 12.3 KB
:stuck_out_tongue:

Will that work out differently compared to AMDGPU freeworld VA-API stuff?

7

In this case it’s just that the two packages need to be careful not to conflict on a config file they ship, as I understand it. The media codec situation (mesa / ffmpeg) is much more complicated than that.

1 Like
8

Good news.

I think we still want a mechanism to allow various downstream packages to request the module. If @mooninite is amenable to that, wine could make the wine-ntsync subpackage, and then others could add Recommends: wine-ntysnc in appropriate places. This is better than having multiple files to load the module present in different places. We might want to add some further setup later, and it’s better if this is centralized in a single package.

So I think this proposal text could still be “rescued” as a Change Proposal to make people aware of the module being added and supported in Wine and other things in F44.

1 Like
9

When I read this, I fall into a bike-shedding rabbit hole: The ntsync module is a general feature. While wine might be using it the first and the most, there might be other tools in the future making use of it. So I almost want to propose renaming it to e.g. kernel-module-ntsync (and similar naming can be reused for other modules in the future). But then, it almost feel like an overkill to package a single config file to load a single kernel module (do we want to extend this to all available modules?), and it feels like “there should be a better way”, similar to requesting creating user accounts in spec files, etc. Which surely isn’t available.

So I’ll just hold my tongue :slight_smile:

10

If the package has a service file, it can say Wants=modprobe@ntsync.service, After=modprobe@ntsync.service, and a job to load the module will be spawned. But obvs. this only works for things with a unit file, so not for a library for example.

11

A polkit which authorized users (in the game/games group?) to start such a service could be used by a wine wrapper I suppose.

1 Like