Rockbox

without trying to tune the values, this was next to unusable. So either we need good common values or user calibration :(

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?

H10 5GB 'pure'

upping the first move time a bit helped a lot. upper/lower 30% seems ok

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

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 ;)

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?

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

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.

So patches like this one have been done before? This one actually attempts to make it work as a slider.

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.

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

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,….

your approach changed to follow the coding rules, with slightly changed constants to make it fairly usable

   slide.patch (9.4 KiB)

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.

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.

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)

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)

more tweaking….

   h10_touchpad3.diff (4.9 KiB)

codepolice :/

   h10_touchpad4.diff (5 KiB)

What happened about this one?

unreliable….couldn't get it to work stable (how iriver manages this is a miracle). No time to try more things atm…