Allow defining additional hotkey mapping

[caver01]

I would love to see a way to map Function+button where “button” can include any of the unused hotkey button combos. For example:

1. Function+START= “ESC”
2. Function+SELECT= “TAB”
3. Function+L and R =send bash command to adjust display LCD brightness (assuming that even exists)
4. Function to enable/disable SMB (once installed)

Why is this important? For Pi Zero projects, it can be very handy to get access to additional keys like ESC to exit stand-alone emulators or TAB to map keys in MAME. While RetroArch is great, the lower performance of the Zero is often better suited to using stand-alone emulators. Additional RetroArch features, while beneficial, carry overhead that can be conveniently avoided, provided you have a way to exit!

Ideally, defining custom hotkeys would be based on an intuitive UI, but a more practical approach could be done iteratively like so:

1. Start with a documented area of a .conf file with syntax examples and a list of available keymap choices. Technical, but functional.
2. In a future iteration, the .conf file could pre-list possible hotkey combos for given projects (i.e. MintyPi buttons) with values only populated for those in use (for volume up, down, Wifi, save state, etc.) showing how you could enable map keyboard keypresses or bash commands with the right syntax.
3. Same as above, only now go beyond just hotkeys--mapping of ALL buttons could be listed in a common configuration area. So, this version would have their main inputs, then their optional inputs with the hardware function/hotkey held down.
4. Develop an interactive config "builder" using script menus where you can select the combo to edit, then scroll through and pick the keyboard key to map, or OTHER and enter a command.
5. (Advanced) Incorporate above with the OSD

I think there are opportunities for basic functionality and refinement as you go forward, from raw editing to full-blown user-friendly scripting. Admittedly, the OSD integration is probably painfully more complicated than just exposing hotkey mapping functionality, and I see that is nice to have, but not a crucial aspect of this.

[withgallantry]

I've created a new version of the open source software which tackles many of the issues above:
https://www.bluuplabs.com/oneforall-v2/
Let me know what you think of the changes and if they address the issues. The biggest change is that it now allows for unlimited key mapping. Let me know if the examples make sense.
Once I've had a few people real world test I'll be updating the binary release here.

[caver01]

Hey, this is fantastic! Good timing for me as I should be able to dive in this weekend and provide feedback.

[caver01]

I think I understand the examples. So, the config file is merely listing key names from the master list alongside its corresponding GPIO? Then, combos are setup in the combo section by specifying the key name with both pins separated by a comma? If I have it right, then that is all simple enough. My last question is the hotkey. On MintyPi3 this has been referred to as the “function” key I think (the one labeled with the star) but I suppose it is just another GPIO input. Is it the pin for SHOW_OSD? And the other hotkeys listed are really just combos with that?

[withgallantry]

That's it exactly! So the SHOW_OSD is now the first key that the others combo with. Now that I have the functionality of combos, I might make it so that any two pins can be specified to do a particular action. I hadn't done that initially as I was planning to create a configuration option that completely disabled the overlay and hotkeys, leaving you with a battery monitor and keys. It would make more sense I thought to therefore have one main SHOW_OVERLAY key as it would then be easiest to disable that being registered in the main program.
Can you think of any functionality that might still be missing that you'd like to see?

[caver01]

Yeah: the ability to trigger a command. That would unlock the world.

[caver01]

Thinking about this further based on your last comment--it seems like the groundwork is somewhat there to support just a little bit more abstraction for extended functions (or "commands" as I put it earlier). I don't want to over-simplify the effort or belittle the accomplishments so far--it already enables a LOT, so thanks for that!

Ok, so reading your comment, it sounds like you have the same insight I did seeing OSD_SHOW is really just a hard-coded version of a COMBOS. If I read between the lines of your message, it sounds like COMBOS evolved to what it is now and that is why the function button (overlay trigger) mechanism exists separately as HOTKEYS. Having said that, I think I read you noticing that another way to go is to simply treat the hotkey as a consistently used COMBOS.

HOTKEYS could go away and be re-written as just another COMBOS, but it would need to perform more than just send a keypress from the input-event-codes.h. I noticed that standard list does not include your own items like VOLUME_UP or TOGGLE_WIFI, as I suspect these are special cases caught by your code.

So, now I finally come to it. . . assuming HOTKEYS could just as easily live under COMBOS, Can the underlying steps be broken out into the configuration file or another file? For example, lets say your command for VOLUME_UP is:

/usr/bin/amixer -q -c 0 sset PCM 1dB+ unmet no cap

Could you have a config file that allows the user to define the command whenever a named "key" is not a match to the standard input list? Something like:

[KEYS]
OSD_SHOW=22 #special function button
KEY_UP=12 #Up DPAD

[COMBOS]
VOLUME_UP=22,12

[CUSTOM_COMMANDS]
VOLUME_UP="/usr/bin/amixer -q -c 0 sset PCM 1dB+ unmet no cap" #or whatever it is
OSD_SHOW="code for display overlay--or even a call to another script.py"

See where I am going? For most examples, you are simply defining standard keys with GPIO pins, but for programmatic triggers--these are referencing a section of custom commands--some of which would get split out of the embedded code and be exposed, editable, extensible. Anyway, I don't know if that is possible or even smart, but it would shift focus into the hands of configuration to maximize flexibility. Thoughts?

[caver01]

Actually, the parsing order is probably important, so could be that it first checks CUSTOM_COMMANDS, and if the key listed is a match, execute after the =. If not a CUSTOM_COMMANDS, lookup the named key in the input-event-codes. Else, do nothing (or capture as an error: No Command or Key found). At least this way, you have ability to override with custom control instead of ambiguous conflict.

[caver01]

I want to add that I love what you are doing with this. If I were a better programmer I would help more directly with a PR. As it stands, my coding is rusty but my development mind for logic and algorithms is my best contribution. Hopefully, my input is constructive not annoying! ;-)