Rockbox

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

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#11696 - scrollwheel not responding on e200 v1

Attached to Project: Rockbox
Opened by Wolfgang Dilg (rasferret) - Friday, 22 October 2010, 08:25 GMT+2
Last edited by Magnus Holmgren (learman) - Sunday, 21 November 2010, 16:28 GMT+2
Task Type Bugs
Category User Interface
Status Closed
Assigned To No-one
Player Type Sansa e200
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

svn = r28311 and prior

This bug seems to be related to  FS#10097 

1. start playing a music title
2. go into the file browser and select a directory where you can scroll up and down with the scrollwheel
3. press play to go back to the playing title
4. use the scroll wheel (volume up/down)
5. let the title finish and the player fall back to the file browser

-> The scrollwheel will not respond until a button is pressed.

This bug is very old. I can't remember when I first noticed this behaviour.


This task depends upon

Closed by  Magnus Holmgren (learman)
Sunday, 21 November 2010, 16:28 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  Fixed in r28584 (and r28631 on the 3.7 branch).
Comment by Magnus Holmgren (learman) - Thursday, 04 November 2010, 21:19 GMT+2
This is a quick patch that seems to fix the problem for me (I have a Fuze V2, but see similar problems). I haven't tested it much though.
   button.patch (0.8 KiB) 
 firmware/drivers/button.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Comment by Johannes Linke (Jaykay) - Thursday, 04 November 2010, 21:50 GMT+2
could be related to FS#8816, FS#7332 and a similar problem was fixed here  FS#10097 
Comment by Michael Sparmann (TheSeven) - Thursday, 04 November 2010, 23:24 GMT+2
I'm seeing similar behavior occasionally on an iPod Nano 2G after unplugging USB. The clickwheel doesn't work until a button is pressed. So this seems to be a target-independent problem that occurs in lots of different conditions, but not always consistently.
Comment by Magnus Holmgren (learman) - Saturday, 06 November 2010, 11:12 GMT+2
Turns out the patch didn't fix the reported problem, but a similar problem I've been seeing. This patch should fix both. I suspect the action.c change is enough to fix both bugs, but the button.c change seems like the right thing to do.
   button_v2.patch (1.4 KiB) 
 firmware/drivers/button.c |    6 +++---
 apps/action.c             |    7 ++++++-
 2 files changed, 9 insertions(+), 4 deletions(-)

Loading...