doc: consider ideal input mapping a bit more

hosts/modules/gui/sxmo/hooks/sxmo_hook_inputhandler.sh

@@ -12,26 +12,29 @@
 #
 # proposed future design:
 # - when unlocked:
-#   - volup1   -> app menu
+#   - volup-release   -> app menu
-#   - voldown1 -> toggle keyboard
+#     - volup-hold    -> WM menu
-#   - pow1:volup1 -> volume up
+#   - voldown-release -> toggle keyboard
-#   - pow1:voldown1 -> volume down
+#     - voldown-hold  -> terminal
-#   - pow2 -> screen off
+#   - pow-volup xN    -> volume up
-#   - pow3 -> kill app
+#   - pow-voldown xN  -> volume down
-# - when locked:
+#   - pow-x2          -> screen off
-#   - volup1 -> volume up
+#   - pow-hold -> kill app
-#   - voldown1 -> volume down
+# - when screenoff:
-#   - pow1 -> screen on
+#   - volup    -> volume up
-#   - pow2 -> toggle player
+#   - voldown  -> volume down
-#   - pow1:volup1 -> seek +30s
+#   - pow-x1   -> screen on
-#   - pow1:voldown1 -> seek -10s
+#   - pow-x2   -> toggle player
-# benefits
+#   - pow-volup -> seek +30s
+#   - pow-voldown -> seek -10s
+# benefits:
 # - volup and voldown are able to be far more responsive
 #   - which means faster vkbd, menus, volume adjustment (when locked)
-# limitations
+# - less mental load than the chording-based approach (where i hold power to adjust volume)
-# - terminal is unmapped. that could be mapped to pow1?
+# - less risk due to not chording the power button
-# - wm menu is unmapped. but i never used that much anyway.
+# drawbacks:
-#   - or, i could add that to the primary menu.
+# - volup/down actions are triggered by the release instead of the press; slight additional latency for pulling open the keyboard
+#   - moving the WM menu into the top-level menu could allow keeping voldown free of complication
 
 # increments to use for volume adjustment
 VOL_INCR_1=5