Fix keymappings for different control styles (specifically IAudio M3 remote)

[RichardC]

Firstly, my apologies for adding a new issue against a closed bug (10332 -> 9548).  In my defense I was unable to add feedback to the previous bug (which is sometimes possible with bug tracking systems) and it wasn't obvious to me how else to add my comment.  Anyway, thanks to Paul Louden for explaining in detail what I need to do.

Basically, I would like for this bug to be reconsidered: http://www.rockbox.org/tracker/task/9548

It was closed originally with the following comment:

  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.


I agree with this principle, and all things being equal the default behaviour of rockbox should win in all cases.  In this case however, I feel that there are two additional aspects that need to be taken into account:

1)  It is not important that Rockbox differs to the OF in this regard, the more important point is that the design of the remote makes the behaviour of Rockbox completely unintuitive.  (See attached image and further notes below).

2) I believe all users of the M3 that are capable of using a compiler will apply the keymap patch and rebuild the source.  The only M3 users left with the default behaviour will be those that don't have a choice.  The patch can be found here:  http://www.rockbox.org/tracker/task/9554?getfile=17829.


Notes re attached image:

The red arrow at the bottom of the remote highlights the location and possible movement direction for the volume toggle. There is an equivalent toggle on the top for previous/next etc.  With the current version of Rockbox, to move to the next menu item, the toggle is moved to the "left".   In other words, a "back" movement results in the "next" menu item being selected.

The top toggle matches the expected behaviour, with moving to the right going into a folder or menu item, and moving to the left going out.

For music players with vertical volume controls, the behaviour of Rockbox is correct.

One thing that did surprise me, was that this information is hard coded into the source.  A possible win/win solution is to allow key-mappings to be configured rather than hard coding them.  This doesn't even have to be full control, even something simple as a direction toggle would probably be enough in most cases:

* Reverse context menu control?                  [Y]
* Reverse context menu prev/next control?  [n]


Regards,

Richard

[pixelma]

The red arrow at the bottom of the remote highlights the location and possible movement direction for the volume toggle. There is an equivalent toggle on the top for previous/next etc.  With the current version of Rockbox, to move to the next menu item, the toggle is moved to the "left".   In other words, a "back" movement results in the "next" menu item being selected.

Note: I have not really tried it and just go by the picture:

If I look at the picture and even how you drew the arrows (and I know this thing is such a round "rocker switch"), you can also see this movement as clockwise and not back. Then it makes sense to use it for going down in the list - and I think that's the reason why the developer who implemented it chose the button mapping this way.

2) I believe all users of the M3 that are capable of using a compiler will apply the keymap patch and rebuild the source.  The only M3 users left with the default behaviour will be those that don't have a choice.

There will at least be one other user who can compile - so has a choice - and will not apply the patch...

Edit: something I forgot to reply to earlier:

One thing that did surprise me, was that this information is hard coded into the source.  A possible win/win solution is to allow key-mappings to be configured rather than hard coding them.  This doesn't even have to be full control, even something simple as a direction toggle would probably be enough in most cases:

So far Rockbox's policy is against user configurable controls (ease of support, surely you'll find some threads about it here). I think that such a change could be considered as sneaking "configurable buttons" in and could give people arguments asking for more and more of those.

[RichardC]

If I look at the picture and even how you drew the arrows (and I know this thing is such a round "rocker switch"), you can also see this movement as clockwise and not back.

You've got me

I couldn't see anyway that the current behaviour could be explained!

Then it makes sense to use it for going down in the list - and I think that's the reason why the developer who implemented it chose the button mapping this way.

I've had my M3L for a few years now, and I've just realised that I'm probably finding it very difficult to separate what I'm used to with what I would expect coming at this cold.

I can see now how the clockwise/anticlockwise works as well as for the OF, and in some ways better since the Rockbox behaviour results in the remote volume control matching that of the main unit!

There will at least be one other user who can compile - so has a choice - and will not apply the patch... 

In order to do a definitive test of this, I'm going to try this out for a while and so I may well become user number two!

Thanks for your Reply!

Richard