[garbear]

Not sold on the idea of delay tolerance on any button unless it can be configured and turned off where sufficient buttons are present for all mappings. Some games might require split second response even to the likes of start and select if they were involved say in pausing the flow of a game at a critical point to choose some action a character to take.

Sorry if i didn't make that clear - Kodi processes non-ambiguous buttons instantly. when a single button can serve two purposes (hold or double-press for a missing button), there's some ambiguity when it's pressed - should this press be considered as the real button or missing one? After a timeout, this ambiguity disappears and Kodi continues treating it as the desired button.

If your controller is only missing the 360 guide button, then only 1 or 2 buttons have to be dual-purposed. On the other extreme, this system allows you to play a PS/N64 (and PC games with limelight) with a simple SNES controller. I'm actually not sure that anyone would WANT to play PS/N64 with a snes controller - but I figure the more we optimize this, the more inclusionary our controller support becomes. Stop me if I'm over-engineering again.

Mapping every controller to the 360 layout internally and then mapping that to the cores is pretty much what retroarch does and works very well there IMO. One thing you might want to watch out for is when a console has multiple common controllers that might need different assignments. For example if I was running a megadrive emulator, I might want a different mapping for the abc buttons depending on if the core was set to emulate a 3 or 6 button joypad.

We can probably fix this by letting cores provide more than 1 configurable controller to the configuration utility. This is the kind of information that saves me much time down the road. I've never used many older consoles, so it's hard for me to make general assumptions sometimes. Thanks OmniBlade, and let me know if you can think of any other edge cases that we'll need to incorporate.