[garbear]

What time is it there? Is it not 4am?

maaaaaaybe

Regarding question 3: I think we need to find a way to do this, the visual cue of seeing what physical controller controls what port is really valuable.

I agree, this should happen.

First, we need a way of automatically assigning controllers to ports. My current solution is poor.

Then, this can be shown (and ideally changed) in the GUI.

Regarding unassign inside a list: we can have it inside, but ideally I really don't want to go through a list to get rid of the list item itself - if that makes sense, so I'd keep it outside (as well)

You're the UX guy

Players:
I'd say 4 players at max for consoles that support it (n64 et similar).

If you want to cater for those strange devices that duplicate game controller ports we can do that too, but I'd hold off for now.
I'd do a basic version avoiding those gimmicks for now.

Limiting this to 4 players is OK, but I hold scalability in high regard and want a system that can handle more. If we limit ourselves to 4 players it needs to be a design decision, not an architectural one.

In Mame's case I think that besides a default mapping for "controller type" (steering wheel, gun, joystick, etc...) I think a per-game mapping is mandatory (later on, ok).

Agreed, per-game mapping will need to be possible. This relies on a game database though, and I'm really started to get annoyed at this architectural achilles heel.

I've literally created two game databases so far, one fully integrated into our messy current situation, and one completely separate from everything else. Both were complete failures, because the integrated one just made the situation more messy, and the independent one re-used too little code and became too big a project on its own.

If I attempt another one, hopefully I can find a goldilocks situation that is a compromise between the two.

Are we mapping RESET buttons for consoles?

We map whatever the emulator can support, and reset is built into the libretro API (and thus our Game API), so it's available to all emulators. It's adding one command more than we have buttons for, however, which entails button combos or sequences.

The difficulty is that Reset is not "input" per se, but a Kodi action. Only input is handled by our button mapper. Kodi actions must still be defined by our keymap system via joystick.xml. Allowing Reset to be mapped requires a system that lets ALL Kodi commands be mapped, so basically allowing Kodi to generate a joystick.xml. I purposefully limited my input work to cleaning up joystick.xml, not getting rid of it. One thing at a time. Indeed, though, Kodi actions should one day be mappable in the GUI, so keep this in mind.

On the Xbox, the combo to reset was L+R+Back+Black, which translates to L2+R2+Back+B on the 360 controller. I'll hardcode this into joystick.xml for now so that I can start developing button combos, and maybe one day we'll get GUI support.

So my real question now is: at what point can we start implementing parts of this to see how it works?
Do you need EVERY image of every console and every controller plus relative icons and ON/OFF statuses before it can be even started?

It would be nice if the system worked with incremental art upgrades so as I complete the art it can be inserted.

Then lets make the artwork a resource add-on so that it can be updated independently of everything else.

What I need is more concepts like the one you posted this morning. We need to nail down what's currently possible, and create a priority list for all the "wants" and "nice to haves". Once we get some concepts I can start on the skinning and C++.