Rockbox

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

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#7451 - Alternative method of list acceleration for scrollwheel-based devices

Attached to Project: Rockbox
Opened by Michael Sevakis (MikeS) - Wednesday, 18 July 2007, 23:28 GMT+2
Last edited by Jonathan Gordon (jdgordon) - Monday, 23 July 2007, 13:27 GMT+2
Task Type Patches
Category User Interface
Status Closed
Assigned To No-one
Player Type PortalPlayer-based
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

This is _potentially_ applicable to any scrollwheel-based device. This first patch will only work on the e200 series however. It's not SVN ready but since the availablity of event data is sort of hacked in to make it just work.

List acceleration is based upon velocity-squared time a constant times number of missed wheel interrupts. The perceived velocity in the list should remain rather constant regardless of CPU load for any given wheel speed.

Fine control remains fine and yet you can move very far with a single wheel flick. It should be easy to aim for a particular range in the list (looking at the scroll bar). A small amount of time with it should make aiming pretty much a reflex action.
   wheel-acceleration.diff (6.3 KiB) 
 apps/action.c                                        |    7 ++
 apps/gui/list.c                                      |   49 ++++++++-----------
 firmware/target/arm/sandisk/sansa-e200/button-e200.c |   37 +++++++++++++-
 firmware/drivers/button.c                            |    5 +
 4 files changed, 67 insertions(+), 31 deletions(-)

This task depends upon

Closed by  Jonathan Gordon (jdgordon)
Monday, 23 July 2007, 13:27 GMT+2
Reason for closing:  Accepted
Comment by Steve Bavin (pondlife) - Thursday, 19 July 2007, 08:09 GMT+2
I can't really speak from experience, having only used an Ipod (3G I think) with it's OF (and never used Rockbox on a scrollwheel of any kind). However, I do recall be impressed by the responsiveness of Apple's UI and would think that would be the ideal for Rockbox.

I know that "the OF does it" is not, in itself, a good reason for doing anything, but Apple must be doing some things right to have their market dominance - style, certainly, but also the feel of the UI.

Just a random thought there, from early in the morning. Apologies if it's not relevant!
Comment by Michael Sevakis (MikeS) - Thursday, 19 July 2007, 18:05 GMT+2
This should be more responsive than Sandisk's UI. I just want some Sansa owners to check it out (JdGordon, you there? :). The constants can be tweaked of course and I really think it's a scheme that has no need for any settings and the time settings for scrolling would be removed (but those are good for joystick-based devices). Noone's complained about the thresholds I chose for the wheel so I think it's possible to adjust this sort of thing to not require them.

Anyone should keep in mind that until decoding is done on the COP, alot of movement in the list will always trigger the boost in the codec thread which causes that sticky movement because the frequent drawing causes the PCM buffer to run low. This patch keeps the scrolling moving along in the list regardless of that.
Comment by Jonathan Gordon (jdgordon) - Friday, 20 July 2007, 04:46 GMT+2
alright, alright, I'll try the patch... :D

yeah, it feels very nice on the sansa, ill see if I can try it on my sisters nano a bit later. It completly breaks the list movement on joystick targets (tested on h300).
did you want to use this or the svn code depending on the target? or was the plan for one code which worked better on the wheel targets?
Comment by Michael Sevakis (MikeS) - Friday, 20 July 2007, 05:03 GMT+2
It won't work on an iPod because the scrollwheel driver doesn't set the correct data. I just blasted it in for a demo and didn't worry about integrating it here but I have done that on my own copy. Someone with a particular iPod available would have to tune the scrollwheel driver to have clicks be the correct angle for comfort.

The bit format for the message data is:
[31:24] = skip count + 1
[23:0] = clicks/uS in fixed 0.24: v = 0xffffffu/dt

Driver is requires a high speed mode where skips will be allowed and v computed.
Slow speed mode never skips since that's fine control...v = 0, even if messages are skipped. Skip count still sent.

...if you were inclined to mess with any iPod scrollwheel driver.
Comment by Michael Sevakis (MikeS) - Saturday, 21 July 2007, 23:38 GMT+2
Ok, I think I'll commit this one with a new #define HAVE_SCROLLWHEEL (defined only for e200 atm). The main problem is that the ideal power curve feels like it should be somewhere between v^1 and v^2. I suppose v^1.5 might be ok but that means a new version of the fsqrt function that can handle large fixed-point integers. :| Not too difficult but more in the binary.

Loading...