Bug 249869

Summary: emulators/wine-devel: add SDL option (for gamepad/joystick input)
Product: Ports & Packages Reporter: Alex S <iwtcex>
Component: Individual Port(s)Assignee: Gerald Pfeifer <gerald>
Status: Closed FIXED    
Severity: Affects Some People CC: iwtcex
Priority: --- Flags: gerald: maintainer-feedback+
Version: Latest   
Hardware: Any   
OS: Any   
Description Flags
SDL option none

Description Alex S 2020-09-24 23:59:10 UTC
Created attachment 218270 [details]
SDL option

This should be self-explanatory.
Comment 1 Alex S 2020-09-25 00:17:40 UTC
Personally, I think it also makes sense to enable SDL and Vulkan by default. Those dependencies aren't particularly large and this should help FreeBSD gaming quite a bit. I won't insist on it, though.

Wine also supports evdev for controller input, which works fine on FreeBSD, but since upstream is slowly moving from it (to SDL, that is), evdev is likely better being left disabled. The only annoying part there is that Windows has two controller input APIs (DirectInput and XInput) and one of them (DirectInput) is only supported through evdev at the moment. Proton (game-focused Wine fork) has the required SDL+DirectInput code, but this is yet to be upstreamed.
Comment 2 Gerald Pfeifer freebsd_committer 2020-09-27 17:17:29 UTC
Thank you, I'm looking into this.

Note that the topic of SDL also came up in the context of bug#249018.
Comment 3 Gerald Pfeifer freebsd_committer 2020-10-04 12:43:12 UTC
I was going to take this.  Then I saw

                        SDL_CPUINFO SDL_EVENTS SDL_FILE SDL_HAPTIC      \
                        VIDEO_OPENGL VIDEO_OPENGLES2 VIDEO_WAYLAND      \

in devel/sdl20/Makefile and am still in a state of shock looking at all
the dependencies pulled in.

Am I off somehow, or is this about as heavy as it gets? :-(
Comment 4 Alex S 2020-10-04 12:51:28 UTC
(In reply to Gerald Pfeifer from comment #3)

Just an overly elaborate port Makefile:

 % pkg info -d sdl2
Comment 6 Gerald Pfeifer freebsd_committer 2020-10-05 11:50:39 UTC
Personally I consider Wayland heavy (and don't tend to use it on my Linux
notebook even), but let's give it a try - I'll add a minor variation of
your patch. SDL then is available as an option and we can take it from 

Two thoughts: The SDL_DESC is a bit technical, and is there really nothing
else Wine uses SDL for?  If you want to propose an update I'll be happy to
consider/take it.

And what do you think of adding a GAMING option or similar, as the very
first in that list, that enables all other options useful for that case?
Comment 7 commit-hook freebsd_committer 2020-10-05 11:52:17 UTC
A commit references this bug:

Author: gerald
Date: Mon Oct  5 11:51:44 UTC 2020
New revision: 551487
URL: https://svnweb.freebsd.org/changeset/ports/551487

  Add an option SDL that uses SDL 2, a cross-platform multimedia development
  API which can be useful particularly when it comes to supporting games.
  This is off by default for now in alignment with the status quo.

  Submitted by:	Alex S <iwtcex@gmail.com>
  PR:		249869

Comment 8 Gerald Pfeifer freebsd_committer 2020-10-05 12:01:58 UTC
I've applied the patch (just changing the order of SDL_USE and SDL_USES)
and am closing this PR accordingly.

My questions re SDL_DESC and adding a GAMING or similar option or still
relevant and I'll keep an eye on follow-ups. :)  Thanks!
Comment 9 Alex S 2020-10-05 12:55:02 UTC
(In reply to Gerald Pfeifer from comment #6)

> Personally I consider Wayland heavy

That ship has already sailed, everything graphical depends on Wayland. Typically transitively through mesa-libs: https://svnweb.freebsd.org/ports?view=revision&revision=484788. That is, our Wine port depends on it as well (libGLU -> mesa-libs -> wayland).

> Two thoughts: The SDL_DESC is a bit technical,
> and is there really nothing else Wine uses SDL for?

Not to my knowledge.

> And what do you think of adding a GAMING option or similar, as the very first in that list,
> that enables all other options useful for that case?

The truth of the matter, I'm aware of only a few people actually building Wine from source on amd64 FreeBSD specifically for gaming. It's jbeich@, (probably) scf@ and the guy receiving annoyed comments from me on the FreeBSD forums and Wine's bug tracker*. (I believe VVD is running Wine on i386 FreeBSD.) Pretty much everyone else waits for a binary package. Maybe we should make a flavor out of it?

I'm thinking of making a port for Valve's Wine fork (https://github.com/ValveSoftware/wine), however the same changes that enable it to work together with the Linux Steam client make impossible run the Windows Steam client under it. Which means it's not really an appropriate replacement for regular Wine.

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