[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).