[krokosik]

Native Wayland does not yet provide a usable Inventor workflow. An experimental cross-process GDI bridge made WebView2 Home content render, but interaction was very slow and glitchy. The patch remains in drafts; the reproducer README records the investigation and upstream issues. X11 remains the supported path.

The flake now exposes explicitly versioned Inventor and media outputs, defaults its package/app to 2027, and removes the native Wayland desktop entries. The NixOS module defaults to an empty release list, with explicit selection documented in the quick start. Nix workflow instructions require builds and tests through named flake outputs.

The nix-overlayfs dependency is pinned to 64e1ea8c42a281831bdb362b6078f61721c3e527, the latest main commit checked on 2026-10-29. The complete dependency diff was reviewed, including installer failure handling, portable reparse points, registry links, FUSE ownership, runtime identity mapping, and asynchronous browser lifetime.

Validation of the updated pin:

• nix flake check -L passed.
• nix build .#inventor-2027 --no-link -L passed, including the base installation, Content Libraries, and 2027.1 update. The licensing installer completed after about six minutes with the already handled exit code 84.
• nix run .#inventor-2027 was tested with Agent Workspace Linux on isolated X11/Xvfb at 1920x1200 using system graphics and the existing signed-in state in place. Startup, complete Home rendering, the New template chooser, and restart passed. Vulkan/DXVK detected the NVIDIA RTX 3060.
• Standard-part creation remained at “Loading…”, matching the previously documented hidden-Xvfb limitation. Closing removed the window, but launcher cleanup did not finish and the owned test sessions required termination. Part/save/reopen and clean exit remain unvalidated; no full L4 result or confirmed regression is claimed.
• Test workspaces were stopped and no launch lock remained. Account-bearing screenshots and logs were kept outside Git.

[Harvi654]

Thanks a lot for this - it's a careful, honest write-up, and parking the bridge in drafts/ until upstream WebView2/compositing support improves is the right call. I read the whole diff: the docs, the reproducer, the draft patch and the Nix changes. A few small things before I merge:

• docs/nixos.md line 64 still uses nix build "path:$PWD#inventor"; that output no longer exists, so it should be #inventor-2026 (or -2027).
• docs/nixos.md line 229 is the record of the 2026-10-20 validation, which ran .#inventor at the time. Could you keep the original command and add "(now .#inventor-2026)" instead of rewriting it?
• nix run now defaults to 2027, while the NixOS module still defaults to versions = [ "2026" ]. That may be intentional. If so, one sentence in docs/nixos.md explaining it would avoid confusion.
• The draft notes say "the maintainer reported terribly slow and glitchy". If that was your own follow-up test, please say so (e.g. "the Nix maintainer"), so it's clear who verified what.

One note on the slowness, in case you pick it up again: every 240×16 tile is a separate synchronous cross-process send_message_timeout from inside flush, so a full 1920×1080 repaint is roughly 540 round trips, sent while the surface is locked. That probably explains most of the slowdown as well as the possible wait you mentioned.

Status on my side: I'm currently working on a private SOLIDWORKS 2026 repository and want to finish it first. The goal is to get it to roughly where Inventor is now, then publish it the same way. I expect about another week, unless something gets stuck. After that I'll come back to Inventor: the full review of #3 and AMD testing (RX 580 and RX 6400) with the script installer, as promised. Sorry it's taking longer.

Where SOLIDWORKS 2026 is now, for anyone following:

• Clean install works and matches Windows file for file. A fresh prefix installed through SOLIDWORKS' own Installation Manager from local media, compared against the same selection on a real Windows 10: about 19,000 files, 0 missing, 0 extra, 0 different (SHA-256).
• Getting there needed Wine MSI fixes. Wine's Windows Installer selected features differently from Windows, so SLDWORKS.exe itself was not installed. The rules were measured on Windows 10 (x86_64 and i686) with original synthetic tests; the three candidate patches pass those tests on both Windows and Wine, plus the existing msi test suites.
• CAD basics work on that clean install: part (sketch, extrude), assembly with mates, save/close/reopen, restart. Earlier test installs also passed splines (a small glu32 NURBS curve implementation) and a static Simulation study with mesh, solve and results.
• Still open: the viewport is black with "Enhanced graphics performance" enabled (works with it off), drawings still need a proper test, and a fresh install needs a few prerequisites written into the installer (a missing concrt140 function, fonts for WPF).

Some of this work produced Wine fixes (msi, msxml3, comctl32, glu32 and others). Once they pass the validation levels on their side, I'll bring the relevant ones over to the Inventor Wine build. SOLIDWORKS itself will stay script-based: there are no plans for Nix packaging, as I can't expect anyone to have a license to test it there. What I'm thinking about is the long-term layout of the Wine build itself, so that the Inventor installer, the Nix flake and the SOLIDWORKS scripts all use one shared Wine patch set and build instead of diverging, possibly with the Wine build in its own repository. Since the flake depends on that, I'd be glad to hear your preference before I change anything.

[krokosik]

As of now, the flake approach is very much compatible with the scripted one. It jsut applies everything within the patches folder, as long as it has a .patch extension and ignores subfolders.

If the scripts build a capable Wine, so will nix. I don't however use Solidworks.

As for the review, I addressed the comments and changed the default version to empty, to not assume a preferred version.

[Harvi654]

Thanks, all four points look good, and thanks for the answer on the shared Wine build - good to know the flake already picks up everything in patches/*.patch, so nothing needs to change there.

One small thing about the new module default: someone who only has programs.autodesk-inventor.enable = true; (which was enough before) will silently get nothing after updating. Could you add a warnings entry when enable is true and versions is empty, e.g. "programs.autodesk-inventor.versions is empty; select [ "2026" ] and/or [ "2027" ]"? Then I'll merge once the flake check passes.

[krokosik]

Changes pushed, also it was discovered that an issue in nix-overlayfs was preventing license checks from succeeding, so I had to patch that flake. Updated pin and added warning are now live

[Harvi654]

Merged, thanks! I read the last two commits and the nix-overlayfs pin change (8bf7c5c..64e1ea8: ExitType=cgroup for the browser opener, exit code from normalize-wine-reparse, tests) - all good.

Heads-up for the flake: the Wine build is moving to a separate repository, https://github.com/Harvi654/winum ("Fortified Wine for engineering software"), shared by the Inventor and SOLIDWORKS projects. Its first release winum-11.20-1 will be exactly the 27 patches of wine-11.20-6, only built there, with patches/series as the order and releases made from my signed tags. The Inventor repo will then pin a winum release instead of building its own. When that happens the flake should take the patches (or the release) from winum instead of patches/*.patch here - no rush, I'll ping you before switching, and nothing changes until then.

For #3 this also answers the structure question: the opt-in Wine OpenGL patch would go to winum (patches/candidates/ until it is validated), the DXVK/vkd3d-proton patches stay as you proposed. I still owe you the RX 6400 test of wine-opengl-require-alpha; I'll post it in #3.

[krokosik]

Sounds good, thank you! As for winum, it would probably be easier to have a minimal flake in that repo as well and simply use it as an input for this one.

[Harvi654]

Good idea - a minimal flake in winum that the Inventor flake takes as an input sounds right to me. Would you be willing to send it as a PR to winum? I'll review it, but you know Nix much better than I do, and you'd be its natural maintainer there.

One thing it has to follow: winum applies only the patches listed in patches/series, in that order, with --fuzz=0. Other .patch files and subfolders (candidates/, debug/, drafts/) are never applied, so the flake shouldn't glob patches/.patch. scripts/lib/wine-patches.sh is the reference.

A correction to my heads-up above: winum-11.20-1 will not be "exactly the 27 patches". I'd rather ship one first release with everything that passes validation by then: the 27 Inventor patches, the SOLIDWORKS ones (msi, msxml3, comctl32, glu32, win32u, winex11, ...), and possibly an oleaut32 type library cache that takes Inventor's 3D PDF export from about 7 minutes to 15 s. Each patch goes into series only after its tests (including on Windows) and a cross-review. I'll post the final list before tagging.

The RX 6400 results for #3 are coming today - I'll post them there.

[krokosik]

Sure, I could maintain the flake there