https://bugs.winehq.org/show_bug.cgi?id=39023
Bug ID: 39023 Summary: Final Fantasy XI Using a Bluetooth PS3 Controller crashes the game. Product: Wine Version: 1.7.47 Hardware: x86-64 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: wine@sharpner.de
Using a ps3 bluetooth controller and setting it up with the ffxiutils. Configuration works, but the game crashes with gamepad enabled.
fixme:qtdatahandler:myComponentRoutineProc unhandled select 0x44 wine.bin(820,0x401f4000) malloc: *** error for object 0x4021c830: double free *** set a breakpoint in malloc_error_break to debug wine: Assertion failed at address 0x000b:0x988b669a (thread 0025), starting debugger...
1.7.48 is also affected, here it wasn't enough to disable gamepad in the configuration but I also had to disable bluetooth.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #1 from Naan wine@sharpner.de --- I doublechecked my settings, I set the Windows Version to 2000.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #2 from Ken Sharp imwellcushtymelike@gmail.com --- Please attach the FULL console output from a CLEAN wineprefix with no third party wrappers. http://wiki.winehq.org/Bugs
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #3 from Naan wine@sharpner.de --- Created attachment 52070 --> https://bugs.winehq.org/attachment.cgi?id=52070 log file while configuring gamepad
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #4 from Naan wine@sharpner.de --- Created attachment 52071 --> https://bugs.winehq.org/attachment.cgi?id=52071 log file ingame with crash at the end
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #5 from Naan wine@sharpner.de --- Done. Hope it helps.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #6 from Naan wine@sharpner.de --- It's a fresh install, with no special settings. I don't use any winetricks. I have only this game installed. My brew flags:
Build: pkg-config ✔ Required: freetype ✔, jpeg ✔, libgphoto2 ✔, little-cms2 ✔, libicns ✔, libtiff ✔, sane-backends ✔ Optional: libgsm ✘
Let me know if you need more info.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #7 from Naan wine@sharpner.de --- Created attachment 52075 --> https://bugs.winehq.org/attachment.cgi?id=52075 output 1.7.49
with the latest wine version the game does not totally crash anymore.
But it displays a windows exception on first use and then the controller won't work anymore.
But the game seems to be running stable after the exception.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #8 from Naan wine@sharpner.de --- Created attachment 52281 --> https://bugs.winehq.org/attachment.cgi?id=52281 1.7.51 output
bug still exists in 1.7.51.
https://bugs.winehq.org/show_bug.cgi?id=39023
Naan wine@sharpner.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine@sharpner.de
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #9 from Naan wine@sharpner.de --- Created attachment 52282 --> https://bugs.winehq.org/attachment.cgi?id=52282 1.7.51 verbose output (WINEDEBUG=warn+all)
I filtered all "warn:d3d:context_bind_shader_resources No resource view bound at index 0, 0." because of the file size limit.
https://bugs.winehq.org/show_bug.cgi?id=39023
Naan wine@sharpner.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #10 from Naan wine@sharpner.de --- is anyone even seeing those updates? Otherwise I would stop providing them with every version....
Some reaction would be nice, even if it is "not going to be fixed".
https://bugs.winehq.org/show_bug.cgi?id=39023
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aric@codeweavers.com, | |ken@codeweavers.com Component|-unknown |directx-dinput
--- Comment #11 from Austin English austinenglish@gmail.com --- (In reply to Naan from comment #10)
is anyone even seeing those updates?
Yes :)
Otherwise I would stop providing them with every version....
It is helpful, even if the bug doesn't get immediate attention. The squeaky wheel gets greased..
Some reaction would be nice, even if it is "not going to be fixed".
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #12 from Ken Thomases ken@codeweavers.com --- Your most recent attachments do not include the backtrace. Please add that, since there have been recent improvements to backtrace generation in Wine. (Although, you'd need an unstripped build, or build from source, to get the best backtrace quality.)
In attachment 52071, the process was gone by the time winedbg tried to grab the backtrace, but hopefully it will be able to get it this time.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #13 from Naan wine@sharpner.de --- Thanks for your responses!
Will attach another one later.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #14 from Naan wine@sharpner.de --- (In reply to Ken Thomases from comment #12)
Your most recent attachments do not include the backtrace. Please add that, since there have been recent improvements to backtrace generation in Wine. (Although, you'd need an unstripped build, or build from source, to get the best backtrace quality.)
In attachment 52071 [details], the process was gone by the time winedbg tried to grab the backtrace, but hopefully it will be able to get it this time.
I always attached everything. You said that there changed something in backtrace generation... Do I now actively need to enable it somehow?
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #15 from Ken Thomases ken@codeweavers.com --- When the game crashes, Wine puts up a crash dialog. If you just click Close, then the backtrace will be written to the output. If you're collecting a log, then it will be in the log.
However, if you click Show Details, then the backtrace is shown in the dialog, instead. It won't be in the log. If you don't explicitly save it to file (and attach that file), then it's lost.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #16 from Naan wine@sharpner.de --- Created attachment 52357 --> https://bugs.winehq.org/attachment.cgi?id=52357 in FFXConfig while ps3 controller connects
Here I got a stacktrace.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #17 from Naan wine@sharpner.de --- Created attachment 52358 --> https://bugs.winehq.org/attachment.cgi?id=52358 Backtrace from Application Dialog
I figured out why my last dumps don't got any backtrace. The wine process uses one complete cpu and doesn't stop until I kill it.
These are the running processes: 69739 ?? Ss 1:11.87 /usr/local/Cellar/wine/1.7.51/lib/../bin/wineserver 69745 ?? Ss 0:00.04 /usr/local/Cellar/wine/1.7.51/lib/../bin/wine.bin C:\windows\system32\services.exe 69747 ?? S 0:00.17 /usr/local/Cellar/wine/1.7.51/lib/../bin/wine.bin C:\windows\system32\winedevice.exe MountMgr 69749 ?? S 0:00.03 /usr/local/Cellar/wine/1.7.51/lib/../bin/wine.bin C:\windows\system32\plugplay.exe 69751 ?? Ss 0:00.22 /usr/local/Cellar/wine/1.7.51/lib/../bin/wine.bin C:\windows\system32\explorer.exe /desktop 69753 s000 R 39:08.73 /usr/local/Cellar/wine/1.7.51/lib/../bin/wine.bin C:\Program Files\PlayOnline\SquareEnix\PlayOnlineViewer\pol.exe /game 69840 s000 S 0:00.43 /usr/local/Cellar/wine/1.7.51/lib/../bin/wine.bin winedbg --auto 35 504
But I get the prompt which forces which displayed me the attached backtrace
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #18 from Naan wine@sharpner.de --- Ah and BTW: thanks for the awesome work with wine, the quality of it is just amazing!
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #19 from Ken Thomases ken@codeweavers.com --- Thanks for those backtraces. They don't seem as complete as they should be, and I don't know why. Wine isn't seeing the Mac-native frameworks, which suggests that Wine isn't finding the dynamic loader's image list. It also isn't seeing the full range of addresses for the Wine DLLs that it is seeing, which prevents it from finding symbols for the addresses.
It seems you're running El Capitan. Something may have changed with that in such a way that's it's interfering with Wine's ability to interpret the debug information.
Can you try something? Please run the following commands and post the output:
xcrun atos -o /usr/local/Cellar/wine/1.7.51/lib/wine/dinput.dll.so -l 4b590000 0x4b5a37a7 0x4b5a00b9 0x4b5a011b
xcrun atos -o /usr/local/Cellar/wine/1.7.51/lib/wine/dinput.dll.so -l 47360000 0x4737767c 0x47374190 0x47374223
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #20 from Naan wine@sharpner.de --- (In reply to Ken Thomases from comment #19)
Thanks for those backtraces. They don't seem as complete as they should be, and I don't know why. Wine isn't seeing the Mac-native frameworks, which suggests that Wine isn't finding the dynamic loader's image list. It also isn't seeing the full range of addresses for the Wine DLLs that it is seeing, which prevents it from finding symbols for the addresses.
It seems you're running El Capitan. Something may have changed with that in such a way that's it's interfering with Wine's ability to interpret the debug information.
Can you try something? Please run the following commands and post the output:
xcrun atos -o /usr/local/Cellar/wine/1.7.51/lib/wine/dinput.dll.so -l 4b590000 0x4b5a37a7 0x4b5a00b9 0x4b5a011b
xcrun atos -o /usr/local/Cellar/wine/1.7.51/lib/wine/dinput.dll.so -l 47360000 0x4737767c 0x47374190 0x47374223
Yeah I've been using El Capitan for a few days now. But the problem was identical with yosemite also.
But yeah, debug output is different since either el capitan or *.51 I don't know...
Here the output for those commands:
xcrun atos -o /usr/local/Cellar/wine/1.7.51/lib/wine/dinput.dll.so -l 4b590000 0x4b5a37a7 0x4b5a00b9 0x4b5a011b _dump_DIDATAFORMAT (in dinput.dll.so) + 462 _wine_spec_pe_header (in dinput.dll.so) + 57529 _wine_spec_pe_header (in dinput.dll.so) + 57627
xcrun atos -o /usr/local/Cellar/wine/1.7.51/lib/wine/dinput.dll.so -l 47360000 0x4737767c 0x47374190 0x47374223 IDirectInputDevice2WImpl_GetObjectInfo (in dinput.dll.so) + 34 fill_DataFormat (in dinput.dll.so) + 613 fill_DataFormat (in dinput.dll.so) + 760
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #21 from Ken Thomases ken@codeweavers.com --- Thanks for that command output. To interpret it further, I'm going to need the actual dinput.dll.so that homebrew built. Could you attach a compressed archive of it? If it's too big (doubtful), you can just email it to me directly. Thanks again.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #22 from Naan wine@sharpner.de --- Here is the file to download:
https://www.dropbox.com/sh/2mw4emfj5m9qveb/AAAN0iTKruJxzM5mOKcUj9DRa?dl=0
Thx for looking into it
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #23 from Ken Thomases ken@codeweavers.com --- Created attachment 52364 --> https://bugs.winehq.org/attachment.cgi?id=52364 Check IOHIDDeviceGetValue() result before using returned value object
Can you please build with this patch and see if it fixes the crash. Also, check whether the controller works properly.
Whether it does or doesn't, please collect a +tid,+seh,+dinput log. I've added some logging for the case where it had been crashing and I'm curious to know what error IOKit is returning when it fails to return a value object.
Basically, the code calls IOHIDDeviceGetValue() for a particular element of the device to get a value object. It then calls IOHIDValueGetIntegerValue() to get the numeric value from that object. It seems the first call was failing and the code didn't check for that. So, when it did the next call, that blew up. But really, I don't know of a good reason why the first call would fail.
Thanks!
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #24 from Ken Thomases ken@codeweavers.com --- As a separate matter, I no longer think the deficient backtraces have anything to do with El Capitan. I think they have to do with Homebrew and how it installs Wine.
I'm working on a fix for that, but in the meantime you can use the following to work around the problem:
export WINELOADER=/usr/local/Cellar/wine/1.7.51/bin/wine.bin
If you use the same shell to later run a different Wine, be sure to "unset WINELOADER" first.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #25 from Naan wine@sharpner.de --- (In reply to Ken Thomases from comment #23)
Created attachment 52364 [details] Check IOHIDDeviceGetValue() result before using returned value object
Can you please build with this patch and see if it fixes the crash. Also, check whether the controller works properly.
Whether it does or doesn't, please collect a +tid,+seh,+dinput log. I've added some logging for the case where it had been crashing and I'm curious to know what error IOKit is returning when it fails to return a value object.
Basically, the code calls IOHIDDeviceGetValue() for a particular element of the device to get a value object. It then calls IOHIDValueGetIntegerValue() to get the numeric value from that object. It seems the first call was failing and the code didn't check for that. So, when it did the next call, that blew up. But really, I don't know of a good reason why the first call would fail.
Thanks!
So this is what I did: 1. Change the brew formula to apply your patch 2. Reinstall wine 3. Start the game with: WINEDEBUG="+tid,+seh,+dinput" WINELOADER=/usr/local/Cellar/wine/1.7.51/bin/wine.bin wine polboot.exe > debug.log 2>&1 4. Sream: IT WORKS!!!
So thank you very much :D you're the man!
But I will still attach the log file in case you need it for the Wineloader thingy, but unfornately it got almost 400MB, so you gotta download it here again: https://www.dropbox.com/s/en6vrm6ewv7bj5l/debug.tar.gz?dl=0 (10MB tar.gz)
Since you're probably able to read passwords through the dinput debug messages please let me know when you're done so I can remove that file :P
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #26 from Naan wine@sharpner.de --- (In reply to Ken Thomases from comment #24)
As a separate matter, I no longer think the deficient backtraces have anything to do with El Capitan. I think they have to do with Homebrew and how it installs Wine.
I'm working on a fix for that, but in the meantime you can use the following to work around the problem:
export WINELOADER=/usr/local/Cellar/wine/1.7.51/bin/wine.bin
If you use the same shell to later run a different Wine, be sure to "unset WINELOADER" first.
The patch only introduces debug log, so the problem is be the Wineloader?
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #27 from Ken Thomases ken@codeweavers.com --- (In reply to Naan from comment #25)
So this is what I did:
- Change the brew formula to apply your patch
- Reinstall wine
- Start the game with: WINEDEBUG="+tid,+seh,+dinput"
WINELOADER=/usr/local/Cellar/wine/1.7.51/bin/wine.bin wine polboot.exe > debug.log 2>&1 4. Sream: IT WORKS!!!
So thank you very much :D you're the man!
You're welcome! I'm glad to hear it. And thank you for testing!
But I will still attach the log file in case you need it for the Wineloader thingy, but unfornately it got almost 400MB, so you gotta download it here again: https://www.dropbox.com/s/en6vrm6ewv7bj5l/debug.tar.gz?dl=0 (10MB tar.gz)
Since you're probably able to read passwords through the dinput debug messages please let me know when you're done so I can remove that file :P
Thanks, I got it.
(In reply to Naan from comment #26)
The patch only introduces debug log, so the problem is be the Wineloader?
My patch (attachment 52364) did more than just add logging. If the IOHIDDeviceGetValue() function fails, it skips trying to query the value with IOHIDValueGetIntegerValue(). The "break" statements exit out of the switch statement and thus prevent the immediately-following code from running. That's the code which would have crashed.
Setting the WINELOADER variable just helps produce better backtraces if it crashes. Since it didn't crash, that part didn't make any difference this time.
If you have other crashes with this version of Wine, then you can use that to get better backtraces. I expect that it won't be necessary in future versions of Wine, because I've submitted a patch to improve backtraces without it.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #28 from Ken Thomases ken@codeweavers.com --- Hmm. That's strange. The log doesn't show any of the WARN statements that my patch added. That suggests that the problem didn't occur and you wouldn't have had a crash even without my patch, at least on that run.
Was the crash completely reproducible every time? Is there any chance this was just a "lucky" run?
Basically, I'm looking for log lines which include "IOHIDDeviceGetValue". If there are no lines like that, then you wouldn't have crashed, anyway.
There's always a chance that the bug is due to something unrelated, like stack corruption. If that's the case, then just compiling a slightly altered version of the code could make it go away. :-/
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #29 from Naan wine@sharpner.de --- Indeed this run was like 30 seconds. But the character moved for the first time.
I won't have time to test for two days now (Oktoberfest yay) but on Sunday I should manage to make a long stress test.
Do you have any ideas how to decrease the log file size? 400mb per minute will fill my laptop up really fast :D
Is a 'grep "IOHIDDeviceGetValue"' enough for you? Could it also be due to the WINELOADER that it worked?
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #30 from Ken Thomases ken@codeweavers.com --- (In reply to Naan from comment #29)
I won't have time to test for two days now (Oktoberfest yay) but on Sunday I should manage to make a long stress test.
Do you have any ideas how to decrease the log file size? 400mb per minute will fill my laptop up really fast :D
Is a 'grep "IOHIDDeviceGetValue"' enough for you?
Well, that's a good start. Maybe that will show me enough to understand what's going on. If not, we can try something else.
Could it also be due to the WINELOADER that it worked?
I don't expect it to make a difference, but maybe I'm wrong. Try it with and without to see if you notice a difference. (The most obvious difference is if you get "IOHIDDeviceGetValue" lines with one but not the other.)
Thanks again.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #31 from Naan wine@sharpner.de --- Okay will do.
I'll get back to you.
I'll also double check my settings to check whether something has changed.
Thanks so far
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #32 from Naan wine@sharpner.de --- Created attachment 52367 --> https://bugs.winehq.org/attachment.cgi?id=52367 I got it to crash again
These are the last 5000 lines of the debug output. But I didn't find your IOHIDDeviceGetValue in it... :(
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #33 from Ken Thomases ken@codeweavers.com --- I suspect the problem may be that two threads are calling into the Mac HID library at the same time. It may be that we need to use a critical section to prevent that entirely. Or maybe using IOHIDTransaction objects will be enough to fix it. The latter would fix it if the problem is just that the element values are being released by one thread (because a new HID report has been received) while the other thread is still using them.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #34 from Naan wine@sharpner.de --- So I guess buying a different controller won't help me much with this problem.
Is there anything else I could try?
I read that at wineconf you decided to restructure the HID stack, maybe I'm more lucky with the new architecture :/
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #35 from Ken Thomases ken@codeweavers.com --- (In reply to Naan from comment #34)
So I guess buying a different controller won't help me much with this problem.
Correct, buying a new controller probably won't help.
Is there anything else I could try?
Not that I can think of at the moment.
I read that at wineconf you decided to restructure the HID stack, maybe I'm more lucky with the new architecture :/
Quite possibly, yes. We may fix it some other way in the meantime. If so, we'll probably ask you test some patches, eventually.
https://bugs.winehq.org/show_bug.cgi?id=39023
Rubén Reina ruben.reina.dev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ruben.reina.dev@gmail.com
--- Comment #36 from Rubén Reina ruben.reina.dev@gmail.com --- I can confirm using the latest release Wine 1.8 stable the game has random crashes if a PS3 controller is connected using OS X El Capitan Bluetooth.
Once I disable my bluetooth interface I can play using the keyboard, but it is a bit frustrating. I hope this information can be useful to you.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=39023
Alex Vallée avallee@chromium.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |avallee@chromium.org
--- Comment #37 from Alex Vallée avallee@chromium.org --- Created attachment 58590 --> https://bugs.winehq.org/attachment.cgi?id=58590 Add locking around access to the same device id.
Ignore the extra logging, I think the main issue for the crash is that FFXI is accessing the same HID device from 2 threads. I noticed that if one of the threads dies the whole game goes down. In other cases you can just continue and that thread dies but the rest of the game is fine.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #38 from Alex Vallée avallee@chromium.org --- (In reply to Ken Thomases from comment #33)
I suspect the problem may be that two threads are calling into the Mac HID library at the same time. It may be that we need to use a critical section to prevent that entirely. Or maybe using IOHIDTransaction objects will be enough to fix it. The latter would fix it if the problem is just that the element values are being released by one thread (because a new HID report has been received) while the other thread is still using them.
I went with the idea and added a mutex for each device id. Seems to work for me.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #39 from Naan wine@sharpner.de --- (In reply to Alex Vallée from comment #38)
(In reply to Ken Thomases from comment #33)
I suspect the problem may be that two threads are calling into the Mac HID library at the same time. It may be that we need to use a critical section to prevent that entirely. Or maybe using IOHIDTransaction objects will be enough to fix it. The latter would fix it if the problem is just that the element values are being released by one thread (because a new HID report has been received) while the other thread is still using them.
I went with the idea and added a mutex for each device id. Seems to work for me.
Can you provide a patch for me or is this already upstream? thx in advance!
https://bugs.winehq.org/show_bug.cgi?id=39023
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #40 from Alex Vallée avallee@chromium.org --- Hey Naan,
you can apply the patch from comment #37. I haven't gone and cleaned it up for submission, but it would be nice to know if it fixes the problem for you.
As an aside, I use a wired usb logitech controller and the game also crashes if I disconnect it, that's something I'd like to also fix.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #41 from Naan wine@sharpner.de --- (In reply to Alex Vallée from comment #40)
Hey Naan,
you can apply the patch from comment #37. I haven't gone and cleaned it up for submission, but it would be nice to know if it fixes the problem for you.
As an aside, I use a wired usb logitech controller and the game also crashes if I disconnect it, that's something I'd like to also fix.
Thanks Alex!
I tested your patch today for about 15 minutes and so far it seems really to have fixed the issue! (I'm not 100% sold yet, since this is really shaky, but tomorrow I give it a longer try).
Really really appreciate it! Sorry I missed that patch at first :P this gui is not the easiest...
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #42 from Naan wine@sharpner.de --- (In reply to Naan from comment #41)
(In reply to Alex Vallée from comment #40)
Hey Naan,
you can apply the patch from comment #37. I haven't gone and cleaned it up for submission, but it would be nice to know if it fixes the problem for you.
As an aside, I use a wired usb logitech controller and the game also crashes if I disconnect it, that's something I'd like to also fix.
Thanks Alex!
I tested your patch today for about 15 minutes and so far it seems really to have fixed the issue! (I'm not 100% sold yet, since this is really shaky, but tomorrow I give it a longer try).
Really really appreciate it! Sorry I missed that patch at first :P this gui is not the easiest...
Tested it today for multiple hours. Can confirm that the patch works!
Thanks again :-)
https://bugs.winehq.org/show_bug.cgi?id=39023
David dbpoole7@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dbpoole7@gmail.com
--- Comment #43 from David dbpoole7@gmail.com --- Could someone explain to me in plain terms how to apply Alex Vallee's patch for the PS4 controller? I am using Portingkit Wine to play FFXI on my Macbook Pro 15" mid 2015 Intel Iris Pro. I do not know how or where to put in the patch he supplied in comment 37. Thank you to anyone that takes the time to help me with this.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #44 from David dbpoole7@gmail.com --- Could someone explain to me in plain terms how to apply Alex Vallee's patch for the PS4 controller? I am using Portingkit Wine to play FFXI on my Macbook Pro 15" mid 2015 Intel Iris Pro. I do not know how or where to put in the patch he supplied in comment 37. Thank you to anyone that takes the time to help me with this.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #45 from Naan wine@sharpner.de --- (In reply to David from comment #44)
Could someone explain to me in plain terms how to apply Alex Vallee's patch for the PS4 controller? I am using Portingkit Wine to play FFXI on my Macbook Pro 15" mid 2015 Intel Iris Pro. I do not know how or where to put in the patch he supplied in comment 37. Thank you to anyone that takes the time to help me with this.
I used homebrew to apply the patch. Basically: brew update brew edit wine
and add the patch to the stable section: patch do url "https://bugs.winehq.org/attachment.cgi?id=58590&action=diff&context=..." sha256 "1807717af49cf5a99ef18332b0a116e0f1590f4a0490165c48fa4698887c6882" end
and then brew install wine
hope it helps :)
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #46 from David dbpoole7@gmail.com --- Created attachment 62135 --> https://bugs.winehq.org/attachment.cgi?id=62135 FFXI PS4 Controller Backtrace
Hi Naan and thank you for your response. Since I used Portingkit, which completely automated the FFXI install process including wine, which it installed at the same time as FFXI, on my Mac found at https://www.paulthetall.com , do I need to uninstall my game and not use portingkit? Do I need to initiate a fresh install using only homebrew or can I install homebrew over the top and along with my current install of FFXI using Portingkit? I apologize as I am somewhat ignorant of these process and am learning what to do as it is all new to me.
I saved my backtrace of the event and the log when the crash occurred. I also sent you an email if this is not the place to be asking these questions. Thanks again for your time. It is greatly appreciated.
David
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #47 from Naan wine@sharpner.de --- No need to be sorry. :)
To be honest I have no clue about "portingkit". But one requirement of patching wine is to install from source. I would guess that portingkit uses a binary (non-source) distribution of wine, and therefore patching would not work.
If you have enough disk space, I think you can try installing it both ways.
In generell homebrew is a great way to manage packages and software on your mac, so you should try it anyways :P
https://bugs.winehq.org/show_bug.cgi?id=39023
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #48 from Zebediah Figura z.figura12@gmail.com --- More importantly your Wine version (1.9) is years out of date, and I suspect this particular issue may have been helped by 221708d64ebf7b9c6bed3674e9363779a3ed1a4d.
https://bugs.winehq.org/show_bug.cgi?id=39023
--- Comment #49 from David dbpoole7@gmail.com --- (In reply to Zebediah Figura from comment #48)
More importantly your Wine version (1.9) is years out of date, and I suspect this particular issue may have been helped by 221708d64ebf7b9c6bed3674e9363779a3ed1a4d.
I just wanted to update you all and took some time to be sure, but once I was able to get a strong and secure internet connection, I was able to go into the advanced settings in the Portingkit under FFXI and change the game's wine engine to a more recent build, specifically Wine 3.0+. I settled on wine 3.5 as the engine for the game and this has completely eliminated the bugs with the wired PS3 and PS4 controllers. I have played for days without a single crash. I hope this helps anyone struggling with the same issues I had.
Thank you all for the support in getting to this point.
https://bugs.winehq.org/show_bug.cgi?id=39023
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED
--- Comment #50 from Zebediah Figura z.figura12@gmail.com --- (In reply to David from comment #49)
(In reply to Zebediah Figura from comment #48)
More importantly your Wine version (1.9) is years out of date, and I suspect this particular issue may have been helped by 221708d64ebf7b9c6bed3674e9363779a3ed1a4d.
I just wanted to update you all and took some time to be sure, but once I was able to get a strong and secure internet connection, I was able to go into the advanced settings in the Portingkit under FFXI and change the game's wine engine to a more recent build, specifically Wine 3.0+. I settled on wine 3.5 as the engine for the game and this has completely eliminated the bugs with the wired PS3 and PS4 controllers. I have played for days without a single crash. I hope this helps anyone struggling with the same issues I had.
Thank you all for the support in getting to this point.
Resolving fixed then.
https://bugs.winehq.org/show_bug.cgi?id=39023
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #51 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.21.
-
wine-bugs＠winehq.org