You are not logged in.

#1 2018-04-09 12:14:13

lightstream
Member
From: Britain
Registered: 2011-10-30
Posts: 64

Trying to track down a problem in Wine 3.5

Wine 3.5 was recently releasded to the repos, and (most) games that I've run using it fail to recognise my Xbox controller. The controller is still recognised in Wine's control panel. If I downgrade to Wine 3.4_2, the controller is again recognised in games.

I then compiled Wine 3.5 from WineHQ's git repo, and when I run games with this, the controller is correctly recognised.

This suggests to me that either a recent commit to Wine fixed the controller support, or there is some discrepancy between how the Arch Wine packages are compiled between version 3.4 and 3.5.

Currently I'm trying to rule out the latter option, and am having a little trouble understanding the PKGBUILD.

I would have thought that controller support requires SDL2, but it is not mentioned. Is it possible that Wine 3.5 could have been built on a system without SDL2, while Wine 3.4 was built on a system where it was already installed?

Offline

#2 2018-04-10 11:34:47

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: Trying to track down a problem in Wine 3.5

https://git.archlinux.org/svntogit/comm … e2111fc344

The only change between wine 3.4-2 and wine 3.5-1 is the version number and checksum.

Last edited by Lone_Wolf (2018-04-10 11:35:03)


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#3 2018-04-10 20:08:32

lightstream
Member
From: Britain
Registered: 2011-10-30
Posts: 64

Re: Trying to track down a problem in Wine 3.5

The problem is that I don't know how packages are built for the community repo.

Are they each built on a central server in a clean environment (e.g. inside a container), or are they built by the package maintainer on their own system?

If it's the latter, I can envisage a case where Wine 3.4 could have been built on a system with SDL2 installed, while Wine 3.5 was not (as SDL2 is not mentioned as a dependency in the PKGBUILD, build would continue without it but without certain features active, such as controller support).

Offline

#4 2018-04-11 08:57:50

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: Trying to track down a problem in Wine 3.5

Packages in core, extra , community and multilib are build in a clean chroot environment using a specific workflow

Wine normally relies on kernel and own code for drivers, I doubt sdl presence during build makes a difference.
But you can use asp to get the iwne PKGBUILD & necessary build files on your system and see if that does make a difference.


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#5 2018-04-11 22:56:40

loqs
Member
Registered: 2014-03-06
Posts: 17,195

Re: Trying to track down a problem in Wine 3.5

You can also extract the .BUILDINFO file from each package archive which lists all packages present during the build and compare ( sdl2 was not present during either build)

Offline

#6 2018-04-12 00:42:52

lightstream
Member
From: Britain
Registered: 2011-10-30
Posts: 64

Re: Trying to track down a problem in Wine 3.5

loqs wrote:

You can also extract the .BUILDINFO file from each package archive which lists all packages present during the build and compare ( sdl2 was not present during either build)

Interesting, thanks. This was an easy way to confirm that Wine 3.4_2 was built with the exact same packages present as 3.5 (although different versions).

I also discovered that wine-staging (3.4_1) is built with SDL2, amongst a host of additional packages.

I will keep experimenting and see if I can track down what's happening with the controller support. Thanks all.

Last edited by lightstream (2018-04-12 00:43:47)

Offline

Board footer

Powered by FluxBB