• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category User Interface
  • Assigned To No-one
  • Operating System Sansa e200
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by sairon - 2007-05-31
Last edited by jdgordon - 2007-06-04

FS#7242 - Jumping of cursor during slow scrolling

Cursor begins to jump over multiple rows (number of skipped rows is gradually raising) during slow scrolling (~1 row per second) through long lists, i.e. plugins, files in database… Jumping occurs even after short pause (3 seconds) if you’re scrolling in the same direction.
Probably not affected by any settings, successfully reproduced with reseted settings.

Closed by  jdgordon
2007-06-04 13:52
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

appologies for closing early, really was a bug :)

ok, probably needs the setting changed, but just in case, we can leave it open a little longer

I think it shouldn’t keep jumping over multiple rows after some pause (like two seconds), because then it’s a bit contraproductive and confusing.

Project Manager

I agree that it is very frustrating when it starts jumping several lines even when you scroll really slowly. Annoying to say the least.

MikeS commented on 2007-05-31 20:50

I find it occurs after actual scrolling in the list has reached the limit but the cursor is still moving towards the last items in the cursor direction - otherwise I’ve witnessed no problem.

MikeS commented on 2007-06-01 11:30

Now I’m seeing the best recipe. My assessment is that it’s doing everything the opposite of what it should and the slower you move in one direction, the more the cursor jumps. No repeat events are being flagged since it’s moving circularly around the list view and accelerating. No acceleration is present when repeats are flagged.

ok, I leant my sansa to a friend so havnt actualy had a chance to play with this untill just now, imo its fine. I scrolled fast enoughto get it skipping a few, then slowed down to the ~1/s which was reported and it scrolled exactly as expected (to the next/prev item, with no skipping)

I couldnt keep that speed up for long and foun i was going faster quickly (my fingure, not the scrolling), so I still think this isnt a bug…

not sure what Michael is talking about.. It didnt do any funny sipping where it shhuoldnt. (your using modified settings maybe?)

Ok, try following settings:
Acceleration start delay - 2s
Acceleration speed - 2x/2s

Then open some large list and scroll through it really slowly (no accelerating and slowing down, like you’ve tried). Still nothing?

firstly, they are not the default settings, so change them if they are causign your problems…

now, I tried then, but I find it extremely hard to actually use the wheel at such slow speed, so no, I still havnt reproduced this bad bhaviour

Ok, reseted to default:
Start delay - 1s
Speed - 2x/3s
and it still occurs. I’ll take a video tomorrow. I’ve tried various setting, but can’t get rid of this.

MikeS commented on 2007-06-02 20:55

When you move really slowly and see the cursor gradually, increasingly jumping by 2, 3, 4, 5, 6, 7, etc. items…something’s rotten in Denmark. :P I’ve never seen it move by more than one item at a time when repeats are flagged and I’m guessing the multi-item jump is supposed to happen when moving fast, no?

yes, something is very rotten if you are mooving really slowly and its still jumping.. I double checked the code and it should not be possible to do this. (and I still havn’t reproduced it here on the 2 sansas at home)

it shhuold only jump if it gets multiple BUTTON_REPEAT events within global_settings.list_accel_wait * HZ/2 ticks (the 2nd setting, which cannot = 0), so the minimum is 2 every half second, which is reasonable, which is also why I say its not a bug, just you have to adjust the setting…. (also, this wont even begin to take effect untill the start delay…)

MikeS commented on 2007-06-03 04:54

I did change settings and no effect really. It shouldn’t be getting BUTTON_REPEAT if the cursor is wrapping since that’s what stops the wrap, right? 30 ticks is the interval by which a repeat occurs and the movement is a good deal slower than .3s per click. How does one explain that no acceleration ever happens when the wheel is moving fast and repeat events are happening as fast as the button queue can be checked? The fact that cursor wrapping happens correctly is evidence enough of the button driver being honest.

Another thing happening lately is that the scrollwheel goes dead at times and doesn’t wake up until a button is pushed. My first guess with that is there’s a message left in the button queue that isn’t being read and the scrollwheel code only posts if the queue is empty.

I’ll give it a look and see if I notice something.

MikeS commented on 2007-06-03 05:33

Looking at get_action_worker, it seems it decides if a repeat occurs based on whether or not the last action is the same as the previous and not based on the button driver setting the repeat flag. The wheel of course doesn’t post release events to break the repeat and get_action_status gives an erronous repeat. Take a look and see if you agree.

the repeat at the end of get_action_worker is if the action was repeated, not the button, it checks the ACTION_… code, not the BUTTON_.. code, so yeah, it looks more like a problem with the button driver not sending BUTTON_REL events.

just thiking loudly, but the not sending _REL events could (although I doubt it) cause this problem with the wheel locking up, I havnt seen this before, but the action_signalscreenchange() locks up all input untill an _REL event is seen. So, while unlikely, it is possible that the screen is channing aftr a scroll event (I dont tihnk this shhuold ever happen though) and that call is locking things up.
Is button_read_device() called enough that it could trigger a button_rel event on the wheel?

on second thoughts, it might be better to base the repeated on the actions and the tick difference…

Ok, here’s the video of this. You can see I’m using latest version (13539). I’ve reseted settings and then scrolled through plugins list - the cursor started skipping after ‘brickmania’ and then gradually more fields. Notice it stopped when I scrolled faster at the end of the movie. Sorry for my shaking hands and maybe a bit odd quality ;) (7,9 MB MPEG2/AVI)

P.S.: I’ve noticed there’s an update from MikeS but it’s doing the same thing even with that version (13540).

oh! thats alot slower than I was trying, yes, I can copy that and get the wierd behaviour.

this shuold fix it


Available keyboard shortcuts


Task Details

Task Editing