Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#8409 - Added iRiver H10 sliderbar functionality

Attached to Project: Rockbox
Opened by Davy Durham (ddurham) - Sunday, 06 January 2008, 05:17 GMT+2
Task Type Patches
Category User Interface
Status Unconfirmed
Assigned To No-one
Player Type iriver H10
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Private No

Details

This patch adds fairly decent support for the sliderbar on the front of the iRiver H10 series players. This functionality is prominently displayed on the H10 wiki as something that is significant and missing.

With this patch the user can slide his finger over the slider to produce a scrolling effect. Or, they may also tap or hold down the upper or lower 30% of the slider for the older up/down behaviour with auto-repeat provided by the common code. This basically mimics the OF's functionality.

The physical slider is very sensitive, so the values that come back from it are fairly spastic. I've attempted to tone down any wild behaviour, and I've added #defines in the patch that can be used to tune the behaviour. But frankly, even the user's thumb size will affect what "good" values are. I believe what I have is good for the time being, but more tweaking may be necessary as time goes on.
   iriver-h10-sliderbar-support.patch (8.3 KiB) 
 firmware/export/config-h10.h                |    4 
 firmware/export/config-h10_5gb.h            |    4 
 firmware/target/arm/iriver/h10/button-h10.c |  145 ++++++++++++++++++++++++++++
 3 files changed, 153 insertions(+)

This task depends upon

Comment by Peter D'Hoye (petur) - Sunday, 06 January 2008, 22:26 GMT+2
without trying to tune the values, this was next to unusable. So either we need good common values or user calibration :(
Comment by Davy Durham (ddurham) - Monday, 07 January 2008, 01:20 GMT+2
Hmm.. works for me.. I'm testing on a H10 6GB.. you? wondering if the model matters. I should have a 20GB model in soon, and can test there too.

Are you still able to use the upper and lower 30% as up/down buttons that work mostly like the old implementation?
Comment by Peter D'Hoye (petur) - Monday, 07 January 2008, 08:29 GMT+2
H10 5GB 'pure'

upping the first move time a bit helped a lot. upper/lower 30% seems ok
Comment by Davy Durham (ddurham) - Monday, 07 January 2008, 16:20 GMT+2
your thumb must be larger than mine or you're using more pressure than I am.. The deal is that when one initially presses on the pad the values return can be anywhere from where the top of area you're touching down to the bottom. Since the range is about 1000 (base10) units on the slider that means if you're touching 1/5th of it then that move area threshold #define needs to be a little bit more than 200 , which means that *at most* the user could scroll only 5 lines down in the UI. So I made that #define the *initial* amount they have to move, and once their finger is moving it doesn't require as much change (I divide the #define's value by 6) in the values (unless you start going the other way, then it requires the full amount again).

This divisor could be adjusted as well. The larger you make the INITIAL_MOVE_THRESHOLD #define the less the user can scroll unless you make the divisor larger requiring less movement once your already moving.

Does this make sense?

If so, perhaps you can play with the values a little more and tell me what they are and I'll see if they work for me too.

Or if you can think of a different method I can attempt to alter the implementation.

thanks
Comment by Peter D'Hoye (petur) - Monday, 07 January 2008, 22:48 GMT+2
I can't find a suitable value and I do not have fat fingers (to the contrary).

The problem is two-fold (as I see it):
- when sliding, the up/down button zones should not be active, because when you reach them when sliding you get up/down button repeats
- during a slide, there should be no flipping from top to bottom or bottom to top, just like when having button repeat. It would feel natural to allow a flip when starting a slide while at the top/bottom but that is almost impossible to implement so I'd forget about it ;)
Comment by Davy Durham (ddurham) - Tuesday, 08 January 2008, 00:37 GMT+2
I left the up/down button zones active because I figured if you slide and then stopped on a zone you'd want it to auto-repeat (IIRC the OF behaves this way), perhaps I need to adjust the timing.

Would you mind comparing the OF's behavior with my patches and compare what's wrong/right? I've already done this and believe I've duplicated it. My 20gig model came today, I will be playing with it tonight.

Concerning it flipping from top to bottom or bottom to top, I really cannot control this I don't beleive because I'm just sending BUTTON_DOWN or BUTTON_UP states and it's the calling code that chooses to wrap the menu. If I could ask the currently active menuing system if it was at the top or bottom item I could avoid the wrapping. Do you know if there is a way of knowing that information?

Comment by Peter D'Hoye (petur) - Tuesday, 08 January 2008, 16:13 GMT+2
I never really used the OF so I'd have to check that...

I think that issuing repeat messages prevents the under/overflowing. No player here with me to confirm this :/
Comment by Johnathon Mihalop (Soul-Slayer) - Wednesday, 09 January 2008, 00:26 GMT+2
This is odd, every time someone posts a calibration for the H10 touchpad, claiming it to be better, everyone else claims it to be unusable. Just a coincidence, or something more sinister I wonder.
Comment by Davy Durham (ddurham) - Wednesday, 09 January 2008, 05:11 GMT+2
So patches like this one have been done before? This one actually attempts to make it work as a slider.
Comment by Johnathon Mihalop (Soul-Slayer) - Wednesday, 09 January 2008, 20:12 GMT+2
No, not to make it work as a slider, but attempts to make it 'less jumpy' and so forth work for the person who creates the patch, but there's always someone who reports it as unusable.
Comment by Peter D'Hoye (petur) - Wednesday, 09 January 2008, 21:38 GMT+2
I think those yes/no reports were from before my change in the ADC timing (which was wrong). Readings are quite stable atm I think
Comment by Peter D'Hoye (petur) - Wednesday, 09 January 2008, 22:13 GMT+2
Note: if you want your code to make it into RB, have a look at DOCS/CONTRIBUTING about the coding rules, like line length, variable names,....
Comment by Peter D'Hoye (petur) - Sunday, 13 January 2008, 21:14 GMT+2
your approach changed to follow the coding rules, with slightly changed constants to make it fairly usable
   slide.patch (9.4 KiB) 
 firmware/export/config-h10.h                |    4 
 firmware/export/config-h10_5gb.h            |    4 
 firmware/target/arm/iriver/h10/button-h10.c |  170 ++++++++++++++++++++++++++--
 3 files changed, 171 insertions(+), 7 deletions(-)

Comment by Davy Durham (ddurham) - Monday, 14 January 2008, 16:22 GMT+2
Thanks Peter, I'll try it out and see if it's usable for the both of us.

I've been thinking about altering the algorithm a bit to support acceleration. Not totally sure yet, but I want to play with using a moving average over the values coming from the slider.

Another thing: I also could easily making "tapping" the middle area of the slider the same as pressing the select button. That would be a deviation from the OF, but do you think that'd be useful? The current patch has a commented out section that does make it behave this way.
Comment by Peter D'Hoye (petur) - Monday, 14 January 2008, 16:48 GMT+2
I also started a completely different implementation to see if I could make the whole thing more stable. I went to the OF once to see just how well they did and something started itching ;) It is not in a usable state but maybe I get some progress tonight.
Comment by Peter D'Hoye (petur) - Tuesday, 12 February 2008, 01:24 GMT+2
Work in progress, my own remarks:
- contains some remains of debug code to be removed
- fails to handle tip-touching up/down but I can't figure out why
- sliding is way to slow
   h10_touchpad.diff (4.9 KiB) 
 firmware/target/arm/iriver/h10/button-h10.c |  106 ++++++++++++++++++++++++----
 1 file changed, 93 insertions(+), 13 deletions(-)

Comment by Peter D'Hoye (petur) - Sunday, 20 April 2008, 01:14 GMT+2
Another simplified version. The constants might need a bit more tweaking. Tip-touch operation disabled because it was not working...
   h10_touchpad2.diff (4.9 KiB) 
 firmware/target/arm/iriver/h10/button-h10.c |   97 +++++++++++++++++++++++-----
 1 file changed, 80 insertions(+), 17 deletions(-)

Comment by Peter D'Hoye (petur) - Monday, 21 April 2008, 00:11 GMT+2
more tweaking....
   h10_touchpad3.diff (4.9 KiB) 
 firmware/target/arm/iriver/h10/button-h10.c |   97 +++++++++++++++++++++++-----
 1 file changed, 80 insertions(+), 17 deletions(-)

Comment by Peter D'Hoye (petur) - Monday, 21 April 2008, 00:13 GMT+2
codepolice :/
   h10_touchpad4.diff (5 KiB) 
 firmware/target/arm/iriver/h10/button-h10.c |   98 +++++++++++++++++++++++-----
 1 file changed, 81 insertions(+), 17 deletions(-)

Comment by Thomas Martitz (kugel.) - Monday, 07 September 2009, 01:50 GMT+2
What happened about this one?
Comment by Peter D'Hoye (petur) - Monday, 07 September 2009, 18:34 GMT+2
unreliable....couldn't get it to work stable (how iriver manages this is a miracle). No time to try more things atm...

Loading...