FS#11208 - More robust iPod keymaps

Attached to Project: Rockbox
Opened by Jeffrey Goode (Blue_Dude) - Sunday, 18 April 2010, 13:19 GMT
Last edited by Jeffrey Goode (Blue_Dude) - Saturday, 08 May 2010, 02:21 GMT
Task Type Patches
Category User Interface
Status Closed
Assigned To Daniel Stenberg (bagder)
Operating System iPod 1G/2G
Severity Low
Priority Normal
Reported Version Release 3.4
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


This is an attempt to create a iPod keymap that will work reliably on all screens with multiple button combos. Needs testing!

Only hotkey is changed for now but others probably need tweaking.
This task depends upon

Closed by  Jeffrey Goode (Blue_Dude)
Saturday, 08 May 2010, 02:21 GMT
Reason for closing:  Rejected
Additional comments about closing:  Superseded by later functionality
Comment by Jeffrey Goode (Blue_Dude) - Sunday, 18 April 2010, 13:43 GMT
Comment by Thomas Martitz (kugel.) - Sunday, 18 April 2010, 15:24 GMT
I don't see how your patch anything compared to r25665. The order of bitwise OR'ing surely doesn't matter.
Comment by Jeffrey Goode (Blue_Dude) - Monday, 19 April 2010, 04:48 GMT
Trigger hotkey on key release.
Comment by Marianne Arnold (pixelma) - Monday, 19 April 2010, 05:50 GMT
I can't imagine that this patch works ( I haven't tried either though).

The last item in this definition is called the pre-condition. BUTTON_NONE means "none of the buttons has to be pressed before", putting e.g. BUTTON_PLAY there means "the Play button has to be pressed before and not be released yet". I can't imagine how BUTTON_PLAY|BUTTON_REL should work there.

From what I saw after a quick glance yesterday when the trouble with r25665 was pointed out in IRC, I think the problem lies in the fact that other actions hit before. Unless you change the hotkey action to something that is not used yet and where nothing else can be triggered before, you might have to change other action definitions too (this can potentially mess up other screens too so you have to be careful). With r25655 it looked like ACTION_STD_CANCEL was hit before if you tried holding the button combo - the standard context is chained and the cancel action is mapped to a long press of Play with nothing in the precondition.

I just saw that everything with the Select button is "guarded" with a pre-condition so making the key combo in a way you have to press Select first and then Play *could* work, although I don't trust this before I tried myself... and this *is* possible to test in a sim (unfortunately I have to go to work now and don't have the time to either test or putting up a real patch, I apologise). The line should read
I think.

P.S. Sorry, I forgot for a moment that the hotkey combo is also supposed to work from the WPS and didn't check the wps context. Knowing how complex the WPS keymap is though, I expect clashes there.
Comment by Jeffrey Goode (Blue_Dude) - Monday, 19 April 2010, 12:20 GMT
The problem with your more conventional solution is that the ACTION_WPS_HOTKEY or ACTION_TREE_HOTKEY event fires upon pressing the keys. This is great, except that if you're in the context menu and you pressed the HOTKEY combo on a valid assignment, a yes/no screen immediately pops up. Unless you're really fast and/or time it correctly, one or more of the HOTKEY combo keys is still being held down when entering the yes/no dialog. The yes/no dialog is unique in that it interprets *any* keypress other than select as a request to cancel the action. Merely releasing one of the HOTKEY combo keys is a "keypress" so the yes/no dialog is dismissed almost immediately. The solution, unless you want to rewrite the yes/no or action code, is to fire the HOTKEY event upon *releasing*, not pressing, the appropriate keys. This clears the keypress release so you go into the yes/no dialog with a clean slate. It works in the sim, and since the keypresses are "short", not "long", there is a natural timing element built in that limits any change in perceived function.