gamepad/joystick support

[photex]

Hello!

SDL2 joystick support and it's associated "gamecontroller" mapping support is very useful. It would be wonderful to have something similar that supported the SDL2 mapping format (steam for instance provides this mapping via an environment variable when launching an app or game from big picture mode).

Is anyone already looking into joystick support? I could contribute to linux support, and possibly osx, but I don't own a copy of windows.

[tomaka]

Gamepads/joysticks support is definitely something we want.

However I don't think the SDL2 mapping format should be part of glutin. It can easily be added later by writing a glutin_sdl_mapping library on top of glutin.

[emberian]

I need this. I'm going to work on this in the next few days for Linux/Windows/Mac (in that order).

[emberian]

This is quickly turning into more a nightmare than I was expecting. Tons of really ugly platform-specific stuff on each platform.

[photex]

Gameplay3d or sdl2 might be decent references perhaps? Gameplay in particular has a pretty simple platform layer to checkout.

[fkaa]

No need to do everything at once! I think it would be a good idea to first get a feel of how the API could look like. From my experience with SDL2 gamepad support, there was a lot of unsafe stuff (passing pointers here and there, checking for length and null and whatnot. For this I actually think simpler is better. The bare minimum for this to be usable would be:

• Each connected controller has a unique handle
• Must be able to test controller input by handle

To further extend on this functionality, we could:

• Add a layer of abstraction over the input, so there could be a single layout which would work with a variety of controls (Think XBox a, b, c, d mapping to Playstation's cross, square, triangle, circle etc.)
• Make each controller be identifiable by vendor name and input number to roughly separate devices like joypads and controllers. (Is there a more robust way to do this?)

[tomaka]

Add a layer of abstraction over the input, so there could be a single layout which would work with a variety of controls (Think XBox a, b, c, d mapping to Playstation's cross, square, triangle, circle etc.)

I'm not fan of this, I think this is too high level.

[emberian]

I agree with @tomaka. That doesn't belong in glutin. I've already designed an interface that I think will work, I'm solidifying it and working on the platform implementations.

[emberian]

(I'll share more when I have more ready)

[Kasran]

It has been over a year since this issue was last updated, and I would like controller support in glutin as well - I really don't want to have to switch window management libraries just for controller input. Is this still on the table for potential future support?

[photex]

To get support for game controllers done right it's probably not too hard to get into it... but it looks like a lot of tedious busy work.

Rather than toss that work into the core glutin project, I was planning to start an exploratory 'glutin_controllers' crate so that controller support could be opted in like it's done in a framework like libGDX.

That said, I have 3 kids and a day job so @Kasran I doubt I'd make any headway on this by the time you could use it.

[fkaa]

IIRC the conclusion was that controller support doesn't need to be tied to a windowing library at all, and thus could be a separate crate entirely.

[photex]

@fkaa that's certainly where I saw things headed, but I guess this ticket should perhaps be closed now?

[emberian]

Indeed. There are two intertwined problems: evented vs polling input APIs, and decoupling from the window's event loop. All of the APIs are separate from the window's event loop, and differ in opinion on whether to poll or wait for events. Glutin isn't a good place for this simply due to the first, but the second requires emulation layers depending on which sort of interface you expose, which would force glutin to make a policy choice.

[Kasran]

Fair enough... Out of curiosity, does anyone have any recommendations about what to use that's already out there?

[icefoxen]

The most well-developed joystick input crates at the moment appear to be, roughly in order: gilrs, reminisce, joy.

The traditional way to handle joysticks and game controllers seems to be to treat them as basically the same type of device, and have each device just have a set of "axis" and "button" inputs. So on a PS2 controller the thumbsticks would be axis 0 and 1, while the d-pad might be axis 2, and the buttons would be buttons 0-7 or whatever, while the most primitive joystick would just have one axis for the joystick itself and two buttons. Barring touch devices this model seems to encompass more or less everything, and leaves it up to higher-level abstractions to handle, mapping the differences between, say a PS2 controller and an XBox controller onto a game's inputs.

[Xaeroxe]

@tomaka I see the decision made here and I respect that it was made with the mindset that this is a low level window library, I do want to point out though that the first sentence on this crate's readme says it's a GLFW alternative, GLFW does have a high level controller abstraction. So ideally either a way to accomplish that should be provided in documentation, built into this crate, or we should change the readme to indicate this crate never plans on supporting it. I have controllers and Windows and Linux installations, so I'll be playing around with a way to do controller support on those platforms, either using the crates already listed or just making my own. I can make a PR to this repository if you change your mind and want a controller API.

[mitchmindtree]

For the record, I just want to mention that if anywhere, discussion on this topic would probably now be better suited to the winit crate, as it is the crate that handles management of windows and associated input events.

On a related note, a DeviceEvent enum was recently added to winit for sourcing more generic device events. This almost certainly does not yet support gamepad/joysticks and I believe it is only implemented for X11 so far, however it would likely be the best place to start looking if a user was serious about adding this kind of support to winit/glutin.

[xgalaxy]

IIRC the conclusion was that controller support doesn't need to be tied to a windowing library at all, and thus could be a separate crate entirely.

I'm confused what you are referring to? glutin bills itself as a GL and Input library. Surely game controller support is within the purview of said 'mission statement'. Supporting SDL2 game controller mapping would be a big part of that. Especially since GLFW 3.3 (which this library claims to mimic) has upcoming support.

[goddessfreya]

Closed as wontfix.