[N3MIS15]

How about handling unknown joypad/controllers by having a dialog asking "press up, press down, press left, press right, press a" and so on (like retropie). Then map the buttons automagicly. IMO this is the quickest and easiest way to get a joypad up and running. From there the user should at least be able to navigate kodi without the need for another input method. A service addon should handle this rather nicely.

[Adam7288]

I approve of this KISS methodology. There will always be new controllers and obscure ones which are not cataloged, and any attempt to automatically recognize them is futile, and a waste of energy, since it is a setup once, and forget about it forever type of thing. There are so many more aspects to this project which deserve more energy.

[garbear]

A little update. I repurposed the touchscreen gesture-recognition engine for joysticks. If your controller is missing buttons (e.g. using SNES controller to control a N64 game), virtual buttons can be defined by holding, double-pressing, double-press-holding, and pressing multiple buttons at once.

What other joystick gestures would you guys like to see? tilting/flinging accelerometers, combo sequences... What if touching an analog stick could "grab" a slideshow picture and allow you to rotate it by spinning the analog stick in circles?

[garbear]

Here's how I envision the system working:

Every controller gets mapped to a 360 controller. If the controller is missing buttons, they can be emulated using gestures. Then, this standardized controller is mapped to individual consoles' controllers. Using the 360 controller as an intermediate simplifies the process of mapping X controllers to Y consoles; unknown controllers only need to be mapped once to support all consoles. I also plan to allow console mappings to be overridden on an individual basis (eventually).

The gesture recognition actually takes place in two levels: once to map raw driver elements (buttons, hats, axes) to physical 360 elements (buttons, triggers, hats, analog sticks, accelerometers), and once to map physical 360 elements to higher-level gestures (spinning analog sticks, accelerometer motions, etc).

Here's an example: Let's say joystick.xml allows multi-presses, and pressing Start + Select exits the game via PlayerControl(Stop). However, the controller is N64 and only has a start button and no select. If select is virtually mapped to a multi-press gesture (let's say A + B), then the game can be exited by pressing A + B + Start. Kodi won't see A or B being pressed - the lower level turns this into a Select before Kodi can look up the gesture in the joystick.xml keymap. Kodi sees Select + Start being pressed, and turns this into an "Exit-game" command.

Another example: If select is mapped to double-pressing A, then the game can be exited by pressing A then quickly A + Start. Because the double-press emits a Select, both A presses are absorbed by the lower-level and Kodi doesn't detect any A presses - only Select.

Does this two-level gesture detection scheme make sense? I think it's necessary to separate the databases into controller->360 mapping and 360->console mapping.

If anyone is willing to put on their thinking caps, I'd like to identify problems while I'm still close to the conceptual phase so I don't have to re-write thousands of lines of code during testing. Here's some thoughts:

• In the above example, Kodi sees Start + Select instead of A + B + Start. If the configuration utility displays "Start + Select", that will be very confusing as the N64 has no select. This can be fixed by exposing the lower-level button mapping to the configuration utility so it can properly display "A + B + Start" instead.
  

• If Select is mapped to holding Start or double-pressing Start, then the game can't be exiting using Start + Select, obviously.
  

• Response times will be slightly delayed for overloaded buttons (and only overloaded buttons). If double-pressing Start maps to Select, then "Start" can't be emitted until we're sure the user isn't attempting a Select. Double-press timeout is 500ms ATM, so if the user taps/holds Start, we won't know that they want Start instead of Select until the timeout lapses.
  
  Tapping example: At t=0, Start is pressed. At t=100ms, Start is released. At t=501ms, Select is no longer possible, so a "Start pressed" is emitted. Also at t=501ms, a "Start released" is emitted. To Kodi and emulators, it will look like Start is held for 0ms instead of 100ms, but any action registered to Start will still be fired (albeit 501ms late).
  
  Holding example: At t=0, Start is pressed. At t=1,000ms, Start is released (held for 1s). The "Start pressed" event is emitted at t=501ms and the "Start released" event is emitted at t=1,000ms. To Kodi and emulators, it will look like Start is held for 499ms instead of 1,000ms and the Start action will be fired 501ms late. However, if "Hold Start for 1,000ms" is mapped to an action in joystick.xml, Kodi is smart enough to emit the action at t=1,000ms instead of t=1,501ms.
  

• I don't think the response-time delays caused by the lower-level mapping is a problem. Most games use start to open a menu or pause, and opening a menu 1/2 second late is a small price to pay for a free Select button. I expect users will overload delay-tolerant buttons instead of primary gameplay ones like A and B.
  

• Multi-press buttons must be pressed within 80ms (tentatively) of each other. Therefore, if response time is an issue, use a multi-press gesture instead of a hold/double-press. In this case, overloaded (and only overloaded) actions will be fired only 80ms late.
  

• Things might get confusing if a combination of lower-level holds/double-presses are combined with higher-level holds/double-presses. ATM no holds/double-presses are recognized in the higher level.
  

[OmniBlade]

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.

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.

[ChrisMyhre]

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.

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.

The 3 button vs 6 button Gens with differnet mappings is a good case to point out. Very excited about the progress.

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

[tree_and_kite]

When running emulators on the orignial xbox a double joystick-click (pressing down on both joysticks at the same time) would exit back to the menu. Maybe that system would work here?

[garbear]

yes. we'll need an way to specify these gestures in joystick.xml. maybe

Code:

<keymap>
  <global>
  <fullscreengame>
    <gamepad>
      <lstick mod="hold">Stop</a>
      <lstick mod="doublepress">Stop</X>
      <lstick mod="doublepresshold">Stop</X>
      <multipress buttons="lstick rstick">Stop</X>

[Mettbrot]

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.

I don't really know if this is necessary at all. If you are a game enthusiast (which you probably are when you play snes or N64 on Kodi) there is a high chance that you have a controller with enough buttons as well. And If not, maybe you should just get one They are 20 bucks. 10 If you go for no-name wired.
I mean games with more buttons can be complex without even having to remember what physical button combination you have to press to 'emulate' a button with your snes controller...
Also input delay is a no go for controllers which have enough buttons.

[a1rwulf]

I agree with Mettbrot here. I don't think anyone is going to play n64 with a snes controller. As game enthusiasts or even as casual gamers you will be used to controllers of recent consoles.
They all have similar layouts to the xbox360 controller.
I would like to see these working as a first step and if community is asking for the mercedes of input, you could still decide to implement every bit of it.

[billyvnilly]

+1 to this. I don't feel you should be expending effort to make past controllers work with current controller's games. I would say focus on x360. I have logitech f710 controllers and ouya controllers that id love to see work eventually. but i think you should go for the highest yield of users, and to keep is simple.

[RockerC]

I have found that there are historically really only two basic gamepad layouts that are used as reference for all game controllers for the past 30-years or so, and those are originally modeled after SNES and Gamecube gamepads.


For example PSX/PS2/PS3/PS4 gamepad layouts are all very similar to SNES, and all Xbox controllers are is more similar to the Gamecube gamepad layout.

Now days however all modern game game controllers with analog tumb-sticks either follow PS2/PS3 game layout or Xbox 360 gamepad layout as reference.


Just something to keep in mind.


Regardless, you should try to checkout Ignition, it have a dead simple interface for setting up your gamepad or joystick for all the emulators

https://www.kickstarter.com/projects/171...-raspberr/

[garbear]

OK, controller input re-worked. This current approach works butter than trying to emulate missing buttons. Sometimes I slip into engineer mode and start solving problems that don't exist... Thanks for keeping me on track

A few people have started compiling my input work, so here's the status of this project:

• The joystick add-on scans for joysticks and emits joystick events
  
• Kodi handles the scan results by creating joystick objects
  
• Kodi hands the events to the joystick objects, events should get mapped to physical buttons but aren't hooked up to anything yet
  
• The joystick add-on is in charge of the actual mapping, but this hasn't been implemented yet
  

So, the next steps are:

• Sync joystick add-on's API with Kodi so the add-on DLL loads
  
• Implement basic/stubbed button mapper
  
• Forward physical buttons to game console "ports"
  
• Load joystick.xml actions
  
• Map buttons with no port to joystick.xml action
  
• Fully implement button-mapper
  

Regardless, you should try to checkout Ignition, it have a dead simple interface for setting up your gamepad or joystick for all the emulators

https://www.kickstarter.com/projects/171...-raspberr/

I've heard great things about this project, but it looks like it's only available to backers right now? Does anyone have a link for research purposes?

[ChrisMyhre]

OK, controller input re-worked. This current approach works butter than trying to emulate missing buttons. Sometimes I slip into engineer mode and start solving problems that don't exist... Thanks for keeping me on track

A few people have started compiling my input work, so here's the status of this project:

• The joystick add-on scans for joysticks and emits joystick events
  
• Kodi handles the scan results by creating joystick objects
  
• Kodi hands the events to the joystick objects, events should get mapped to physical buttons but aren't hooked up to anything yet
  
• The joystick add-on is in charge of the actual mapping, but this hasn't been implemented yet
  

So, the next steps are:

• Sync joystick add-on's API with Kodi so the add-on DLL loads
  
• Implement basic/stubbed button mapper
  
• Forward physical buttons to game console "ports"
  
• Load joystick.xml actions
  
• Map buttons with no port to joystick.xml action
  
• Fully implement button-mapper
  

Regardless, you should try to checkout Ignition, it have a dead simple interface for setting up your gamepad or joystick for all the emulators

https://www.kickstarter.com/projects/171...-raspberr/

I've heard great things about this project, but it looks like it's only available to backers right now? Does anyone have a link for research purposes?

Very exciting.