[WIP] Generalize Mappings

[Holzhaus]

Gosh, this one has grown huge.

The basic idea of this is to generalize the whole input handling stuff (since you do that over and over again in every single Input implementation) and also make mapping thing I wrote for the evdev implementation more reusable.

We have an InputMapping class that contains a mapping. They are managed by a InputMappingStore (which does nothing more than to load and store them and make sure that they don't get loaded twice).

We have an abstract InputHandler class that takes care of all the boring stuff like handling the button/axis codes, converting axis values and so on.

What the actual implementations do is to derive a subclass of InputHandler (e.g. EvdevInputHandler and define these methods:

• std::string get_api_name() - just return the API name as string, e.g. "evdev"
• std::string get_default_mapping_filename(); - returns a default mapping filename in case no custom mapping was supplied or could not be opened (e.g. controller_generic.cfg)
• void get_axis_limits(const InputAxisCode code, InputAxisLimits& limits); - get the axis maximum. minimum and deadzone values and write them to the according field in the limits struct (if minimum == maximum, conversion is disabled)
• void handle() - Read the actual events (e.g. from a Queue) and pass them on to handle_button()/handle_axis()
• bool setup_device(std::string device) - Do the device setup (e.g. open the evdev descriptor and stuff like that).

All of that is not that hard and should be a bit shorter than the original code, plus you get button/axis handling, axis value conversions and mapping logic for free. Also, we reduce the number of different code paths (or rather the size, because they share a lot of code now).

As a proof of concept, I ported evdev and the Linux joystick to this. I also have an SDL Joystick implementation on my HDD, but I'm not sure what to do with the Mouse and Keyboard handling in there.

Still not sure if the API is good enough though. If you like the general idea, I'll try to port the Win32 input stuff to this and check if that works out, too.

[skmp]

This does sound like a step to the right direction. I'm heading to bed now and can't look on the actual implementation. Interestingly enough, I was thinking about smth similar today (while working on unrelated issues)

[Holzhaus]

Maybe we should just drop the evdev/joystick implementations and focus on a single SDL codepath and make use of SDL's built-in support for game controller mappings.

[baka0815]

I will take a look at this and #823 in the upcoming weeks and try to rework the missing bits for the current codebase.

[skmp]

(Cleaning up old tickets - @flyinghead you might wana take a look for inspiration)