Hi Matthew, Pritam, et alia QtGamepad is intentionally limited to gamepads, and does not include support for joysticks, or generic devices with an arbitrary number of axes/buttons. The design was primarily inspired by the HTML 5 gamepad API: https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API/Using_the_Gamepad_API
Gamepads have roughly the same Button/Axes configurations and you can see this in the definitions of these similar API's: Apple platforms native Game Controller API's: https://developer.apple.com/library/ios/documentation/ServicesDiscovery/Conceptual/GameControllerPG/Introduction/Introduction.html Android Game Contorllers: http://developer.android.com/training/game-controllers/controller-input.html#button And even the specialized SDL2 GameController module (which yes, does use the joystick API behind the scenes, but demonstrates the importance of the Gamepad specialization): https://wiki.libsdl.org/CategoryGameController So I do not support expanding the scope of QtGamepad in the way you propose, as I think if it belongs anywhere it is in a generic input API (or you can always still just wrap SDL's input module pretty easily). There are however some API's missing that a gamepads API might actually need about like accelerometer based motion controls as well as haptic feedback, so during the tech preview phase this feedback and input is important, but I would like to reiterate the scope of this particular module before the discussion get too far off on a tangent (as it tends to do on this mailing list). Regards, Andy Nichols ________________________________________ From: Development <development-boun...@qt-project.org> on behalf of Matthew Woehlke <mwoehlke.fl...@gmail.com> Sent: Monday, February 15, 2016 7:32 PM To: development@qt-project.org Subject: Re: [Development] some questions about QtGamePad On 2016-02-15 13:04, Matthew Woehlke wrote: > On 2016-02-15 06:36, pritam.ghang...@gmail.com wrote: >> Looking at the API it seems it has a very hard assumption on 2 sticks and >> 18 buttons. > > Please support arbitrary axes and buttons, as done in e.g. SDL. I wrote a joystick API in Qt a while back. It had three signals (I didn't get around to hat support): buttonPressed(int button); buttonReleased(int button); motion(QHash<int, double> axisPosition); The first two are obvious. The third (you'd probably want to use a different name) is emitted every time any axis value changes, and reports the current value of *all* axes. (This is an optimization / implementation detail; you could as easily have a signal per axis, or indeed do both.) Although I didn't need to have current-state accessors (consider if you really need these), they'd be easy enough to add. Hat support would probably look like: hatMoved(int hat, HatDirection direction); Looking at QGamepadManager, I notice that you treat the hat as a set of buttons. That doesn't strike me as a good idea. Buttons are normally orthogonal (that is, given any two buttons, both might be pressed at the same time). While it's true that you can be lazy and report hats that way, there are problems doing so. First, it precludes users mapping an entire hat to a single digital 2-axis control (or at least makes it much more difficult). Second, hat directions are *not* orthogonal; a hat is more of a digital version of an axis-pair, i.e. two values that are either {-1, 0, +1}. This isn't just a matter of how you can mash on the controller, it's also a question of what the hardware protocol is capable of reporting. -- Matthew _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development