Iriver touchpad suggestion

[chaetophile]

Howdy! I use the iRiver H10 20Gig. Like many boxes, it has a design foible that Rockbox might be able to address.

The iPod's scrollwheel has the option, during playback, of scrolling through a track, which takes the place of ff/rw buttons. This is a wonderful idea, and makes audiobook listening so much more enjoyable. Long tracks get interrupted, and this feature make it possible to find your place in the track when resuming.

The iRiver's ff/rw buttons are slower than molasses in January in a JAR.
The iRiver has the touch-pad on the front, and it is only being used for volume and file-scrolling. Is there a way to make it scan through a track?

[Llorean]

Have you tried Rockbox's fast-forward yet? It accelerates quite nicely for long files.

[chaetophile]

I'm not actually using Rockbox yet, as it's not quite sorted for the H10. I like using the FM tuner. I am looking forward to losing the ugly firmware wallpapers! I shall overcome them with strange beauties.

Accelerating fast forward is a wonderful solution, thanks.
I was mostly disappointed to find that the iRiver's "river" was not used to its full advantage in the design. It seems such a glaring waste! I dislike Apple's
overproprietarinesses, but the iPod user-interface really is quite sweet.
Thanks for the answer!

[keenerd]

You'll probably be more disappointed with Rockbox, then.

True. the radio does not work, but you can dual boot both firmwares when needed.  Otherwise its fairly stable and slick.  H10 users miss out on some of the latest and greatest plugins, and it the code base is not optimized for our processor at all.  So we lag a bit behind in plugins.  (Gameboy emulation is slow, mpeg video is playable as long as there is no audio track, and battery life is about 1/3 of stock firmware.  Btw, that is just listening to music with the screen off.  No fancy postwork like crossfeed or plugins.)

The bigger issue that you'll take immediate notice to is the complete lack of scrollpad support.  The pad is not direction sensitive.  It is divided into two zones, each zone acting as a plain button.  Even this is not done well, as there is no dead space between the two zones, and the *very* top of the scrollpad triggers as a down button press.

Optimally (IMHO) the scrollpad would be divided into three zones.  The top and bottom act as normal buttons, and the center space initiates scroll mode.  (If you've ever used the gsynaptics linux touchpad driver, you'll probably get what I mean.)  Scroll up/down and button up/down would both do the same thing, just scrolling would be faster.  Anyway, the scrollpad still has a very long way to go.

You may not mind this.  Rockbox's FF/RW buttons have tweakable acceleration values.  Tracks can be zipped through with great ease, making scrollpad navigation a little superfluous.

H10 20Gb

[bluebrother]

I'm not actually using Rockbox yet, as it's not quite sorted for the H10.

Do you really consider it a good idea to give advices for Rockbox if you haven't used it yourself yet? I think that's a bit strange idea.

The pad is not direction sensitive.  It is divided into two zones, each zone acting as a plain button.  Even this is not done well, as there is no dead space between the two zones, and the *very* top of the scrollpad triggers as a down button press.

Nobody has found a good way to do it better yet. it's not done "not good" because nobody cares (your post sound a bit like implying that) but it's simply not that easy. If you have a good idea how to read reliable values from the touchpad please tell.

[keenerd]

I've been studying DSP programming, I know optimization is hard stuff.  I've done less driver reverse engineering, and I know that's even harder.  Didn't mean to imply anything.  But so far everyone who has used my H10 has had to have the "scroll buttons" explained to them, despite have never used an iRiver dap before.  Its the very first thing a new user notices, and its a bit of a turn off.

Rockbox has access to the absolute scrollpad data, with a resolution of 0x400.  Accuracy is low (jitters by about 0x20) so some sort of moving average would be needed for scrolling.  Pressure appears to be a binary value.  That's all under the debug menu.

I'm going to presume that I am missing something, and I'm going the the SVN to figure out what it is.  Because the two-zone behavior matches a comparison to 0x200, but the "top of the pad goes down" implies there is no check against the pressure bit.  (Basically, values around 0x120 are generated at the very top of the pad, but only when the pressure is light and the pressure bit is false.)  

So a dead zone could be as simple as adding one more comparison.  I doubt it is, because it would have been done already.

H10 20Gb

[keenerd]

Wow, was I wrong.  Its dirt easy to add the dead zone.

http://svn.rockbox.org/viewvc.cgi/trunk/firmware/target/arm/iriver/h10/button-h10.c?view=log&pathrev=10943

Code: [Select]

        /* Read scroller */
        if ( GPIOD_INPUT_VAL & 0x20 )
        {
            GPIOD_OUTPUT_VAL &=~ 0x40;
            udelay(50);
            data = adc_scan(ADC_SCROLLPAD);
            GPIOD_OUTPUT_VAL |= 0x40;
            
            if(data < 0x210)
            {
                btn |= BUTTON_SCROLL_DOWN;
            } else {
                btn |= BUTTON_SCROLL_UP;
            }
        }

Good zone boundaries would probably be 150 and 250, so the middle 25% of the pad is non-responsive.

Oddly enough, the pressure bit is tested (0x20).  So I don't know why the "top of the pad goes down".  Guessing the signal is even more noisy than thought?

The above button code is fairly stateless and instantaneous.  De-noising and/or scrolling requires several samples over time, opposite of how the code is written, and I don't have the slightest clue where that should be implemented.  Really comes down to differentiating between taps, drags and holds.  With a drag-mode-flag, since hold-the-button and pause-the-drag look awfully similar.  Ugh.

[keenerd]

Still working on the custom-build tool chain.  I am amused that all the instructions are for cygwin, but it isn't playing friendly with my Arch install.  Once that's sorted out, I guess I'll make a patch and look into getting SVN privileges.  

One thought on how a "simpler" scroller could be implemented:  the scrollpad sets repeat rate for button holds.  Near the center, slow repeat rate.  Near the top/bottom, fast repeat rate.  Linear transition from middle to edge.  Though repeat rate is already adjusted by acceleration, so it might be better to have the scrollpad set variable acceleration.

[bluebrother]

Still working on the custom-build tool chain.  I am amused that all the instructions are for cygwin, but it isn't playing friendly with my Arch install.

you can use the script tools/rockboxdev.sh to set up a tool chain. I built mine before the script was available, and it isn't hard at all. You might want to read the CrossCompiler page instead ...