FS#10332 - Fix keymappings for different control styles (specifically IAudio M3 remote)

Attached to Project: Rockbox
Opened by Richard Corden (RichardC) - Sunday, 14 June 2009, 12:05 GMT
Last edited by Paul Louden (Llorean) - Sunday, 14 June 2009, 13:11 GMT
Task Type Bugs
Category Remote
Status Closed
Assigned To No-one
Operating System iAudio X5
Severity Low
Priority Normal
Reported Version Version 3.2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


*NB:* I have an iAudio M3, however I selected "iAudio X5" as the player type since I don't have any other player.

Firstly, I must apologise if there is a better way to refer to a closed bug. The following bug has been marked as closed:

The reason given being:
Reason for closing: Rejected
Additional comments about closing: Rockbox tries to be consistent across targets. We do not care about how the OF does this.

As a a general rule I completely agree with this sentiment, however, I wanted to highlight two things:

1) In this specific case the behaviour is not just consistent with the OF, but much more importantly, the behaviour is logically correct given the design of the remote (see attached image and notes below).

2) I would be surprised if anybody with an M3, (with appropriate development skills) would not immediately apply this patch to the source and rebuild ([0]=4&sev[0]=&pri[0]=&due[0]=&reported[0]=&cat[0]=&status[0]=open&percent[0]=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=)

Notes re image:

The red arrow at the bottom of the screen highlights the possible directions of the volume bar located on the bottom of the remote. There is an equivalent one on the top. With the current version of Rockbox, to move the next menu item, the toggle has to be moved to the left. In otherwords, a "back" movement results in the "next" menu item being selected.

The top toggle works as expected.

If the volume control was vertical, then the current behaviour would be 100% consistent, however the strange position here changes the expectation.

One thing that did surprise me, was that the specification of this information is hard coded into the build. It seems to me that this bug could be easily addressed (and would please everybody) if obvious mappings could be configured, possibly even with just "toggle options":

* Reverse context menu control [Y]
* Reverse .... [n]


This task depends upon

Closed by  Paul Louden (Llorean)
Sunday, 14 June 2009, 13:11 GMT
Reason for closing:  Duplicate
Additional comments about closing:  Please do not attempt to re-open rejected tasks by simply starting new ones. If you think it deserves more discussion, bring it up on the mailing list and get someone who *can* re-open tasks to agree with you.

Simply opening new tasks any time you disagree with a closure is very poor form.
Comment by Richard Corden (RichardC) - Sunday, 14 June 2009, 12:10 GMT
Trying to add attachment.