Rockbox

Resync

I don't see how your patch anything compared to r25665. The order of bitwise OR'ing surely doesn't matter.

Trigger hotkey on key release.

I can't imagine that this patch works ( I haven't tried either though).

{ ACTION_WPS_HOTKEY, BUTTON_SELECT|BUTTON_PLAY, BUTTON_NONE }
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
{ ACTION_TREE_HOTKEY, BUTTON_SELECT|BUTTON_PLAY, BUTTON_SELECT }
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.

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.