dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Request for comments on Ipod scroll wheel acceleration

Request for comments on Ipod scroll wheel acceleration

From: <>
Date: Thu, 08 Jun 2006 21:51:17 -0400

Request for comments on Ipod scroll wheel acceleration

Scope: Ipod Video targets, possibly other Ipod targets.

Chris Russell offers a patch,
  , to handle accelerated scrolling for the Ipod.

In this document, I propose a different method for handling
accelerated scrolling. This is not a matter of Russell's code being
bad -- it's pretty clean --, it's as a matter of how it interacts with
the existing code base.

Russell's initial patch establishes two new virtual keys, one each for
accelerate scrolling backward and forward.

His revised patch establishes eight, four each for accelerated forward
and accelerated backward scrolling.

Because these new keys are not "or'ed" together with the existing
BUTTON_SCROLL_FWD or BUTTON_SCROLL_BACK keys, these key presses are
effectively "invisible" to any existing code that processes keys,
until and unless the existing code is changed to recognize the new keys.

If an accel key is generated, to unmodified code it's as if no key had
been pressed.

This is particularly burdensome for plugins: either plugin authors,
who themselves may not own an ipod, must add ipod-specific
key-handling code, or risk the plugin "not seeing" the standard key
when an accel key is generated.

A better alternative would be to "or" the acceleration key together
with the standard BUTTON_SCROLL_FWD/BACK key.

However, since much of the existing code base switches on the actual
button value, without masking off the bit of interest, i.e.,

code-base is:
switch( button ) {

code-base is not:
if( button & BUTTON_SCROLL_FWD ) {

this strategy also "breaks" existing code.

To allow both acceleration and backward compatibility of existing
code, I propose that, as currently, only BUTTON_SCROLL_FWD and
BUTTON_SCROLL_BACK be generated. (These map to the standard
BUTTON_DOWN and BUTTON_UP respectively.)

However, for ipods only, I suggest adding the function
enum wheel_accel get_ipod_scroll_wheel_acceleration( void ) ;
wheel_accel is
enum { NORMAL, FAST, FASTER, FASTEST } wheel_accel ;
declaring it in button.h and defining it in button.c

Existing code would continue to function normally, but could be
modified (for ipod only) to call get_ipod_scroll_wheel_acceleration()
where desired. Plugins or code unconcerned with acceleration would
continue to function as expected, without modification.

This abstract interface also allows acceleration to be implemented in
a number of different ways.

I've currently implemented three forms:
*acceleration based on "winding" the wheel, that is the number of
times the wheel has been "rotated" 360 degrees without the user's
finger lifting or reversing its direction;

* acceleration based on in which of four sectors the finger initially
touches the wheel (0-89 degrees is normal, 90-179 is FASTER, etc.);

* acceleration based on the actual finger speed (delta of finger position)

Potentially, any of these forms could selected by user preferences (or
by patching), while keeping the same public API,

(Another alternative would be for client code to examine the "data"
field in the button queue, which records the absolute wheel position
and the delta, if any, since the previous button). However, this puts
the burden on client code outside of button.c to understand these
values, inviting inconsistency as different code sites may evaluate
these raw values differently. It also requires multiple code sites to
find the /previous/ queue element, wrapping around if necessary. And
it doesn't allow for different GUI methods to establish when, and to
what extent, acceleration is in effect. Using the abstraction of a
public function makes everything clearer, more consistent, and easier
on client code.)

Your comments are requested.
Received on 2006-06-09

Page template was last modified "Mon Jun 14 16:30:06 2021" The Rockbox Crew -- Privacy Policy