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

Status Closed
Percent Complete
100%
Task Type Bugs
Category Remote
Assigned To No-one
Operating System iAudio X5
Severity Low
Priority Very Low
Reported Version Version 3.2
Due in Version Undecided
Due Date Undecided
Votes
Private

Attached to Project: Rockbox
Opened by RichardC - 2009-06-14
Last edited by Llorean - 2009-06-14

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

*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:

http://www.rockbox.org/tracker/task/9548

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 (http://www.rockbox.org/tracker/task/9554?string=iAudio&project=1&type[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]

Etc.

Closed by Llorean
2009-06-14 13:11
Reason for closing: Duplicate
Additional comments about closing: Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

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.