Wine-NSPA-10.x Rebase/Port

[nine7nine]

• With the Wine-10.0 release coming very soon, it's time to start thinking about rebasing Wine-NSPA.
• After Wine-10.x is released, I need to wait for Wine-Proton to release Wine-10.x builds, due to some dependencies in Proton.
• I also need to consider supporting both Fsync and NTSync. The latter I will need to do a ton of testing with.
• NTSync: I will need to familiarize myself with both the userspace/wine code AND the kernel code. It's highly likely I will want to modify it in some way or another.
• I will need to rebase the Wine-NSPA RT patchset, which may need further modifications.
• Initially, I can drop a lot of patches (mainly backports, and legacy stuff).
• I will also need to either pickup new versions of patchsets I use, or forward-port the odd patchset..

Given the above, after Wine-10.0 / Proton-10 are available, I can start with getting the basics in-place. eg: Using latest Wine-TKG build system, Fsync (+ Proton Fsync changes), NTSync, Wine-NSPA RT support, along with a few other bits...

Once I have working builds: I'll push them to github, then start going through other patchsets and revivals and revisions. ~ This bit will probably take a while to get up to snuff (it is a lot of work), but shouldn't be too bad.

No ETA yet, a lot will depend on Proton-10 to begin the work. Wine developers are working on the drafts for the Wine-10.0 release, so it is emminent / coming very soon.

NOTE: I will update this issue, when the work has begun / first code is pushed.

[nine7nine]

Also, note: After a hiatus - Linux-NSPA is currently up-to-date. Latest builds are Linux-6.13 based.

[BEEFY-JOE]

Happy to hear this and see that you are still active with the project!
Wine-stagging 10.0 just dropped on the arch repos today!

[nine7nine]

@BEEFY-JOE - Ya, I had always intended to move onto Wine-10.x ... but it's been a waiting game + for the last 5-6 months I have been busy with work.

So, now I am just wating for Proton/Wine-10.x to drop and I will start the process of rebasing everything. Mainly, I am waiting for proton due to a handful of patchsets & to see if they pull in NTSync (which i do plan on doing), as I want to start testing it, along side Fsync.

But yes, Wine-Staging is in Arch && Wine-TKG is up-to-date, as well.

[nine7nine]

Working on initial Wine-NSPA-10.x builds. So far:

• Wine NSPA RT Patchset is working
• Proton Fsync changes are ported over (since Wine-TKG doesn't include them)
• My changes to Fsync to be compatible with my RT patchset are working
• Multi-threaded / SHM per thread in Winserver is working
• Dynamic Spin with Adaptive Yield is working
• a handful of one-offs from Proton are applied
• a handful of one-offs hacks / performance related patches are applied
• Initial build completes/compiles and works.

There are a few patchsets that need updating for 10.x, and I will need to rebase/rework the librtpi support. However, at that point I will release an initial build -- even if it is missing a few less critical patchsets / changes...

I figure in another week or so, maybe?

[nine7nine]

Not messing with NTSync for now -- Linux-6.14 should be the first kernel release that actually allows enabling it anyway.

Primarily, the most important features that MUST work are: Wine-NSPA RT patchset, multi-threaded Wineserver, Fsync and LibRTPI support. NTSync can come later, as an option.

[nine7nine]

Small update:

Yesterday I put some time into porting to Wine-10.x... I still have a couple of tricky patchsets to work out, but overall the process has been going faster than expected.

That said: there is a nasty bug in Wine-10.0 that causes some window management bugs with Ableton Live 12. Initially, I had thought it was caused by something in my tree/sources ~ but I've verified it happens in Vanilla Wine-10.0, as well... So that is a bit of a blocker ~ but shouldn't prevent me from continuing to port over changes / work on Wine-NSPA-10.x builds.... Next weekend I am planning to try and finish up things on my end, then it is just waiting for this upstream bug to be fixed.

The last patchset I wil need to port over is the LibRTPI / PI Support, as that is typically the last patchset to be applied -- due to it requiring tree-wide conversions of locks/threads. This shouldn't be too bad though: because I have a patch already that covers most of Wine, so it'll likely be the case where a few chunks fail, I fix those -- then run a script to catch whatever was missed (along with some manual fix ups).

Then of course: I need to spend a bit of time really testing it all.

[BEEFY-JOE]

#there is a nasty bug in Wine-10.0 that causes some window management bugs with Ableton Live 12

These window management bugs were present for me when running Ableton 12 in wine-stagging 9.22 as well.

The work around that I had used was;

Modify winecfg Settings
Under graphics tab, enable Emulate virtual desktop, set the desktop size to something that will fit on your primary display.
Under graphics tab, Uncheck the box for "Allow the window manager to decorate the windows"
Under graphics tab, Uncheck box for "Allow the window manager to control the windows"
Under Input tab, Check the box for "Automatically capture the mouse in full-screen windows"
Under the staging tab, uncheck the box for "Enable CSMT for better graphic performance (deprecated)
Click the "Ok" button to close winecfg

Then when running Ableton, to run it fullscreened inside the wine virtual desktop.
This addressed scaling issues and window boundary problems, however it cuts off the top menu bar.
This can be worked around with using the Alt+F (or Alt+Whatever First letter of menu bar tab), and that would pull up the menus, able to use arrow keys to navigate around it.

I am unsure if this was not the case in the past, as I only started using wine for Ableton with stagging 9.22, but yes this has carried over to wine-stagging 10 as well, and you noted, it's in vanilla wine.

I havent had the time to conduct a regression test to figure out which version of wine these window management issues were introduced in.

Hope that this information helps.

[nine7nine]

That may be useful information, yeah.

I'll need to verify but if it was introduced between 9.21 - 9.22 ~ it shouldn't be all that difficult to find the problematic commit(s)... There's really only a few places where changes could've happened to cause the regressions.

fyi, i don't need to do any of the above -- i can simply maximize the window and get the same behavior you describe (with kwin or hyprland anyway). but yeah, the regression happens in virtual desktop, x11 and wayland... I've found some other regressions too -- there seem to be some locking / blocking issues in Wine-10.x, as well...

So i probably have a couple of options:

• find problematic commits and revert them ( until they are properly fixed).
• rebase on a 9.x / pre-10.x release where none of the issues exist.
• wait until the current issues are fixed, then push a release.

Anyway, when I have some free time; i'll look into the first option and go from there, most likely.

btw, this is exactly why I don't chase releases or plan as if the newest release is always the best. typically, it is not the way to go. haha

[nine7nine]

@BEEFY-JOE - there is a change between 8.21 and 9.0 that causes the messed up menus and window management...

I haven't isolated the exact change - but 8.21 works fine, while 9.0 starts with the messed up menu/window disappearing on vanilla wine... so somewhere in the 9.0-rc* cycles is where the regression was introduced...

I still need to narrow it down -- but sheesh, this regression has existed for a LONG time, AFAICT. I kind of suspect it's in win32u, user32 of dwm code, given the bug exists regardless or X11, Wayland or emulated desktop...

anyway, working on it (hopefully, it just just a single patch I can revert and report)