EQW / eqmules edition - crash without native dinput8

[rage_311]

Hi,

I'm having issues with the eqmule's EQMac client that uses EQW as the Everquest wrapper, and I'd like to see if anybody here has ideas on how to resolve it.

The issue that I'm having is that the game will crash as soon as I get to the character select screen, if I don't use the native dinput8 library. My log file for that is attached (with WINEDEBUG=+dinput).

If I do use the native dinput8 library, the game at least doesn't crash, but the mouse behavior is erratic. It seems to be an issue with the game expecting relative mouse positioning, but it's being provided absolute positioning ... or vice versa? The cursor starts out stuck to the top left corner of the window, until I move my mouse to some seemingly arbitrary position, then the cursor starts to move at about 10x the normal speed, and seems to be a step or two behind the direction that I'm actually moving my mouse in. If I use mouse look in game, the movement is also very fast and erratic. I've attached this log as well.

I had this working in Fedora 17 with WINE 1.5.29 at some point... but I've changed to Arch Linux, I have much newer versions of Xorg, and it's possible that the client has changed between then as well, so I'm not able to narrow down the exact difference that's causing it. I have since tried it on other hardware running: Ubuntu 12.04 and Linux Mint 17, but the behave the same as my main Arch machine.

I've tried many versions of WINE from 1.3.X up to 1.7.29. In ~1.5.15 and previous, I get an error of "Unable to open eqw.dll" before I even make it to the game client. Other than that, there are no real behavior differences.

I've also tried using the native version of dinput, but when the EQ client is loaded after hitting "OK" on the EQW window, I get an error "DirectInput keyboard open failed!, code = 1".

I've tried the MouseWarpOverride settings in forced, enabled, and disabled. I've tried with and without virtual desktops, allowing the window manager to decorate, allowing the window manager to control the windows, and automatically capturing the mouse in full screen -- technically "full screen" isn't possible because EQW intentionally runs EverQuest in a window for easy switching between multiple clients.

System info:
Arch Linux 64-bit kernel 3.17.1
Nvidia GTX 670 4GB with proprietary 343.22
Xorg 1.16.1

Thanks for any help on this! I've been at it for quite some time trying to figure it out.

[dimesio]

Problems caused by using native dlls are not Wine bugs, but the crash without it is.

When you had this working with Fedora, was that with or without native dinput8? When you say you've tested this in Ubuntu and Mint with the same results, were those tests all with the same versions of Wine (which ones?), and the same version of the app? And by "same results" do you mean the crash, or the problem caused by using native dinput8, or both?

There is no log attached to your post; it was probably too big. In general, you shouldn't post logs with debug channels set unless asked. Post ordinary terminal output (no debug channels) from a clean wineprefix (no native dlls) in the current development release.

[rage_311]

Problems caused by using native dlls are not Wine bugs, but the crash without it is.

I agree. I'm also open to suggestions for workarounds, whether that's using the native override or not.

When you had this working with Fedora, was that with or without native dinput8?

I believe it has only ever worked with the native dinput8.

When you say you've tested this in Ubuntu and Mint with the same results, were those tests all with the same versions of Wine (which ones?), and the same version of the app? And by "same results" do you mean the crash, or the problem caused by using native dinput8, or both?

I've tested them all with Wine versions 1.5.29 (since that's the version I had working previously) as well as 1.7.29. And yes, all with the exact same version of the application. By "same results", I mean that they all crash (lock up, rather) without native dinput8, and have the same erratic behavior with it.

There is no log attached to your post; it was probably too big. Post ordinary terminal output (no debug channels) from a clean wineprefix (no native dlls) in the current development release.

I tried to attach the log with the first post, but it wouldn't let me, and still won't due to txt/log extensions not being allowed. Here's the regular output from a 1.7.29 wineprefix without using native dlls where the game locks up at the end.

I've noticed that most of the time, the game doesn't lock up until I press a key on the keyboard. After that, nothing will respond (likely due to the thread-blocking errors at the bottom of the log). Even before pressing a key though, the cursor doesn't behave. There are no smooth motions, just a few big jumps occasionally when I move the mouse.

Code: Select all

fixme:win:EnumDisplayDevicesW ((null),0,0x33ecc8,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x33f408,0x00000000), stub!
fixme:d3d:wined3d_device_decref Device released with resources still bound, acceptable but unexpected.
fixme:d3d:wined3d_device_decref Leftover resource 0x175cf8 with type WINED3D_RTYPE_SURFACE (0x1).
fixme:d3d:wined3d_device_decref Leftover resource 0x175b98 with type WINED3D_RTYPE_TEXTURE (0x3).
fixme:win:EnumDisplayDevicesW ((null),0,0x33f488,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x33f4a8,0x00000000), stub!
fixme:ddraw:ddraw7_WaitForVerticalBlank iface 0x141d48, flags 0x1, event (nil) stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x33f588,0x00000000), stub!
err:ntdll:RtlpWaitForCriticalSection section 0x7c5c9c6c "../../../dlls/dinput/dinput_main.c: dinput_hook_crit" wait timed out in thread 0031, blocked by 002c, retrying (60 sec)
err:ntdll:RtlpWaitForCriticalSection section 0x12b61c "../../../dlls/dinput/keyboard.c: SysKeyboardImpl*->base.crit" wait timed out in thread 002c, blocked by 0031, retrying (60 sec)

[dimesio]

FYI, the forum will accept plain text logs without extensions (assuming they fall within the size limit).

File a bug for the hang without native dinput8.