Created attachment 218270 [details]
This should be self-explanatory.
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.
Thank you, I'm looking into this.
Note that the topic of SDL also came up in the context of bug#249018.
I was going to take this. Then I saw
OPTIONS_DEFAULT= ASM DLOPEN OSS PTHREADS SDL_ATOMIC SDL_AUDIO \
SDL_CPUINFO SDL_EVENTS SDL_FILE SDL_HAPTIC \
SDL_JOYSTICK SDL_LOADSO SDL_POWER SDL_RENDER \
SDL_THREADS SDL_TIMERS SDL_VIDEO VIDEO_KMSDRM \
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? :-(
(In reply to Gerald Pfeifer from comment #3)
Just an overly elaborate port Makefile:
% pkg info -d sdl2
(In reply to Alex S from comment #4)
Also see https://www.freshports.org/devel/sdl20/#dependencies and https://www.freebsd.org/cgi/ports.cgi?query=^sdl2.
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
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?
A commit references this bug:
Date: Mon Oct 5 11:51:44 UTC 2020
New revision: 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 <firstname.lastname@example.org>
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!
(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.