glfw
glfw copied to clipboard
Add FreeBSD support to the glfw joystick code.
Tested with the multimedia/webcamd port as "driver", and an Xbox One game pad. Assumes "Linux" for game pad definitions, which seems right as webcamd actually is wrapping the Linux drivers.
Note that part of this may have to be synced upstream with glfw. No idea how this process works in go-gl/glfw.
Explanation of the parts:
- This adds a dependency on the devel/inotify port. Seems like lots of other stuff already uses it anyway, I did not have to install it.
- Adapted
linux_joystick
to also work on FreeBSD:- Simplified the regular expression; in FreeBSD basic REs,
+
does not exist there. -
PATH_MAX
comes from<limits.h>
.
- Simplified the regular expression; in FreeBSD basic REs,
- Changed lots of ifdefs to also include FreeBSD.
One issue seems to be that it's unlikely this can be upstreamed to glfw - current glfw organizes joystick support differently enough for the same patch not working on both.
Hi,
Thanks for this however most of this patch needs to be sent to upstream.
Also the null joystick was accepted via https://github.com/go-gl/glfw/pull/285 so it might be a good idea to see why it was done that way in the first place. I'm no expert neither in joystick API nor in BSD so I don't want to misdirect.
I think it was done that way in the first place as it may have been easier.
Anyway, filed https://github.com/glfw/glfw/issues/1892 for now, which would then reduce this PR to just the changes to c_glfw_freebsd.go plus a new revision hash for upstream code.
However it kinda depends on whether glfw will accept changes on top of stable or if this will require a glfw 3.4 release and then go-gl/glfw upgrading to that with potential API changes. I'd really like to have my gamepad supported "soon".
Can we keep this PR open until we resolved how this should be upstreamed and ported back here?
No idea how this process works in go-gl/glfw.
The way we do it at the moment is to avoid introducing any downstream delta to the C files of glfw itself. That's why travis is failing - it gets the sources from the official repository and diffs them to make sure they're the same. The rationale is that we don't want to be maintaining a glfw fork.
To update glfw, modify https://github.com/go-gl/glfw/blob/master/v3.3/glfw/GLFW_C_REVISION.txt and run scripts/grab-upstream.sh.
I think I'd prefer to see a tracking issue in go-gl/glfw rather than this pull request.
I think your next step is to get this fixed in upstream glfw, and once it's in a glfw release, we can pull it in to go-gl/glfw.
Was this added upstream into glfw? If so, maybe this PR should be closed by now?
Doesn't look like it has landed upstream yet. Here are some references: https://github.com/glfw/glfw/issues/1892 https://github.com/glfw/glfw/pull/1952
Happy to leave this PR open for anyone who wants to watch for it getting closed, until that is resolved.