Hello, I read in comment of bug 38816 that xinput gamepad are now support in wine out-of-box for game that not support dinput.

I'm trying to get my gamepad working with brothers and wine 3.12, but game do not see it.

I get my gamepad work with "legend of kay" through koku-xinput, then I try it with brothers but I've get an error, I think due to conflict with .net framework.

I try both builtin and native xinput*.dll, nothing change.

I disable any gamepad in wine control for avoid conflict, only difference is that in launcher appears warning about no gamepad connect, but in every case game work with keyboard and there is no way to switch to gamepad.

It's can be related with bug 45084 that i have?

Hello. I've found that warn in terminal output:

004d:warn:plugplay:sdl_driver_init compiled without SDL support

Can it be the problem?

Yes you need Wine to be compiled with SDL2 support and the multilib SDL2 libraries to be installed on your system...
Otherwise the new controller stuff, Aric Stewart implemented, will not work.

• Where did you get your Wine package / build from?
• Do you have the SDL2 library packages (32-bit + 64-bit) installed on your system?

Bob

Hello.

I get my wine package from arch repo (pacman -S wine).

I'm looking for all wine package in AUR, no one mention sdl or sdl2.

I have this sdl and sdl2 packages installed:

extra/sdl 1.2.15-9 [installato]
extra/sdl2 2.0.8-9 [installato]
extra/sdl_image 1.2.12-4 [installato]
extra/sdl_mixer 1.2.12-5 [installato]
extra/smpeg 0.4.5-3 [installato]
multilib/lib32-sdl 1.2.15-7 [installato]
multilib/lib32-sdl2 2.0.8-9 [installato]

Thank-you.

Hello.

Waiting for bug 44722 is considering, how I can compile wine myself with sdl support?

I have not idea about making makefile or modify pkgbuild.

Bug 44722 - Wine 3.3 is compiled without sdl und udev, limiting gamepad support, is not relevant to you. This for the Linux distributions that WineHQ package for (which does not include Arch).



The current Arch wine-staging package should be built with sdl2 support.
See: wine-staging / PKGBUILD.
sdl2 support is enabled by default (Wine build-time default) and the Arch build-time (makedepends) sdl2 library dependencies are listed.

Note: the Arch wine package will not have sdl2 support.
You can simply rebuild the wine PKGBUILD (adding over the makedepend sdl2 lines from the wine-staging PKGBUILD).

Bob

Hello. Thank-you for trip. I've install current Arch wine-staging package (without recompiling), but... no game with gamepad support start anymore, and i get this error:



but that file is present on my pc:



can you give me more help?

@macchinetta

You probably need the package: lib32-sdl2 ; as well.

Bob

Thank you. In effect I missing lib32-sdl2, probably because it's not (optional) required from any package, and I've purge it as unuseful dependence.

Now error reported above is resolved, but... is slooooowwwwwww to start any game, seems freeze on splash screen and only after lots of minutes it start, I think some staging patch interfere with somethings...

In any case, gamepad seems not work, but with this slowness testing is very difficulty.

Tomorrow I'll should try to compile official wine following your tips for see differences.

@ macchinetta,

If you wish... You could post a log of your game, when using wine-staging-3.15.

Please run:

if you want to troubleshoot your game controller.

What kind of game controller are you using?
Looking at dlls/winebus.sys/bus_sdl.c I'm only really seeing support for Xbox controllers.
Perhaps SDL2 maps other 3rd party controllers inputs as a virtual Xbox controller - but I wouldn't rely on that...

People blame often incorrectly blame Wine (or Wine Staging) for their game startup issues...
This is very often due to a broken gstreamer setup, causing game intro-videos to crash Wine.
A collection of native Linux multlib (32-bit + 64-bit) gstreamer libraries are typically required to decode these media files.
Without a Wine terminal log - I can only guess why your game is crashing with the wine-staging package.

Bob

Hello. My game do not crash with wine-staging, they freeze or best "hang" for several seconds (over 1-2 minutes), then start normally, and it not terminate if I not terminate it manually.



I'm use a gamesir controller with both xinput and dinput support, but when it's connected in xinput mode lsusb said:

045e:028e Microsoft Corp. Xbox360 Controller

So I Think that wine should think it's a original xbox controller.


Attached log from "Brothers - Tale of two sons" (in tarball because txt and log extensions seems are not allowed in this forum).



Now I started compilation of wine-3.15 adding sdl makedepend lines from wine-staging pkgbuild.
I let you know about differences.

Sorry for double post. Time for edit is expired.

Compilation done. Now i can confirm gamepad do not work also with sdl support.

No more freeze at application start.

This is log with 3.15 compiled with sdl support:

@macchinetta

You probably want to disable:

It's a known problem with Wine Staging and Nvidia graphics cards...
Games will try to load the Physx library dll's and fail.

I presume you have setup a 32-bit WINEPREFIX, set to Windows XP compatibility, run this game, e.g.:

Looking at the games Steam page.
A Unity title I presume? Probably why it doesn't work...

Nothing is obvious in the log about your controller not working in game.
It's being recognised by Wine SDL2 shim.
It would be worth filing a bug for that - especially since your controller is mapped as a "fake" Xbox360 controller.

Bob

Yes. I've set 32bit wineprefix set to winxp. (note steam is interrupting winxp support)

There is already a bug about this problem, and in this bug user report that "brothers" work with gamepad:
https://bugs.winehq.org/show_bug.cgi?id=38816#c19

Also "koku" work for me with my gamepad and other games (legend of kay), but it's do not work with brother because crash, reading bug above seems interfere with .net framework.

Hello. Reading well this:

https://bugs.winehq.org/show_bug.cgi?id=44652

Seem need also UDEV support over SDL.

Looking in wine and wine-staging PKGBUILD, I do not see any mention about UDEV, but I think there is not a specific makedependence for UDEV because UDEV is part of SYSTEMD.

There is some way can I try to compile wine with UDEV support for test?

Thank-you.

No! Remember you don't have any udev errors or warnings in your Wine log!
From bug 44652:

You (supplied) log was clean of such warnings.

The end user in the bug report you linked to: Bug 38816 - Multiple games require XInput gamepad support (Brothers: A Tale of Two Sons, Broforce, Dead Space, Lego Star Wars Complete Saga).
See comment #24: 38816#c24.
So I'd suggest disabling koku, for the WINEPREFIX you have installed Brothers - Tale of two sons to.
Then re-test.
If necessary, retest, but with a clean WINEPREFIX.

Bob

Koku is not enabled for wineprefix, Is enable manually with LDPRELOAD environment variable.

In any case i try to unistall it totally, makes no difference.

I try to install driver xpadneo instead of steamos-xpad, makes no difference.

In clean wineprefix this game do not run because required some native features (as .net framework) that is not supported in a pure wineprefix.

Hello. Good news. Wine 3.16 (partially) solve problem, now gamepad is recognized from all game, both wine classic and wine staging without recompiling myself, just install from repo. (:?:)
Just need to use builtin xinput_x.dll (then NOT install it with winetricks xinput or correct through winecfg).

But whit wine classic button map is partially incorrect, i test it also with xinputtest.exe included in x360ce (in other directory than x360ce.ini for avoid conflict) and button map is effectively wrong for some button/axis.

I try to correct it with "export SDL_GAMECONTROLLERCONFIG=..." as worked as koku, but do not work in this case.

Instead with wine staging button map is correct and perfectly working, but wine staging is always sloooow to run games, also set nvapi.dll as disable. (nvapi64 is not present in 32bit prefixes).

Edit: wine-staging hang up problem solved. It's due to pulseaudio. I see some pulseaudio error in wine log, then I try to set alsa as driver and now games start fast.

Then now I can follow using wine-staging, and this thread can be marked as solved.

Thank you.

That's not a solution, it's a hacky workaround.
pulseaudio is the Wine default for Linux now, and should work OTTB.

Please post a terminal log from using wine-staging, using pulseaudio as the default backend:


Ta
Bob

Here the log.

Hello. I note the problem is not present in 64bit profile.

It seems related to 32bit, but lib32-libpulse is installed.

I made another log in wine 3.17 ensure that pulse is setting as driver, and adding +coreaudio,+sound,+dsound to WINEDBG.

Sorry for the delay in responding...

There is nothing leaping out at me from that log.
It's loading the pulseaudio driver OK...

The optional audio driver dependency packages for Arch, listed in the wine PKGBUILD, are:

• libpulse
• lib32-libpulse
• alsa-plugins
• lib32-alsa-plugins
• alsa-lib
• lib32-alsa-lib

That should be enough.

Bob

Hello. No problem for delay. Until wine work well with alsa not urgency for resolve pulseaudio issue.

Also I've ended game in topic object. As soon as find a right game, I try pure-clean wineprefix for exclude "dirty" cause.

Any case in 64bit prefix I've not a hang on start games, but I've encontered ingame lag suspect due to buffer underflow error found in log, and "resolved" that setting alsa as audio driver...

The Optional dependency who you list are all installed on my arch.