Skip to content

Fix command line not being restored after NeoForge early window init#3803

Merged
douira merged 3 commits into
CaffeineMC:devfrom
FlashyReese:fix/neoforge-early-window-workaround-restoration
Jul 5, 2026
Merged

Fix command line not being restored after NeoForge early window init#3803
douira merged 3 commits into
CaffeineMC:devfrom
FlashyReese:fix/neoforge-early-window-workaround-restoration

Conversation

@FlashyReese

@FlashyReese FlashyReese commented Jul 4, 2026

Copy link
Copy Markdown
Contributor

Fixes #3733

On newer NeoForge, Sodium applies the Nvidia/AMD command line workaround from the early window bootstrap path, but the normal Window#createGlfwWindow restore path is not hit for that early GL context.

This leaves the spoofed command line in the PEB after startup.

This waits for NeoForge's early renderer to initialize, then restores the command line using the existing undo path. The workaround still stays active long enough for the driver to initialize, but it should no longer remain visible for the rest of the process.

image

Newer NeoForge creates the early GL context through the early window bootstrap path, so Sodium's normal Window#createGlfwWindow restore path does not run for that context.

Wait for the early window renderer to initialize, then restore the Nvidia/AMD command line workaround using the existing undo methods.
@douira

douira commented Jul 4, 2026

Copy link
Copy Markdown
Contributor

Thank you for looking into this. You're using a polling approach, which makes me wonder whether there's maybe instead some place that we could hook into that would give us this event explicitly. Is that possible?

@FlashyReese

Copy link
Copy Markdown
Contributor Author

afaict neoforge doesn't expose a hook for this exact point.

the point we want is after LoadingScreenRenderer finishes init / rendererFuture completes, but that is internal earlydisplay state. sodium's normal mixins also load too late for this path.

takeOverGlfwWindow() exists, but that is later when minecraft takes over the window, not when the early renderer is ready.

so unless we add a neoforge hook or use an early transformer/mixin into neoforge internals, polling seems like the only sodium-side option.

@Demeno

Demeno commented Jul 5, 2026

Copy link
Copy Markdown

Hi @FlashyReese, thanks for fixing the bug! I just tested it and the issue is indeed no longer happening in the PR version.

We just had another user ask us on Discord if there's any update today, so it's fortuitous timing that we can now tell them that the fix is in sight. :)

@douira douira requested a review from IMS212 July 5, 2026 18:21
@douira

douira commented Jul 5, 2026

Copy link
Copy Markdown
Contributor

takeOverGlfwWindow() exists, but that is later when minecraft takes over the window, not when the early renderer is ready.

Does this mean that if we did it later at this point it wouldn't work properly?

@FlashyReese

Copy link
Copy Markdown
Contributor Author

takeOverGlfwWindow() exists, but that is later when minecraft takes over the window, not when the early renderer is ready.

Does this mean that if we did it later at this point it wouldn't work properly?

Probably works, just later than ideal. I will test a local patch.

Replace polling the early window state with hooks around `takeOverGlfwWindow()`.

This restores the PEB when Minecraft takes over the early window, after NeoForge has already waited for the early renderer to initialize.
@FlashyReese

Copy link
Copy Markdown
Contributor Author

Switched this to hook takeOverGlfwWindow() instead of polling. It restored properly in my test, but @Demeno could you test this version too?

@Demeno

Demeno commented Jul 5, 2026

Copy link
Copy Markdown

@FlashyReese, tested it, seems to no longer fix the issue, unfortunately

@douira

douira commented Jul 5, 2026

Copy link
Copy Markdown
Contributor

I wonder why the timing matters here. Are other applications reading the command line args of the game at some specific early time?

@FlashyReese

Copy link
Copy Markdown
Contributor Author

my guess is that some overlay apps read/cache the process command line pretty early.

takeOverGlfwWindow() is late enough for the driver workaround, but maybe too late for those apps, since the spoofed PEB stays visible for more of startup.

we only need the spoof until rendererFuture completes / the early renderer initializes, so polling restores it closer to that point. I tried the handoff hook, but Demeno could still reproduce it, so I reverted back to polling.

@douira

douira commented Jul 5, 2026

Copy link
Copy Markdown
Contributor

Thank you for testing it. I'll merge this soon if nobody else has any concerns. I'm not the code owner for this, so I'd like a sign of approval from somebody else if possible.

@douira douira merged commit e765800 into CaffeineMC:dev Jul 5, 2026
1 check passed
@douira

douira commented Jul 5, 2026

Copy link
Copy Markdown
Contributor

Does this need to be backported to 26.1?

@FlashyReese

Copy link
Copy Markdown
Contributor Author

This affects 1.21.10+

douira pushed a commit that referenced this pull request Jul 5, 2026
…3803)

Newer NeoForge creates the early GL context through the early window bootstrap path, so Sodium's normal Window#createGlfwWindow restore path does not run for that context.

Wait for the early window renderer to initialize, then restore the Nvidia/AMD command line workaround using the existing undo methods.
douira pushed a commit that referenced this pull request Jul 5, 2026
…3803)

Newer NeoForge creates the early GL context through the early window bootstrap path, so Sodium's normal Window#createGlfwWindow restore path does not run for that context.

Wait for the early window renderer to initialize, then restore the Nvidia/AMD command line workaround using the existing undo methods.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Sodium fails to restore modifications to PEB in newer NeoForge versions

3 participants