glfw icon indicating copy to clipboard operation
glfw copied to clipboard

Add FreeBSD support to the glfw joystick code.

Open divVerent opened this issue 3 years ago • 6 comments

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>.
  • Changed lots of ifdefs to also include FreeBSD.

divVerent avatar Apr 28 '21 13:04 divVerent

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.

divVerent avatar Apr 28 '21 13:04 divVerent

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.

tapir avatar Apr 28 '21 13:04 tapir

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?

divVerent avatar Apr 28 '21 16:04 divVerent

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.

pwaller avatar May 07 '21 15:05 pwaller

Was this added upstream into glfw? If so, maybe this PR should be closed by now?

Jacalz avatar Dec 10 '21 13:12 Jacalz

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.

pwaller avatar Dec 10 '21 14:12 pwaller