iPod 5.5G scrollwheel responsiveness - any work being done?

[nicke2323]

Not sure where to post this, so sorry if it ended up in the wrong place.

Have had Rockbox on my new 80GB iPod Video for a few weeks now, and I find Rockbox superior to the iPod firmware in every respect except scrollwheel responsiveness. This single issue makes Rockbox on the iPod feel clunky, despite its awesomeness in all other respects.

I think I read somewhere that this is due to limitations in the scrollwheel driver, but now I can't find that post. Is this correct? If so, is there any work being done to update the driver?

[tdtooke]

If you don't mind building from source you can find "#define WHEEL_SENSITIVITY 4" in firmware/target/arm/ipod/button-clickwheel.c.  Set that to a lower value.  You'll have to play around a bit to get it just the way you want it.

[GodEater]

Have had Rockbox on my new 80GB iPod Video for a few weeks now, and I find Rockbox superior to the iPod firmware in every respect except scrollwheel responsiveness. This single issue makes Rockbox on the iPod feel clunky, despite its awesomeness in all other respects.

Could you define what you find wrong with the scrollwheel behaviour? Too slow? Too fast? Something else I can't imagine ?

[Sherv]

Could you define what you find wrong with the scrollwheel behaviour? Too slow? Too fast? Something else I can't imagine ?

Nicke2323 may be experiencing a different aspect of unresponsiveness but what I've noticed is that there are times when rotating (along) the wheel doesn't result in a smooth scrolling of the line selector (while in the file browser, for example). That is, if I move my finger along the wheel at a "medium" pace (no idea how better to quantify this, maybe in terms of RPM? the selector won't move proportionally, sometimes it even jumps, and it takes a lot of rotation to have the selector cover a relatively short distance. There are other instances, however, where the wheel works as usual, wherein it is extremely sensitive and you can cover long lists in just a quick flick....

[Zardoz]

In general it works well for me but there are times when it seems strange - scrolls slowly, jerks or jumps, scrolls too quickly, doesn't respond at all (particularly the menu and select buttons, but also the scrollwheel.) I thought I just had a dodgy scrollwheel, I can't imagine why it should be so intermittently odd

[Llorean]

Boosting. The scrollwheel will seem much more responsive when the CPU has more overhead to spare.

[Elias_Maluco]

In general it works well for me but there are times when it seems strange - scrolls slowly, jerks or jumps, scrolls too quickly, doesn't respond at all (particularly the menu and select buttons, but also the scrollwheel.) I thought I just had a dodgy scrollwheel, I can't imagine why it should be so intermittently odd

Yeah, those happens to me too.

[Buschel]

The "unresponsiveness" of the 5G in terms of list scrolling does not seem to be connected to the scroll-wheel part itself. It seems to be an effect of the performance when updating the screen. With its high resolution and mostly small WPS-fonts it takes a lot CPU. Especially when scrolling during playback (which consumes CPU as well and leaves the residual CPU-time for the scrolling) this effect can be seen.
For anybody who can build rockbox -> FS#8668 boost the CPU on wheel activity. This gives far better responsiveness.

[Zardoz]

that makes sense. but why the inconsistency? (these are questions by the way, not challenges or opinions!) I might have thought that updating the screen took up similar amounts of CPU per cycle regardless of whats on the now playing screen. what else affects cpu usage? different codecs etc i assume (musepack kicks ass btw). For players that have a video co-processor would there be any benefit in using it to perform functions other than playback/decoding? Sorry if i've digressed

[saratoga]

that makes sense. but why the inconsistency? (these are questions by the way, not challenges or opinions!) I might have thought that updating the screen took up similar amounts of CPU per cycle regardless of whats on the now playing screen.

I'm not really sure what you're getting at here, but if you mean why does scrolling seem slow, its in part because the code used from updating menu lines is pretty slow, and because the screen itself is slow. 

For players that have a video co-processor would there be any benefit in using it to perform functions other than playback/decoding? Sorry if i've digressed

I think the Gigabeat S and iPod Video are the only devices with video coprocessors.  For the Video, we can't use it at all since theres no compiler, and for the Gigabeat, its pretty limited in what it can actually do (image scaling and colorspace conversion I think).  The gigabeat main CPU is so fast it wouldn't make much sense anyway.

[Zardoz]

fair enough. (i wish i had a gigabeat  )
what i meant was if, like you say, the code used for updating menu lines is slow and the screen  itself is slow, why is it (responsiveness) only sometimes an issue? that's all. anyway thanks for replying. and thanks for developing such a cool piece of software. i hate to niggle. (i used rockbox on my X5 for years until it was stolen. it was only when i got an ipod i was 'forced' to post annoying questions here and hereabouts. how bout them apples??)

[nicke2323]

Original poster here, sorry for the delay in getting back. I just spent some time comparing scrolling in the iPod firmware with Rockbox in lists of identical lengths. My conclusion:

I actually prefer the scrolling dynamics in Rockbox to those in the original firmware. The main problem with Rockbox is that there is a slight delay after I stop scrolling until the cursor stops. The delay is only a fraction of a second or so, but that is enough to cause the cursor to consistently overshoot the target, no matter the scrolling speed (a slow speed only overshoots by one step, faster speeds by several steps). The constant need for scrolling back after overshooting is what makes the scrolling feel clunky.

I'd like to try the CPU boost patch to see of that reduces the stop delay, but have no way of compiling Rockbox at the moment.

EDIT:

Soap (one of the moderators) was kind enough to compile and send me the latest SVN version with the CPU boost patch. I am glad to report that this eliminates the stop lag completely. Scrolling now feels just as responsive as the original iPod firmware. I feel it accelerates smoother as well, but that may just be a placebo.

Two questions:

1. Can the code be improved to reduce the lag without the CPU boost patch?
2. Alternatively, can the CPU boost patch be committed?

[Llorean]

1) Possibly, and we're hoping to investigate that.
2) Almost certainly, but if it is, it reduces the possibility of more research time spent on 1. That being said, if we do a 3.0 release, the release version will probably have the patch (assuming no problems crop up with it) while the development version will probably continue not to for a while so that the signs of further optimizations are more obvious, at least until we're sure the lag won't go away so easily.

[Buschel]

Regarding the CPU boost patch: I am not sure it will be committed as lots of testing is needed -- especially to check effects on plugin behaviour (like games). The patch boosts the CPU on each scrollwheel activity, independent of the GUI context.
Maybe another interim solution (e.g. only boosting when GUI is in list context) must be found...