Created attachment 245080 [details] Patch to update emulators/wine-devel from 8.15 to 8.16 This patch, which goes on top of PR 273837 and its update from 8.14 to 8.15, updates wine-devel to version 8.16.
This build and works. However, the OSS driver has a bug in it which I reported: https://bugs.winehq.org/show_bug.cgi?id=55639 The audio is going to the device one higher than the device chosen.
On a side note, I am unable to get any sounds using ALSA with my tweaked asound.conf or the default one. I have to stick with OSS.
Created attachment 245124 [details] Patch to allow i386 to build Revert 0b3f90ab1485d5bd32bd72d41c7fd8213b3b95b9 which breaks FreeBSD/i386 build: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271201#c8 Plus, it appears to break on Linux for some people: https://bugs.winehq.org/show_bug.cgi?id=55408#c6
The inability of ALSA to play any sound was due to the configuration of alsa-plugins. It turns out that BUFSZ_P2 can break playback. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274047#c1 Two more items now: - The microphone records crackling through wine-devel for both OSS and ALSA. Noticed in Rocket League as well as this simple program: https://github.com/BlueDragon28/MicrophoneLoopback The microphone does work for native Firefox and Mumble. - Homeworld 2 crashes with: Unhandled exception: unimplemented function winegstreamer.dll.winegstreamer_create_video_decoder called in 32-bit code (0x6288ea91). I think it is just a configuration issue. I rebuilt the i386 wine-devel package with gstreamer enabled (hopefully), but it still failed the same way.
Created attachment 245167 [details] Patch to enable gstreamer
(In reply to Sean Farley from comment #2) > On a side note, I am unable to get any sounds using ALSA with my tweaked > asound.conf or the default one. I have to stick with OSS. This is an indication to keep the OSS option for the time being (even if your ALSA problems have been resolved in the meantime).
(In reply to Gerald Pfeifer from comment #6) I would appreciate keeping the OSS option alive. It is easier to configure than ALSA for some setups involving multiple sound devices. With OSS, winecfg shows all the devices separately for input and output to easily choose. I will try to get gstreamer working independently from this issue. I think the issue was in 8.11 or 8.14 too, so this PR should not be held back due to it.
Created attachment 245192 [details] Patch to enable gstreamer Here is an update to the gstreamer patch to include all needed files for it. With this, Homeworld 2 now "runs" on my system. There is some issue where the focus in game play slides off into the weeds, but that may be game-specific.
(In reply to Sean Farley from comment #8) > Patch to enable gstreamer It would be nice to keep USES alphabetically sorted. And, more importantly, for the sake of reproducible builds --without-gstreamer should not be simply removed, rather replaced by --with-gstreamer. That is, we should be explicit about all options. (Admittedly in this case USES=...gstreamer... will in principle ensure everything is in place; still a good practice - which may catch an issue later on.)
Note, I see the benefit, just am not able to properly test myself so this will need someone else to possibly commit. Question: Should this maybe be an option to keep the port somewhat "light"?
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=e79d1724732cf329b77f66f3f14d7c691fdd7e80 commit e79d1724732cf329b77f66f3f14d7c691fdd7e80 Author: Gerald Pfeifer <gerald@FreeBSD.org> AuthorDate: 2023-10-14 21:43:56 +0000 Commit: Gerald Pfeifer <gerald@FreeBSD.org> CommitDate: 2023-10-14 21:43:57 +0000 emulators/wine-devel: Update to Wine 8.16 This includes the following changes: - Beginnings of a DirectMusic revival. - Many fixes and improvements in the regression tests. - Various bug fixes. And one fix of mine to keep FreeBSD building. Reset maintainer since sadly Damjan has not been available for the last ten months due to personal circumstances. Thank you for your contributions as maintainer and before that - and I hope to see you back! PR: 273987 Approved by: maintainer timeout emulators/wine-devel/Makefile | 4 ++-- emulators/wine-devel/distinfo | 6 +++--- emulators/wine-devel/pkg-plist | 6 ++++++ 3 files changed, 11 insertions(+), 5 deletions(-)
The issue of this PR per se is thus closed, so we could close it. Alas there's now to patches from Sean here: - On the i386 build I still believe we should first and foremost get clang fixed. This probably is best done by trying to build on i386 and then reporting the build failure, including preprocessed source file, as a distinct PR. - The gstreamer patch looks fine modulo my comment #9, I am just not able to properly test (and would not be able to update this port anymore once it's in).
(In reply to Gerald Pfeifer from comment #12) > reporting the build failure https://github.com/llvm/llvm-project/issues/62339
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=944eff5cfa5f0fe00d44a04f891b19928a34c335 commit 944eff5cfa5f0fe00d44a04f891b19928a34c335 Author: Gerald Pfeifer <gerald@FreeBSD.org> AuthorDate: 2023-10-16 08:23:03 +0000 Commit: Gerald Pfeifer <gerald@FreeBSD.org> CommitDate: 2023-10-16 08:23:03 +0000 emulators/wine-devel: Improve configuration for ALSA and OSS Use ALSA_CONFIGURE_WITH and OSS_CONFIGURE_WITH instead of the ALSA_CONFIGURE_ON and OSS_CONFIGURE_ON forms. This properly handles the case where neither the ALSA nor OSS option are set. It's more resilient to future changes. And shorter. PR: 273987 emulators/wine-devel/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
This is (should be) an improvement by and in itself. It also is a step towards enabling gstreamer in what I believe is a better approach than attachment #245192 [details]. Unless I am missing something we'll only want to pull in gstreamer if one of ALSA or OSS are enabled?
Created attachment 245706 [details] Alternate patch to enable gstreamer Here is an alternate patch to enable gstreamer based on my rework of the ALSA and OSS options. gstreamer is now enabled (only) if one of these two is selected. @scf, others, can you please test, ideally with ALSA as well as OSS?
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=63ef7d1ab018109313476c9b03632c4fe1ab6633 commit 63ef7d1ab018109313476c9b03632c4fe1ab6633 Author: Gerald Pfeifer <gerald@FreeBSD.org> AuthorDate: 2023-10-22 16:07:12 +0000 Commit: Gerald Pfeifer <gerald@FreeBSD.org> CommitDate: 2023-10-22 16:15:52 +0000 emulators/wine-devel: Use GStreamer when supporting sound When ALSA or OSS are enabled, i.e., we have sound enabled, pull in and use GStreamer as well. PR: 273987 Reported by: scf emulators/wine-devel/Makefile | 10 ++++++++++ emulators/wine-devel/pkg-plist | 4 ++++ 2 files changed, 14 insertions(+)
This should address everything that was reported and/or I found related to ALSA, OSS, and GStreamer. I plan on back porting it to emulators/wine and maybe emulators/wine7.
Sorry I did not report back in time, but I have been battling an update to -CURRENT, and am now getting back on track. I do not know how anyone tests Wine (specifically -devel) on FreeBSD. Nothing will run unless I have the corresponding 32 bit Wine component built, and installed. I have a patch in my local worktree, that incorporates Sean's patch into the Port, just so I can build Wine again, however, it does mean Wine is usable, the old "could not load kernel32.dll" has resurfaced, but at least Wine builds now. Gerald, I noticed when build testing the GStreamer patch, a number of warnings were produced during stage-qa. I made the following modifications: > ALSA_USES=> > gnome gstreamer > ALSA_USE=> > GNOME=glib20 > OSS_USES=> > gnome gstreamer > OSS_USE=> > GNOME=glib20 Thanks.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=8241302dda4980341c3162f21aa8ded4e4a3b4d1 commit 8241302dda4980341c3162f21aa8ded4e4a3b4d1 Author: Gerald Pfeifer <gerald@FreeBSD.org> AuthorDate: 2023-10-24 22:16:18 +0000 Commit: Gerald Pfeifer <gerald@FreeBSD.org> CommitDate: 2023-10-24 22:16:18 +0000 emulators/wine: Improve configuration for ALSA and OSS Use ALSA_CONFIGURE_WITH and OSS_CONFIGURE_WITH instead of the ALSA_CONFIGURE_ON and OSS_CONFIGURE_ON forms. This properly handles the case where neither the ALSA nor OSS option are set. It's more resilient to future changes. And shorter. (This back ports 944eff5cfa5f from the wine-devel port.) PR: 273987 emulators/wine/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
(In reply to Alastair Hogge from comment #19) > I do not know how anyone tests Wine (specifically -devel) on FreeBSD. I have a nightly builder and ensure it keeps building on x86-64 (aka amd64). Without that, Wine on FreeBSD would be several layers deep into build failures. I have not been using Wine on FreeBSD for ... two decades, since I switched to Linux on my desktop/notebook upon a job change. > Nothing will run unless I have the corresponding 32 bit Wine component > built, and installed. I have a patch in my local worktree, that > incorporates Sean's patch into the Port, just so I can build Wine again, > however, it does mean Wine is usable, the old "could not load kernel32.dll" > has resurfaced, but at least Wine builds now. I believe the way out is to rip off the band aid that the legacy implementation of WoW64 on FreeBSD is and move to what upstream has been working on for the last two years. Wine 8.0 has a first implementation thereof, and in the meantime Wine 8.x (wine-devel) is rather complete. That does require some work on the toolchain which has been stuck. I plan on removing the old, which as you found, does not work even once you got it build on i386, and add notes for someone to pick up and add the missing pieces in the next weeks.
(In reply to Gerald Pfeifer from comment #21) > I believe the way out is to rip off the band aid that the legacy > implementation of WoW64 on FreeBSD is and move to what upstream > has been working on for the last two years. Does new WoW64 actually work on Linux? It's still labeled as experimental, after all.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=a9a707cc8f112c79b6d8cbf9ab0f75bd99294cfa commit a9a707cc8f112c79b6d8cbf9ab0f75bd99294cfa Author: Gerald Pfeifer <gerald@FreeBSD.org> AuthorDate: 2023-11-01 12:17:22 +0000 Commit: Gerald Pfeifer <gerald@FreeBSD.org> CommitDate: 2023-11-01 12:32:50 +0000 emulators/wine-devel: Unbreak on i386 Revert an upstream change to tools/winebuild/res32.c that exposed resource contraints for clang on i386 (cf. the upstream reports at https://github.com/llvm/llvm-project/issues/62339 and https://bugs.winehq.org/show_bug.cgi?id=54889 ). Apply this patch only on i386 to minimize divergence and risk on 64-bit x86. PR: 273987 [1], 271201 [2] Bi-sected by: Damjan Jovanovic <damjan.jov@gmail.com> [2] Motivated by: scf [1] emulators/wine-devel/Makefile | 2 +- .../files/extra-patch-tools-winebuild-res32 (new) | 95 ++++++++++++++++++++++ 2 files changed, 96 insertions(+), 1 deletion(-)
(In reply to Alex S from comment #22) > Does new WoW64 actually work on Linux? It's still labeled as > experimental, after all. My understanding is that leading up to Wine 9.0 the new approach is the default; but let's see how that works out. That said: Does the old WoW64 actually work on FreeBSD? Success (or failure) reports welcome - Alex, Sean, and Alistair, and of course others as well!
Closing this since the upgrade to 8.16 is in (and I went to 8.18 and 8.19 since then) and both issues/patches Sean raised are in as well, if in somewhat different form. Thanks!
(In reply to Gerald Pfeifer from comment #24) > That said: Does the old WoW64 actually work on FreeBSD? Old WoW64 works for me, although I had to patch executable paths a bit recently*. The new mode immediately crashes in a way that I don't really understand. I've yet to try new WoW64 with a Linux Wine build under Linux emulation for comparison. * https://github.com/freebsd/freebsd-ports/commit/1f07ec6014a3c3380a731efdc74a3cf88b91ca29#diff-04eaa16fadbb0dcc62021a82efb4ebda345ce317e2d838c5474823e4fd9573a2 and https://github.com/freebsd/freebsd-ports/commit/1f07ec6014a3c3380a731efdc74a3cf88b91ca29#diff-f5a78cdfb3a213ac852230c9fe34ef01ffeeaafdd7ea06b7674392a35e704460
(In reply to Gerald Pfeifer from comment #24) Thanks for the callout for testing. I am now just getting around to testing wine-devel-8.19,1 on some recentish 15-CURRENT. wine-devel on amd64 builds, however, i386 seems to be missing much pkg-plist items, from my first initial poudriere-testport. Would you like me to submit a patch to this existing BR, or submit a new report? Thanks.
See bug #274905
(In reply to Alastair Hogge from comment #27) > Would you like me to submit a patch to this existing BR, or submit > a new report? Separate, like you did, was great. This report already had three distinct issues in one. Plus that way other committers are more likely to help (which indeed happened here :-). Thanks!
(In reply to Alex S from comment #26) > Old WoW64 works for me, although I had to patch executable paths a bit > recently*. The new mode immediately crashes in a way that I don't really > understand. Did you try with wine-devel (Wine 8.19) or wine/wine-proton (based on Wine 8.0.2, which doesn't have some 10 months of work on the new WoW64)? I am not in a position to properly test myself. If there are (necessary) changes to the scripts wine-devel uses, it would be great could you share/ submit them. Same for emulators/wine, of course!
(In reply to Gerald Pfeifer from comment #30) > wine-devel (Wine 8.19) or wine/wine-proton Last time I tried new WoW64 was roughly 2 months ago with Wine 8.11. > changes to the scripts wine-devel uses The relevant parts were pointed out in the previous comment. I might submit them, but I'd rather work on something else.
(In reply to Alex S from comment #31) > The relevant parts were pointed out in the previous comment. I might submit them, but I'd rather work on something else. I have not forgotten about this helpful information, tho I am currently busy with another Port. If noone beats me, I will look at those patches; a fully functioning Wine would be great. Thanks.