search

ValveSoftware / Proton

Compatibility tool for Steam Play based on Wine and additional components
Other
24.13k stars 1.05k forks source link

Mount & Blade II: Bannerlord (261550) #3706

Open Yarwin opened 4 years ago

Yarwin commented 4 years ago

Compatibility Report

System Information

I confirm:

Proton crash log:

steam-261550.log

Symptoms

Game don't launch

Reproduction

  1. Download M&B II: Bannerlord
  2. Try to run it
  3. Game crashes with: 
    Unhandled Exception:
System.IO.FileNotFoundException: Could not load file or assembly 'ManagedStarter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
File name: 'ManagedStarter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'

    message in the log.

Current workaround

Proton 5.5-GE https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/5.5-GE-1 + protontricks 261550 dotnet472 (Bannerlord necessary dependencies can be found there: https://forums.taleworlds.com/index.php?threads/installing-missing-necessary-dependencies.407126/) Installing dotnet core might significantly reduce number of crashes: https://github.com/ValveSoftware/Proton/issues/3706#issuecomment-609959973, https://github.com/ValveSoftware/Proton/issues/3706#issuecomment-610022040

Multiplayer: it works, just skip installation of a BattleEye when prompted.

E3FxGaming commented 4 years ago

Few notes:

You can rename two .exe files in /Mount & Blade II Bannerlord/bin/Win64_Shipping_Client/

to at least make the game start, see the splash screens and then I get to the point I have to interact with the game for the first time (change brightness settings) at which point my CPU and GPU go absolute haywire and I can't interact with the game at all.

YellowApple commented 4 years ago

I'm able to confirm that bypassing the launcher (by moving TaleWorlds.MountAndBlade.Launcher.exe out of the way and replacing it with a copy of Bannerlord.exe) does get it to at least the brightness calibration screen (or as far as the main menu if I set brightness_calibrated = 1 in $COMPATDATA/261550/pfx/drive_c/users/steamuser/My Documents/Mount and Blade II Bannerlord/Configs/engine_config.txt).

However, it looks like there's a bug with mouse input; the cursor moves and is visible, but menu options don't highlight when moving over them and the game doesn't respond to clicks (and naturally there's no keyboard navigation...). Problem persists with every permutation of V-sync, launching in a virtual desktop, disabling the Steam Overlay, etc.

Of particular interest in steam-261550.log is the spamming of fixme:win:GetMouseMovePointsEx (24 0x3c87f298 0x3c87f2b0 64 1) stub. Possibly related to Wine bug 36873?

Further discussion on TaleWorlds' forum: https://forums.taleworlds.com/index.php?threads/linux.385761/page-2 and https://forums.taleworlds.com/index.php?threads/b0-8-9-mouse-clicks-not-registered-on-linux.395650/

EDIT: tried plugging in a controller, and that allowed me to actually navigate through the menu. Gonna see how far I can get, but... progress!

Yarwin commented 4 years ago

For me game was still crashing on launch after running Bannerlord.exe instead of TaleWorlds.MountAndBlade.Launcher.exe. Using protontricks I've installed dotnet4.8 and vcrun2015 – the game still crashes but at least I'm able to admire the game loading screen.

tkamat commented 4 years ago

Can confirm that I'm having the same problem with mouse inputs, on Manjaro with Proton 5.0-5. I was in the closed beta and the game was working fine before the very last update, so I am pretty confident that the rest of the game should be working once we manage to fix this navigation issue.

YellowApple commented 4 years ago

So after fumbling around getting a character created entirely via a Logitech gamepad, it looks like I've hit another roadblock in the form of a hard crash at the loading screen right after character creation (relevant entry from steam-261550.log: wine: Call from 0x7b00fc3e to unimplemented function api-ms-win-crt-private-l1-1 -0.dll._o___stdio_common_vswprintf, aborting). This persists even after running protontricks 261550 vcrun2015 and protontricks 261550 vcrun2017.

nilleairbar commented 4 years ago

Just a quick google as I can't actually test it right now myself (still downloading) but a similar issue seemingly plagued the BNet Launcher at some point and was fixed by adding ucrtbase and the api-msi-win etc etc dll as overrides via winecfg.

catmagi commented 4 years ago

Custom battles do work when you navigate to them using the gamepad, and when in the actual game you're able to use the mouse to fight.

However the game for me looked incredibly washed out and bright while playing and changing settings crashes the game half the time, along with setting everything to low crashes the game. Here's a log for the crash when saving settings. steam-261550.log

Edit: changing settings down from high caused customs to stop working, so avoid doing that.

ghost commented 4 years ago

Right, I did some reading, research, downloaded the game three times down, and some more research, and I believe I´ve figured it out.

Bannerlord is using Battleye, which is a Kernel Anti-Cheat software. Since Proton-Wine instance isn´t the base Linux Kernel, but the Windows Kernel, Battleye is unable to intercept the mouse input straight from the usb-port to verify that its the real deal, and then let it into the game, or is mistaking Wine´s mouse-input as an artificial program-based mouse input, which means the Anti-Cheat system kicks in.

I do recall reading somewhere that Battleye does not play nice with Linux at all, but that comment was from... 3 years ago? So I don´t actually know the current state of the anti-cheat software. So the options are, I think, to ask TaleWorlds to configure Battleye to play nice with Proton, disable it for Proton until a proper Linux version can be made, then re-enable it there, (they are using Mono for something. Looked like the launcher?) Wait until the game is properly released because chances are that they will mooost likely hold off on doing multiple OS support until later in Early Access so it´s 10 times easier to dish out updates... Or figure out how to let a Window Executable Battleye go straight into the Linux-based Kernel so it can scan everything it wants and let us do inputs into the game without trigger the anti-cheat...

So I guess we´re waiting a bit longer for Bannerlord.

0xh007 commented 4 years ago

Right, I did some reading, research, downloaded the game three times down, and some more research, and I believe I´ve figured it out.

Bannerlord is using Battleye, which is a Kernel Anti-Cheat software. Since Proton-Wine instance isn´t the base Linux Kernel, but the Windows Kernel, Battleye is unable to intercept the mouse input straight from the usb-port to verify that its the real deal, and then let it into the game, or is mistaking Wine´s mouse-input as an artificial program-based mouse input, which means the Anti-Cheat system kicks in.

I do recall reading somewhere that Battleye does not play nice with Linux at all, but that comment was from... 3 years ago? So I don´t actually know the current state of the anti-cheat software. So the options are, I think, to ask TaleWorlds to configure Battleye to play nice with Proton, disable it for Proton until a proper Linux version can be made, then re-enable it there, (they are using Mono for something. Looked like the launcher?) Wait until the game is properly released because chances are that they will mooost likely hold off on doing multiple OS support until later in Early Access so it´s 10 times easier to dish out updates... Or figure out how to let a Window Executable Battleye go straight into the Linux-based Kernel so it can scan everything it wants and let us do inputs into the game without trigger the anti-cheat...

So I guess we´re waiting a bit longer for Bannerlord.

I'm not buying this. If Battleye is causing the cursor issues then why wouldn't we see the same issue when using a gamepad?

tkamat commented 4 years ago

Battleye is not the issue, it is an optional install and only required for multiplayer.

hjones2199 commented 4 years ago

Battleye is not the issue, it is an optional install and only required for multiplayer.

To expand on tkamat's post, I was also in the closed beta and the game still worked for a few patches after Battleeye was patched into the beta. From what I understand they made it optional at the time, you could just ignore cancel the battle eye install on first run and it wouldnt kick you from games for not using it.

About two weeks ago there was a patch that broke a bunch of windows users ability to play as well, it apparently had something to do with having a controller or joystick plugged in while trying to play with keyboard/mouse. They hotfixed the issue a couple of days later but all the Linux users on the forum reported the no mouse input happening whether or not a controller was plugged in even after the update.

We were speculating on the forum that it might be an issue with steamplay presenting a virtual controller to the game at a driver level, but never confirmed this. As for the crash on starting a campaign we never got that far since it was a multiplayer beta.

0xh007 commented 4 years ago

Battleye is not the issue, it is an optional install and only required for multiplayer.

To expand on tkamat's post, I was also in the closed beta and the game still worked for a few patches after Battleeye was patched into the beta. From what I understand they made it optional at the time, you could just ignore cancel the battle eye install on first run and it wouldnt kick you from games for not using it.

About two weeks ago there was a patch that broke a bunch of windows users ability to play as well, it apparently had something to do with having a controller or joystick plugged in while trying to play with keyboard/mouse. They hotfixed the issue a couple of days later but all the Linux users on the forum reported the no mouse input happening whether or not a controller was plugged in even after the update.

We were speculating on the forum that it might be an issue with steamplay presenting a virtual controller to the game at a driver level, but never confirmed this. As for the crash on starting a campaign we never got that far since it was a multiplayer beta.

Did the game run well on Linux before battleye? I was on Windows back during the beta so never got to try it through proton.

hjones2199 commented 4 years ago

Battleye is not the issue, it is an optional install and only required for multiplayer.

To expand on tkamat's post, I was also in the closed beta and the game still worked for a few patches after Battleeye was patched into the beta. From what I understand they made it optional at the time, you could just ignore cancel the battle eye install on first run and it wouldnt kick you from games for not using it. About two weeks ago there was a patch that broke a bunch of windows users ability to play as well, it apparently had something to do with having a controller or joystick plugged in while trying to play with keyboard/mouse. They hotfixed the issue a couple of days later but all the Linux users on the forum reported the no mouse input happening whether or not a controller was plugged in even after the update. We were speculating on the forum that it might be an issue with steamplay presenting a virtual controller to the game at a driver level, but never confirmed this. As for the crash on starting a campaign we never got that far since it was a multiplayer beta.

Did the game run well on Linux before battleye? I was on Windows back during the beta so never got to try it through proton.

It started working on Linux around December, crashed every once in a while but performance was acceptable after it finished compiling shaders for each map. I was also on a relatively underpowered graphics card (rx 480) at the time so I think performance-wise the game will be ok on Linux if we can get a small assist from taleworlds on fixing these issues. We did get a dev response about the mouse issue we were facing so it seems they are at the very least not hostile to considering Linux users & proton.

Aliervo commented 4 years ago

What a day to not be able to find my controller! I did actually get something working though! I followed the renames as above and then attempted to hook up my switch Joy-Cons using this handy driver.

When the joy-cons are recognized as a pro controller, I am able to click on things with the mouse after using the left stick to position the cursor. Mouse aim and clicking works fine in my quick test battles, so the problem may be menu related. Not sure if this will work with other controllers, or if it has something to do with the way that driver is implemented.

YellowApple commented 4 years ago

Just a quick google as I can't actually test it right now myself (still downloading) but a similar issue seemingly plagued the BNet Launcher at some point and was fixed by adding ucrtbase and the api-msi-win etc etc dll as overrides via winecfg.

Adding those as overrides still resulted in a crash, but I was able to brute-force it by following the steps from a similar issue re: Age of Empires 2: Definitive Edition:

cd /home/$USER/.steam/steam/steamapps/compatdata/261550/pfx/drive_c/windows/system32/
wget "https://aka.ms/vs/16/release/vc_redist.x64.exe"
cabextract vc_redist.x64.exe
cabextract a10

Which got me a lot further:

Tutorial works

Mouse continues to be unusable for dialogs and the pause menu (you can "Click to continue" there, so it obviously recognizes the mouse clicks, but doesn't know whether or not the mouse is actually over something unless you're moving the cursor with the controller). Works fine for movement and combat. Got through a couple of the tutorial objectives before I crashed again (this time because of an eventfd: Too many open files; gonna reboot with a pumped up ulimit -Hn and try again).

EDIT re: BattlEye:

Bannerlord is using Battleye, which is a Kernel Anti-Cheat software. Since Proton-Wine instance isn´t the base Linux Kernel, but the Windows Kernel, Battleye is unable to intercept the mouse input straight from the usb-port to verify that its the real deal, and then let it into the game, or is mistaking Wine´s mouse-input as an artificial program-based mouse input, which means the Anti-Cheat system kicks in.

This seems unlikely. If it was anti-cheat-related, I'd expect the opposite of current symptoms (i.e. mouse working fine in menus/dialogs, but not for movement/combat). I would also expect keyboards and controllers to be similarly affected (which doesn't appear to be the case).

BattlEye's certainly going to put a damper on things for multiplayer, but it should be entirely unnecessary for singleplayer (and indeed, other BattlEye games with singleplayer modes work reasonably well under Proton, e.g. Conan: Exiles).

qsniyg commented 4 years ago

@YellowApple Could you see if the following patch fixes the crash without vcredist? (i.e. set ucrtbase and api-ms-win-crt-private-l1-1-0 to builtin when testing)

https://gist.github.com/qsniyg/4ba247c7398e3a1926988e3f6ca252ce

Would be cool if it could be fixed upstream without needing overrides :) I don't have the game at the moment, so I can't test.

tkamat commented 4 years ago

@YellowApple I have tried reproducing your solution, but it is sadly not working for me, and campaign is crashing after character creation. Log files still seem to point to api-ms-win-crt-private-l1-1-0.dll._o___stdio_common_vswprintf as the issue. Did you do any other steps, like reinstalling vcrun-2017 or something else?

YellowApple commented 4 years ago

So bumping up my ulimit -Hn helped, and I was able to get as far as the main map, but noticed that any attempt to save the game will cause the game to temporarily freeze for a few minutes while pegging every core/thread on my CPU (certain sounds do continue to play in the background, though). I suspect there's an autosave function that's triggering similar freezes, too (happened after cheating in some inventory, and happened again when idling for awhile).

Also, it seems pop-up dialogs will cause the joystick-driven mouse cursor to disappear (haven't determined whether or not that always happens; with enough wiggling I did manage to get the "OK" button to briefly highlight, so I think the cursor's just invisible).

I can also confirm that the mouse buttons and scroll wheel fully work in the menus/dialogs; you just gotta use the controller to move the cursor to the thing you want to click or scroll. So whatever's causing that bug has purely to do with where the game thinks the mouse is pointing.

@YellowApple Could you see if the following patch fixes the crash without vcredist? (i.e. set ucrtbase and api-ms-win-crt-private-l1-1-0 to builtin when testing)

Will do @qsniyg (as soon as I get Vagrant to cooperate). Are these functions all implemented but stubbed out or something?

@YellowApple I have tried reproducing your solution, but it is sadly not working for me, and campaign is crashing after character creation. Log files still seem to point to api-ms-win-crt-private-l1-1-0.dll._o___stdio_common_vswprintf as the issue. Did you do any other steps, like reinstalling vcrun-2017 or something else?

@tkamat: Exact steps I did (to the best of my recollection):

Yarwin commented 4 years ago

@YellowApple maybe it is a blind shot – but can you try installing dotnet 4.8 via protontricks as well? I was able to use mouse in the splash/loading screen.

qsniyg commented 4 years ago

@YellowApple

Will do @qsniyg (as soon as I get Vagrant to cooperate). Are these functions all implemented but stubbed out or something?

They're implemented, but windows uses these api-ms-win-... dlls which basically just import from other dlls (advapi32, kernel32, ucrtbase, etc.). I guess wine adds in the functions to those dlls in an as-needed basis in order to make sure they're correct.

It's possible the game will crash again on some other unimplemented function from one of those api dlls. Feel free to either add them in yourself or let me know. Hopefully after a bit of iteration, we'll be able to find which functions are needed, then send it in upstream to wine :)

ChemiKyle commented 4 years ago

@Yarwin @tkamat I have a hunch the protontricks installation of dotnet4.8 may be causing your issue (though it did seem to let me use the intended launcher, mouse had to be controlled via controller in the actual game). I installed that as well and could not get @YellowApple's solution to work.
I ended up deleting $COMPATDATA/2615501 altogether and went through the process of verifying files for both Proton 5.0 and Bannerlord. After that, the cabextract method worked (don't forget you'll have to edit $COMPATDATA/261550/pfx/drive_c/users/steamuser/My Documents/Mount and Blade II Bannerlord/Configs/engine_config.txt again to set brightness_calibrated = 1). This may solve your problem whatever the cause.

+1 for the hang being caused by saving. I also was able to finish the tutorial until a hang caused me to close it, now a new folder has appeared at $COMPATDATA/261550/pfx/drive_c/users/steamuser/My Documents/Mount and Blade II Bannerlord/Game Saves.

YellowApple commented 4 years ago

@YellowApple maybe it is a blind shot – but can you try installing dotnet 4.8 via protontricks as well? I was able to use mouse in the splash/loading screen.

Doesn't seem to have had any effect for me.

+1 for the hang being caused by saving. I also was able to finish the tutorial until a hang caused me to close it, now a new folder has appeared at $COMPATDATA/261550/pfx/drive_c/users/steamuser/My Documents/Mount and Blade II Bannerlord/Game Saves.

Yeah, I encountered that post-tutorial hang, too. Kinda kicking myself for not just waiting it out and seeing if it would've unborked itself eventually like these other save-hangs seem to do.

tkamat commented 4 years ago

@ChemiKyle thanks for the tip, I just finished the tutorial but now I am stuck at the notification screen since my mouse cursor vanished. Spent a couple minutes fiddling with the joystick to see if its invisible, but its not working lol. I feel like the mouse issue shouldn't be too hard to fix in general considering controller input has been working fine. My steam logs have a warning about GetMouseMovePointsEx spammed a bunch of times, but as far as I can tell that function is already implemented in wine.

qsniyg commented 4 years ago

@YellowApple @tkamat I've created a hacky patch for GetMouseMovePointsEx, I haven't tested it so it could be wrong, but would you mind giving it a shot?

https://gist.github.com/qsniyg/4ba247c7398e3a1926988e3f6ca252ce#file-getmousemovepointsex-patch

It's written against wine-staging, so you may need to manually apply it.

YellowApple commented 4 years ago

@qsniyg Just tried a fresh prefix with both of your patches; no dice with either. Mouse input is still busted, and still crashes due to that same unimplemented function. Logs from the patched run.

EDIT: ah, looks like the patch was for vfwprintf whereas the crash is due to vswprintf. Lemme see if I can fix that up...

qsniyg commented 4 years ago

@YellowApple Darn, well it was at least worth a shot :) I'm quite blind as to what the issue might be, I don't own the game yet so I cannot test either. That being said, a +rawinput,+win,+cursor,+dinput,+xinput log would probably give a lot of insight into the issue (although you may need to .gz compress the log... :)

Anyways, here's the vswprintf patch: https://gist.github.com/qsniyg/4ba247c7398e3a1926988e3f6ca252ce#file-vswprintf-patch

YellowApple commented 4 years ago

Hot damn, that did the trick (though I patched it as _o___stdio_common_vswprintf(int64 wstr long wstr ptr ptr), since I was trying to match Microsoft's docs as close as possible; I guess a pointer's a pointer, but who knows with Wine, lol).

I'll try to get some logs with those flags so that we can hopefully get some headway on this mouse issue.

qsniyg commented 4 years ago

Good to know! Sent them in :)

https://source.winehq.org/patches/data/182375 https://source.winehq.org/patches/data/182376

I don't know why wine did it that way either, I just copied how they declared vswprintf from an earlier declaration in the file :)

tomhobson commented 4 years ago

Hi, I've added the app to the wine AppDB: https://appdb.winehq.org/objectManager.php?sClass=version&iId=38834&iTestingId=107964

@qsniyg Do you want to link the bugs to the application or should I?

qsniyg commented 4 years ago

@tomhobson Go right ahead! (I'm not in any way part of the wine development team, I just write patches and embarrass myself on the mailing list due to always getting something wrong haha)

tomhobson commented 4 years ago

@tomhobson Go right ahead! (I'm not in any way part of the wine development team, I just write patches and embarrass myself on the mailing list due to always getting something wrong haha)

If you write patches, sounds like you're part of the wine development team :)

Ok I've linked bug: https://bugs.winehq.org/show_bug.cgi?id=36873

I'm not sure how/if you link the patches back to the bug. But when they get merged we can tackle the next.

Is there any bugs I've missed?

allquixotic commented 4 years ago

So the "state of the art" with all the patches here is still essentially requiring a gamepad of some kind to control the menus. Is that right? Just checking that the mouse issue has never been overcome even experimentally.

ElCaconym commented 4 years ago

@allquixotic: that is correct.

rcizeron commented 4 years ago

Hi guys! I'm not playing on Linux nor Wine, but I had a similar issue: gamepad was ok for mouse cursor but not real mouse.

I play on Shadow (distant computer) and when I set "capture cursor" on, the issue was just gone. I don't know how Wine works exactly, but maybe if this option is availaible too, you can try it.

Cheers

tomhobson commented 4 years ago

Hi guys! I'm not playing on Linux nor Wine, but I had a similar issue: gamepad was ok for mouse cursor but not real mouse.

I play on Shadow (distant computer) and when I set "capture cursor" on, the issue was just gone. I don't know how Wine works exactly, but maybe if this option is availaible too, you can try it.

Cheers

Thanks for the info. Is this capture cursor setting within bannerlord?

nilleairbar commented 4 years ago

Thanks for the info. Is this capture cursor setting within bannerlord?

I believe he means in the streaming solution. Might be worth a try to test if allowing Wine to take exclusive control of the mouse might work.

ElCaconym commented 4 years ago

The only settings related to the mouse in engine_config.txt appear to be the following:

invert_mouse = 0
mouse_sensitivity_coefficient = 0.5000
control_mouse_movement_y_scale = 1.5000
control_mouse_movement_max_accumulation = 40.0000
control_mouse_movement_accumulation_decay_speed = 100.0000

Unsurprisingly, modifying them does not appear to help with the issue.

rcizeron commented 4 years ago

Thanks for the info. Is this capture cursor setting within bannerlord?

I believe he means in the streaming solution. Might be worth a try to test if allowing Wine to take exclusive control of the mouse might work.

yep i meant exactly that.

@ElCaconym sorry if it doesn't help :(

tomhobson commented 4 years ago

If someone is available to test (I'm still working)

I've found something that could be useful here: https://askubuntu.com/questions/968252/ubuntu-17-10-mouse-problem-in-wine

nilleairbar commented 4 years ago

If someone is available to test (I'm still working) I've found something that could be useful here: https://askubuntu.com/questions/968252/ubuntu-17-10-mouse-problem-in-wine

That was pretty much the idea I just got. Enabling this option could potentially help, Automatically capture the mouse in full-screen windows as I remember other games having at least comparable issues with mouse cursors in Wine.

ElCaconym commented 4 years ago

@tomhobson: already tried that; no luck.

The "fixme:win:GetMouseMovePointsEx" messages simply denote the stub in wine for this function; I doubt they're even related to the clicks-not-registering issue; and indeed a Taleswords dev said here:

We started using GetMouseMovePointsEx for some mouse movement inputs. Maybe that's not implemented in WINE? It's not used for mouse clicks though.

Running with +rawinput,+win,+cursor,+dinput,+xinput doesn't appear to produce any enlightening logs, at least at first glance; notably, upon clicking, you get the usual:

0014:trace:cursor:X11DRV_RawButtonEvent raw button 0 (raw: 1) up
0014:trace:cursor:X11DRV_RawButtonEvent raw button 0 (raw: 1) down

(depending on whether you use the left or right click)

qsniyg commented 4 years ago

@ElCaconym Could you share the log? The full log might contain more information that might help to debug the issue :)

ElCaconym commented 4 years ago

Of course; attached. WINEDEBUG: +err,+fixme,+rawinput,+win,+cursor,+dinput,+xinput.

I'm not using proton, mind you: it's wine-staging 5.4 with all staging patches, no custom patches (not even the one referenced above - I wanted to fix the mouse issue before applying the vfwprintf/vswprintf patch), and dxvk 1.6. Winetricks: vcrun2010, vcrun2015, and dotnet48 (only the last one may be necessary).

I launched the game, and in order not to pollute the logs I avoided moving the mouse until I got to the gamma selection screen. I then moved the cursor over the "Accept" button, and left-clicked. Then, I killed the game from another term.

The file:

stderr_bannerlord.log.gz

tomhobson commented 4 years ago

@ElCaconym Maybe they're checking the mouse is on the screen.

This function is being used on the menu. I'd be surprised if this wasn't related to the menu issue.

Are you running multi monitor or single?

ElCaconym commented 4 years ago

Single monitor.

qsniyg commented 4 years ago

@ElCaconym Huh interesting, it's also clipping the cursor every frame, like in AoT2. I wonder if this patch would help? https://source.winehq.org/patches/data/181257 It was meant to fix an issue with the mouse cursor's movement being improperly registered, not clicks, so it may be useless in this case, but who knows, it shouldn't hurt though :)

The second click creates a fullscreen clip window:

``` 0014:trace:cursor:X11DRV_RawButtonEvent raw button 0 (raw: 1) down 0014:trace:cursor:X11DRV_EnterNotify hwnd 0x10020/7000008 pos 1116,1057 detail 1 004b:trace:cursor:X11DRV_EnterNotify hwnd 0x30052/a600001 pos 1116,1057 detail 1 004b:trace:cursor:X11DRV_ButtonPress hwnd 0x30052/a600001 button 0 pos 1116,1057 004b:trace:cursor:clip_fullscreen_window win 0x30052 clipping fullscreen 004b:trace:win:WIN_CreateWindowEx (null) L"Message" ex=00000000 style=00000000 0,0 0x0 parent=0xfffffffffffffffd menu=(nil) inst=0x140000000 params=(nil) 004b:trace:win:dump_window_styles style: 004b:trace:win:dump_window_styles exstyle: 004b:trace:win:GetWindowRect hwnd 0x20094 (0,0)-(0,0) 004b:trace:win:GetWindowRect hwnd 0x20094 (0,0)-(0,0) 004b:trace:win:WINPOS_GetMinMaxInfo 106 106 / -3 -3 / 1932 1092 / 112 27 004b:trace:win:GetWindowRect hwnd 0x20094 (0,0)-(112,27) 004b:trace:win:invalidate_dce 0x20094 parent 0x10026 (0,0)-(112,27) ((0,0)-(0,0)) 004b:trace:win:invalidate_dce 0x70058: hwnd 0x30052 dcx 00000012 Cache 004b:trace:win:invalidate_dce 0x1005a: hwnd 0x30052 dcx 00000013 Cache 004b:trace:win:invalidate_dce 0x12004c: hwnd 0x10020 dcx 00000013 Cache 004b:trace:win:invalidate_dce 0x33004a: hwnd 0x10020 dcx 00000013 Cache InUse 004b:trace:win:invalidate_dce 0x40041: hwnd 0x10020 dcx 00000013 Cache InUse 004b:trace:win:set_window_pos win 0x20094 surface (nil) -> (nil) 004b:trace:win:WIN_CreateWindowEx hwnd 0x20094 cs 0,0 0x0 (0,0)-(112,27) 004b:trace:win:GetWindowRect hwnd 0x20094 (0,0)-(112,27) 004b:trace:win:invalidate_dce 0x20094 parent 0x10026 (0,0)-(112,27) ((0,0)-(112,27)) 004b:trace:win:invalidate_dce 0x70058: hwnd 0x30052 dcx 00000012 Cache 004b:trace:win:invalidate_dce 0x1005a: hwnd 0x30052 dcx 00000013 Cache 004b:trace:win:invalidate_dce 0x12004c: hwnd 0x10020 dcx 00000013 Cache 004b:trace:win:invalidate_dce 0x33004a: hwnd 0x10020 dcx 00000013 Cache InUse 004b:trace:win:invalidate_dce 0x40041: hwnd 0x10020 dcx 00000013 Cache InUse 004b:trace:win:set_window_pos win 0x20094 surface (nil) -> (nil) 004b:trace:win:WIN_CreateWindowEx created window 0x20094 004b:trace:cursor:X11DRV_XInput2_Enable XInput2 v2.1 available 004b:trace:cursor:grab_clipping_window clipping to (0,0)-(1920,1080) win 7000001 0014:trace:cursor:clip_cursor_notify clip hwnd changed from (nil) to 0x20094 004b:trace:cursor:X11DRV_EnterNotify hwnd 0x30052/a600001 pos 1116,1057 detail 2 004b:trace:cursor:X11DRV_EnterNotify pos 1116,1057 old serial 24052, ignoring 004b:trace:win:WINPOS_WindowFromPoint scope 0x10020 (1116,1057) returning 0x30052 004b:trace:cursor:SetCursor 0x20070 004b:trace:win:WINPOS_WindowFromPoint scope 0x10020 (1116,1057) returning 0x30052 004b:trace:win:GetWindowRect hwnd 0x30052 (0,0)-(1920,1080) 004b:trace:cursor:ClipCursor Clipping to (null) ```

ElCaconym commented 4 years ago

With that patch, the mouse clicks are still being ignored. And I still get the following sequence regularly, as well:

004b:trace:cursor:ClipCursor Clipping to (null)
004b:trace:cursor:ungrab_clipping_window no longer clipping

... which kinda made me doubt at first the patch was applied properly, so I recompiled wine fully from scratch (instead of using my previous compilation dir), and used another prefix (autotools install prefix I mean, not a wineprefix) just in case as well. The logs in question persist - though that may be expected ?

qsniyg commented 4 years ago

Ah okay, makes sense. It was a bit of a longshot haha.

Just in case, could you try with wine by itself, instead of wine-staging? Wine-staging has a rawinput patch that prevents clicking on games like Mass Effect: Andromeda. Alternatively you could just recompile wine-staging without the rawinput patch.

I'm just pulling things out of a hat here though, this might very well not work either.

ElCaconym commented 4 years ago

Tried with wine without any staging patches: no changes. The logs change a bit of course; for example, I now get:

004c:trace:cursor:X11DRV_ButtonPress hwnd 0x3003a/a000001 button 2 pos 163,1067

... on mouse clicks instead of the previous X11DRV_RawButtonEvent lines, but beyond that, clicks are still ignored. This new test did not include your patch above, mind you (will try that now just in case).

I'm just pulling things out of a hat here though, this might very well not work either.

Of course - thanks for trying ! :-)

nilleairbar commented 4 years ago

Could be that that patch actually might have an effect, as I believe the problem to not lie with detection of input but rather a problem with where the cursor is displayed and where the game believes the cursor is located.