Wine 6.0-RC1 Released Following Last Minute Changes

[phoronix]

Phoronix: Wine 6.0-RC1 Released Following Last Minute Changes

As expected, the first release candidate of Wine 6.0 is now available for testing for this annual update to Wine for running Windows programs and games on Linux and other platforms...

http://www.phoronix.com/scan.php?page=news_item&px=Wine-6.0-RC1-Released

[pinguinpc]

This wine version fix some cinematics case xanadu, ys oath in felghana and maybe others





however lack of color converter

[CochainComplex]

how is the state of making use of futex2 ? I know that it has not landed kernel upstream yet but are there already some "if available " functions implemented?

[Cybmax]

how is the state of making use of futex2 ? I know that it has not landed kernel upstream yet but are there already some "if available " functions implemented?

If by futex2 you are referring to "fsync" or "futex wait multiple", then no.

Esync - Eventfd synchronization - which fsync is somewhat related/dependant on is not upstream either (staging only), so i would venture to say it will be quite a while, if ever, till this is near upstream.

This could ofc change if fsync would be upstreamed for kernel, but i guess since this currently requires a patched kernel that probably none of the major distros currently use, they would hold off this until then. Speculation ofc, but using a custom kernel even tho many do, is some kind of "enthusiast" thing to do. I mean, it is not hard, but if you are a "stability above all for my distro" (perfectly valid thing to be), you wont be using fsync patched kernel. Since this is not upstream, things might change on the implementation until then, and to incorporate a rather huge patchset for wine that requires non-upstreamed kernel patches? Well.. i can see why it wont happen

Having it as part of the -staging set i could see tho...

[CochainComplex]

If by futex2 you are referring to "fsync" or "futex wait multiple", then no.

Esync - Eventfd synchronization - which fsync is somewhat related/dependant on is not upstream either (staging only), so i would venture to say it will be quite a while, if ever, till this is near upstream.

This could ofc change if fsync would be upstreamed for kernel, but i guess since this currently requires a patched kernel that probably none of the major distros currently use, they would hold off this until then. Speculation ofc, but using a custom kernel even tho many do, is some kind of "enthusiast" thing to do. I mean, it is not hard, but if you are a "stability above all for my distro" (perfectly valid thing to be), you wont be using fsync patched kernel. Since this is not upstream, things might change on the implementation until then, and to incorporate a rather huge patchset for wine that requires non-upstreamed kernel patches? Well.. i can see why it wont happen

Having it as part of the -staging set i could see tho...

Thx for your answer - i mean those https://lwn.net/Articles/825860/
futex wait multiple is afaik part of it.

basicly I'm refering to this article https://phoronix.com/scan.php?page=n...ystem-Call-RFC

[Cybmax]

Hmm.. i see... I think i might have to take a wee bit harder dive into this, cos i kinda thought futext wait multiple was more or less the same as futex2, but it might not be.

I do not know if wine w/futex patches works the same/better/worse with a kernel patched with futex2 patches (or if it is indeed huge differences between them).

The patchset i use for my custom kernel atm is : https://github.com/sirlucjan/kernel-...patches-v3-sep
I do believe these are the same as the initial valve implemented ones, and not directly "futex2".

Worth investigating a bit i think

PS. I noticed Zebediah Figura had signed off on the futex2 patchset too.