[Solo0815]

AWESOME!
can't wait to test it in Kodi 14+x

[Scourge]

how about this?

Did you move the image?

[garbear]

yea, to dropbox. i'll re-link the photobucket img

[Scourge]

Not bad at all! It looks in line with what I would expect from this functionality. I'd say you keep this and let the skinners think of fancy alterrnatives.

[Adam7288]

We got ourselves a savant here! Nice work!

[OmniBlade]

Looks like the standard layout table is a little off. Assuming we are basing the layout on the xbox360 layout being correct, the 1 should be cross on the PS layouts and B on the Wii layouts, 2 should be circle on the PS and A on the wii, 3 should be Y on Wii and 4 should be X on the Wii.

[garbear]

Glad you guys like it. Is the general concept OK? Can the underlying assumptions be improved?

Currently we have one mapping for each system, and one "default" for Kodi itself. The default has Kodi functions like "select", "scroll", etc. The console will have controller buttons. For *most* controllers, the NES screen will look exactly like:

Code:

Select: Select           Start: Start
.D-pad: D-pad                B: B
                             A: A

Is this what we want?

Getting this right is critical, because it directly dictates the demands of the Peripherals API and the Game API.

Looks like the standard layout table is a little off. Assuming we are basing the layout on the xbox360 layout being correct, the 1 should be cross on the PS layouts and B on the Wii layouts, 2 should be circle on the PS and A on the wii, 3 should be Y on Wii and 4 should be X on the Wii.

I mentioned this above,

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.

These decisions are exactly the kind that should be set by the community, instead of a single developer or user who "knows best". We can make keymaps "data-driven" by collecting keymap data and defaulting to the most popular configurations.

[natethomas]

To collect key maps, we'd need Kodi or the addon to phone home, right? I personally don't have a ton of objection to that, but in the past (at least for gsoc) I believe we made it an opt in kind of thing.

Edit: topfs2 would know more about that.

[garbear]

To collect key maps, we'd need Kodi or the addon to phone home, right? I personally don't have a ton of objection to that, but in the past (at least for gsoc) I believe we made it an opt in kind of thing.

Edit: topfs2 would know more about that.

after running the python button-labeler or the configuration GUI, we could ask the user if they'd like to vote for their configuration. that's exactly what's taking place. i can't imaging that ruffling any feathers

[natethomas]

Sounds reasonable enough to me.

[topfs2]

Again. Might be nice too look at how steamos has done it. They have a way for users to upload their maps of games. The users can manually select a keymap and by doing so they vote on that map. Those that just select default get the map which is the most voted map. Simple and effective.

However. This is probably on the overcomplicating side of things IMO. We are one app and there are like 10 gamepada out shouldn't be overly hard to have users upload sane defaults via PRS etc. A way go alter them locally though is beyond awesome.

[ziggurat]

Again. Might be nice too look at how steamos has done it. They have a way for users to upload their maps of games. The users can manually select a keymap and by doing so they vote on that map. Those that just select default get the map which is the most voted map. Simple and effective.

However. This is probably on the overcomplicating side of things IMO. We are one app and there are like 10 gamepada out shouldn't be overly hard to have users upload sane defaults via PRS etc. A way go alter them locally though is beyond awesome.

I believe they upstream their gamepad database to SDL and have it opensource.
http://youtu.be/MeMPCSqQ-34

[Mettbrot]

I believe they upstream their gamepad database to SDL and have it opensource.
http://youtu.be/MeMPCSqQ-34

This is actually what we are looking for, starting at minute 30

[garbear]

The SDL database that steam has helped generate will be useful and will make a good starting point for our database. We're gonna have to extend it in at least several dimensions:

• Support more APIs beyond SDL (DirectX, Linux Joystick API, whatever api android/osx will use)
  
• Support button labels. SDL makes everything look like a X360 controller, but I dislike asking the user to "Press Y" when they have A, B, C-right, C-down, C-left and C-up.
  
• Support keymaps. SDL just maps buttons to one set of buttons, it doesn't map buttons to media center actions or the various sets of buttons that retro consoles require.
  

Another thing in the video that caught my eye: "We can't physically make buttons appear out of nowhere". That's a shame, because with the use of button combos our system can perform this impossible feat

Thanks for bringing this video to my attention. The more exposure I get to how others do things, the better I can pick-and-choose the best parts to make our system outdo them all.

[natethomas]

Might be worth pulling @Koying in for Android stuff. I know he's had experience working with Android controllers through Ouya and the Shield, so he can probably provide some pretty useful input.