[garbear]

It looks to me like we need to support a second D-Pad. The N64 controller C keys act as a 2nd D-Pad. Imaging playing Golden Eye with the current mappings using an Xbox 360 controller. I think this means that we need a way to map analog to digital buttons. If you could map the Xbox 360 right analog stick to the second D-Pad then playing Golden Eye would feel natural. The Dreamcast Maple Bus protocol also supports a 2nd D-Pad, though I don't know of any controllers that actually have a second D-Pads.

I would map the Xbox black and white buttons to L and R. Then are analogous to the LB/RB from the 360 controller.

See what I wrote in post #3. There's a large, near-infinite amount of ways to map every controller to a permutation of 17 (ish) buttons. To make this problem more tractable, we're going to map all these controllers to a single standardized 17-buttoned controller. This will be the role of an add-on so that its large dataset can be updated independent of Kodi.

Kodi, then, will be able to reassign these buttons via a single joystick.xml (I half-assed one here). Remapping buttons is done by modifying joystick.xml, analogous to keyboard.xml, remote.xml, etc.

Where can I read about the new Input API? I was wondering if it supports dynamically adding and removing inputs? Will it support force feedback?

The (half-finished) API is well-documented, so reading the source will probably give you a good idea of what it's capable of:

• xbmc_peripheral_types.h lists the enums and data structures used by the API
  
• xbmc_peripheral_dll.h lists the add-on's functions that Kodi can call
  
• xbmc_peripheral_callbacks.h lists Kodi's functions that the add-on can call
  

The API introduces a new kind of add-on: Peripheral add-ons. The first implementation is joysticks. Next will probably be media readers (like the Retrode) so that ROMs can be played and downloaded directly from cartridges.

Here's how the joystick part of the peripherals API works:

When Kodi detects a hardware change, it has the add-on rescan for new joysticks via PerformJoystickScan().

Drivers report 3 different kinds of elements: Buttons, Hats (d-pads) and Axes. Except some drivers report hats as 4 buttons. And some report hats as axes. And some combine two triggers into a single axis. And there's probably lots of other driver fuckery yet to be encountered. Initially, PerformJoystickScan() will simply return this raw data.

Kodi is then responsible for telling the driver how to interpret this data. It can call SetButton() to assign a random button (e.g. button 1 or button 2) to a standardized ID (e.g. "A" or "Start"). It can call AddTrigger() to assign an axis to 1 or 2 triggers and AddAnalogStick() to assign two axes to a single analog stick.

Once these raw axes have been assigned to "virtual" triggers and analog sticks, the driver will then start reporting state changes for these elements via callbacks in xbmc_peripheral_callbacks.h (which I have yet to write).

So raw data produces no Kodi events. As Kodi gradually describes how the raw data maps to physical elements, the add-on will start reporting state changes for these mapped elements.

Will it be possible to remap key combinations? i.e LT+RT+Start+Back => Guide button (old school xbox reset trick) ?

I think key combinations will muck up the API. There's a large desire to keep it as simple as possible because of all the layers of abstraction it involves. Binary add-ons are forced to use a C interface. We abstract this by wrapping it in a C++ interface. We then abstract this by placing the C++ calls into objects. Small additions to the API result in a *lot* of extra work. Key combinations will probably be deferred to Kodi.

However, there is merit in allowing this. We already have an API call to associate one raw button with a standardized one. Associating two raw buttons to a standardized one would mean that this combination can happen at the driver level so that Kodi doesn't have to deal with this. However, then we're limited to a small number of combinations (at most the add-on can report 17-ish buttons). If Kodi processed combinations, then we could expose this to joystick.xml for a near-infinite amount of possible combinations.

EDIT: Now that I think about this, I really like the idea of doing combinations in both the add-on AND kodi. This would let all controllers, even ones with a limited amount of physical buttons, present the same number of standardized buttons.

Some controllers have rumble/force feedback and a LED features.
I don't know if the libretro cores support this, but maybe this should also be a part of the input API?

I'll make sure the API includes rumble and LED support. Games already support rumble; they expose two rumblers, a weak one and a strong one, that can both be set to a strength from 0.0 to 1.0.

Don't know enough to know how to ask this, but what are the buttons from OEM controllers "sent as" when using USB adapters? Do you already know if a specific adapter brand is "suggested"? Some time back you mentioned having the USB adapters for OEM controllers, hope that's still the case

The driver reports the name of the adapter. This is simply matched against a database of known adapters (this is already done using "altnames" in the existing keymaps).

[natethomas]

As far as major or semi-major Android controllers go, the Ouya and the NVIDIA Shield are basically just repeats of the xbox 360 controller.

Also, this could be a v2 (or vNever) sort of request, but if the addon knows what controller you are using, and knows what each button does, does that mean it'd be possible to expose to the skinning engine button suggestions similar to those you see in various video games? For example, in the image below, Skyrim gives you the chance to continue and knows that I have my 360 controller connected, so it suggests hitting A if I want to continue from my last game and B if not. When the controller is not hooked up, it alternatively suggests Enter and Esc (I think).



If buttons were exposed to the skin, in theory a skin could show you a bunch of options. Like if you highlighted a show, it might say A Play, X context menu, B back, or similar. I'm not a skinner, so I'm not really sure what the optimum view would be.

edit: Also worth noting, if you do implement key combinations, being able to see the appropriate combination without requiring memorization would naturally be quite nice.

[garbear]

As far as major or semi-major Android controllers go, the Ouya and the NVIDIA Shield are basically just repeats of the xbox 360 controller.

Also, this could be a v2 (or vNever) sort of request, but if the addon knows what controller you are using, and knows what each button does, does that mean it'd be possible to expose to the skinning engine button suggestions similar to those you see in various video games? For example, in the image below, Skyrim gives you the chance to continue and knows that I have my 360 controller connected, so it suggests hitting A if I want to continue from my last game and B if not. When the controller is not hooked up, it alternatively suggests Enter and Esc (I think).

If buttons were exposed to the skin, in theory a skin could show you a bunch of options. Like if you highlighted a show, it might say A Play, X context menu, B back, or similar. I'm not a skinner, so I'm not really sure what the optimum view would be.

edit: Also worth noting, if you do implement key combinations, being able to see the appropriate combination without requiring memorization would naturally be quite nice.

Very good points for someone posting at 5 in the morning text-based button labels allow for a poor-man's version of your skyrim example. button icons are a possibility, but what if you're using a crappy knockoff controller where *all* the buttons are unlabeled? at least textual labels allow for a generic "Button 1", "Button 2" fallback. what if two different controllers are connected?

Every time a binary API changes and compatibility is broken, baby Jesus cries a little. for this reason, I'll probably allow for button icons in the peripherals API. actually implementing them has its own set of challenges and may never happen, but better safe than sorry in this case.

[Montellese]

button icons are a possibility, but what if you're using a crappy knockoff controller where *all* the buttons are unlabeled? at least textual labels allow for a generic "Button 1", "Button 2" fallback. what if two different controllers are connected?

We could put the button labels and icons into the addon that provides the keymap etc. Those things shouldn't really be in core anyway.

Concerning multiple connected controllers that's probably a tricky one. Are the controllers always numbered? If so we could just show the icons that are used by the first connected controller. Otherwise we could remember which controller provided the last input and show those icons. At the beginning we would again fall back to the first connected controller.

[topfs2]

button icons are a possibility, but what if you're using a crappy knockoff controller where *all* the buttons are unlabeled? at least textual labels allow for a generic "Button 1", "Button 2" fallback. what if two different controllers are connected?

We could put the button labels and icons into the addon that provides the keymap etc. Those things shouldn't really be in core anyway.

Concerning multiple connected controllers that's probably a tricky one. Are the controllers always numbered? If so we could just show the icons that are used by the first connected controller. Otherwise we could remember which controller provided the last input and show those icons. At the beginning we would again fall back to the first connected controller.

SteamOS has solved this by simply using the assets of the last used controller, which I think is the easiest way of achieving this. If we generalize the controller parsing we have in Application I reckon it should not be too hard to know which is the last used one.

[garbear]

controllers are indexed, but the only guarantee is that indexes are unique. for games, we'll need a way to map these indexes to player numbers. also, the peripheral API allows joysticks to request a player number, such as if a 360 controller is plugged in and the "player 1" LEDs light up. if player 2 leaves, we don't want player 3 to become player 2 mid-game, but if a 2-player game is launched we don't want to have only players 1 and 3.

The icon shown should be player 1. some games only allow player 1 to control the system anyways, so this makes sense. allocating controllers to player numbers is a much trickier problem that will need to be solved.

[topfs2]

controllers are indexed, but the only guarantee is that indexes are unique. for games, we'll need a way to map these indexes to player numbers. also, the peripheral API allows joysticks to request a player number, such as if a 360 controller is plugged in and the "player 1" LEDs light up. if player 2 leaves, we don't want player 3 to become player 2 mid-game, but if a 2-player game is launched we don't want to have only players 1 and 3.

The icon shown should be player 1. some games only allow player 1 to control the system anyways, so this makes sense. allocating controllers to player numbers is a much trickier problem that will need to be solved.

SDL 2 has switched to ID's IIRC. Which helps a bit here.

[garbear]

not all joystick APIs use IDs, and the API has to cater to the lowest common denominator

[garbear]

I'm designing the GUI controller configuration utility. Any feedback is appreciated.

Here, the user configures A, selects the label from a list, then configures B, and selects the label from a list. Pay close attention to how the list options, and their order, is inferred from my controller analysis above.

http://pastebin.com/5ham9T0R

Here, the user configures A and B but in the opposite order. Pay close attention to how the list options differ from above. Again, notice how the selection and order of the suggested labels are derived from the data.

http://pastebin.com/KXbMtwbZ

Here, the user performs the first example but with a PS1 controller, and then goes on to configure the next two buttons. Notice for button 3, likely labels for button 3 and 4 are both offered. This reflects my assumption that users will have a different idea of whether square comes before triangle, or triangle comes before square. (this is also why both A and B are presented for the "OK" button). Eventually, if we collect keymaps on a massive scale, it will be possible to mine the data for these subjective differences.

http://pastebin.com/FPH6eGpe

Here, the user only has four main buttons, so decides to use the combination A+B for button 5 and X+Y for button 6... but doesn't perform the configuration in the order you'd expect. It's OK though, because the label for button 6 can cope with this.

http://pastebin.com/9ApgJapk

So, is this data-driven approach worthwhile, or is it way too over-engineered?

[Adam7288]

Man, we need to get you in touch with a proper GUI designer. You are a hardcore software engineer. Take a look at what Alex Stubbs, the person behind the Kickstarter project Ignition is up to.



He sent me a picture of his development environment and you can see the attention to detail he takes with the smallest aspects of the experience.

If we could somehow combine your strengths, my god. The result would be exceptional.

[garbear]

What I can do with the XBMC skinning engine is probably 1/1,000,000th of what alex can do with javascript. my last attempt at skinning was retroplayer's save state manager, and all I remember is the damn blue numbers wouldn't go where i wanted them to. if I posted in the skinning section of the forum, do you think any skinners would step up help with the controller configuration utility?

[Martijn]

What I can do with the XBMC skinning engine is probably 1/1,000,000th of what alex can do with javascript. my last attempt at skinning was retroplayer's save state manager, and all I remember is the damn blue numbers wouldn't go where i wanted them to. if I posted in the skinning section of the forum, do you think any skinners would step up help with the controller configuration utility?

I think it is best you first do the grunt work on getting it working and then later some GUI designer can go through optimising it.
I am sure we can do a similar setup "wizard" within our skinning engine.

[garbear]

Adam7288 is a genius I'll just do the wizard in javascript! that way, I won't be limited to linear lists and OK boxes in kodi's skinning engine. I may not be able to match alex's brilliance, but I sure as hell can write a simple web app. Eventually, some poor sap can translate my web app to the skinning engine. and until then, we'll have a fully-functional, graphical configuration utility (albeit outside of Kodi proper).

Garrett's thinking, meet box

[Adam7288]

Ay, get that chip off your shoulder Garret We can't be experts in everything. Thats the key to success - recognizing our own strengths and deferring to others where it makes sense. In this case, it is not simply a matter of programming languages.

Javascript is often the whipping boy of the programming world, but the example I posted had little to do with the programming language. What I meant to convey is the possibility that others could excel at the visual presentation of your underlying logic. You are necessary!

[garbear]

how about this?