search

nine7nine / Wine-NSPA

Wine-NSPA: Proaudio & RT focused builds of Wine(-TKG)... WARNING: Forced Pushes && Resets..
22 stars 2 forks source link

Rebase on Wine-9.6+ (Lots breakage / rework to do) #8

Closed nine7nine closed 3 months ago

nine7nine commented 10 months ago

This is all manageable to fix and sort out, and the vast majority is somewhat trivial to fix -- However, it is time-consuming.

Given the scope ~ I'm going to hold off for now

nine7nine commented 9 months ago

I'll wait until Valve Proton is based on Wine-9.0 so that i can pick up certain rebased patches and avoid doing extra work.

no rush, my current build works fine for my needs

nine7nine commented 6 months ago

it looks like the the ntsync kernel driver will land in linux-6.10.

ref: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/log/?s=anzwix&h=char-misc-next

So I think I will plan on rebasing Wine-NSPA around then, with the included support in Wine-NSPA to use this, if desired (and will still support Fsync/Futexes)...

I've been a bit lazy and reluctant to rebase Wine-NSPA: as I've seen/heard about numerous people having problems with some VSTs on Wine-9.0+ ~ and tbh, I haven't had any real issues with my current 8.x builds, beyond stuff that isn't unexpected...

anyway, ntsync being merged into the linux kernel is a good point to rebase Wine-NSPA and add that support.

nine7nine commented 3 months ago

Update:

So all things considered: I'm not going to rebase Wine-NSPA on Wine-9.x (likely at all). More likely, I will wait for Wine-10.x. There are a few reasons for this:

  1. WineWayland Support: It simply is NOT ready in Wine-9.x (and won't be). In particular, because while I do use Wayland (via Hyprland), until the subsurfaces work lands for menus: WineWayland is DOA for me (aside from lots of other issues it currently has... Additionally, most wine-realted wrappers are X11 explicit. So for now XWayland really is my best option.

  2. I have backported a ton of stuff since May 2024. There are very few interesting bits from Wine-9.x+ to actually grab up, meaning a significant rebase on it -- is pretty much a waste of time for me.

  3. I have some Wine-NSPA-specific patchwork that is going to be time-consuming && painful to rebase, when I do. Which makes 2. even less attractive, given the benefits would be absolutely minimal.

This isn't bad news or anything: I don't chase Wine releases anyway, given how often things break during development (and Wine-9.x has been no exception: there has been lots of breakage, issues with yabridge / winelib apps being broken at various points, Ableton Live was broken recently (Wine-9.12), and so on. Meaning, there are ample reasons for me to pick a base, and pull in stuff I want as I go: without worrying about upstream too much.

List of commits (2024):

Wine-NSPA: dwmapi: Sleep in DwmFlush() & gcc fixup Wine-NSPA: Updates, Debugging && Fixes Wine-NSPA: Shell32 Updates && PRIOCLASS_ env patch Wine-NSPA: Support for large page backed file mapping objects Wine-NSPA: Proton CPU Overrides && Backports Wine-NSPA: Backports && Updates Wine-NSPA: ntdll: Dynamic Spin with Adaptive Yield Wine-NSPA: Various Updates Wine-NSPA: Misc Updates && Fixes Wine-NSPA: GCC-14.x Build FIx && Patchwork Updates Wine-NSPA: Updates. Fixes. Keyed Events Futexes Updates && Fixups! Update MSVC (Wine-9.8) && Upstream Fixes Wine-NSPA: Updates && Maintenance Wine-NSPA: Updates && Cleanups! librpti-stuff: librtpi-PI_Support-Core (trim down) librtpi-stuff: WIP! Backup! Wine-NSPA: Remove 7x-branch (Archived)

In reality, without rebasing at all. Wine-NSPA is somewhere between Wine-8.19 - 9.12 already. But also includes a ton of uniquely Wine-NSPA stuff, not found elsewhere (inlcuding in Proton, TKG and co).