Rockbox

Tasklist

FS#5230 - Keypad HOLD doesn't let go until scrolling is used

Attached to Project: Rockbox
Opened by Mateusz Radwan (mr666) - Monday, 24 April 2006, 20:14 GMT
Last edited by Torne Wuff (torne) - Wednesday, 24 February 2010, 12:21 GMT
Task Type Bugs
Category User Interface
Status Requires testing   Reopened
Assigned To No-one
Operating System iPod 4G Grayscale
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Whenever the HOLD switch is turned off, the hold icon in rockbox disappears, but hold actually doesn't let go. I can't use any keys until scroling is used. Scrolling left or right is the only thing that actually switches off hold. It can be pretty annoying as I use HOLD a lot.
This task depends upon

Comment by Paul Louden (darkkone) - Tuesday, 25 April 2006, 20:20 GMT
Just to note, this bug has been present for *months*. As best I can tell it was created with the fix that kept scroll events from stacking up. So, now you can't accidentally scroll too far and adjust the volume all the way up to +6 because it's a bit laggy, but you get this instead. :)
Comment by Steven (SorcererSteven) - Monday, 05 March 2007, 05:49 GMT
I have a Nano with the same bug... I know it's not exactly severe, but it's extremely annoying.
Hopefully this will become fixed some point soon ^_^
Comment by Rick (bospaadje) - Thursday, 14 June 2007, 07:41 GMT
This bug is also present on my nano, it's pretty annoying.. I hope someone will look into this.
Comment by Will Robertson (aliask) - Sunday, 29 July 2007, 23:20 GMT
Could somebody with an iPod please do a quick check with a current build and report back on whether this bug is still present?
Comment by Steven (SorcererSteven) - Monday, 30 July 2007, 03:28 GMT
Yup, the bug's still present on the current build (as of this post, anyways).
Comment by Eliot (Yskyflyer) - Saturday, 23 August 2008, 04:05 GMT
I can reconfirm this bug still exists (iPod Video 60 Gig) r18335 clean install (and earlier r18205)
Easily reproducible in file (tree) browser.

Possibly related problem.

Plug-ins that require you to use the hold to get to the menu frequently show same symptoms (“Whenever the HOLD switch is turned off, the hold icon in rockbox disappears, but hold actually doesn't let go.”) but scrolling doesn’t fix it. Controls are unresponsive. Sometimes after using the hold again or pressing random buttons it will resume function, other times I have to reset (select + menu). It doesn’t always happen but happens a lot in RockBoy especially when you go back and forth to the menu and use a buggy game from PDroms. I've also noticed it in RockDoom r18205 after I've been playing a while.

Good luck with Version 3.0 Thanks everyone for the wonderful firmware.
Comment by Gareth (Mystic_kitsune) - Thursday, 04 September 2008, 23:56 GMT
I would like to reconfirm that this bug is present in sansa e200 series DAPs as well...
Comment by Mark Sikora (Flarkis) - Thursday, 11 September 2008, 16:37 GMT
Problem still present on both iPod 5.5G and 4G photo with current build

In reference to Eliot using the hold button to access the menu in rockboy is extremely unreliable and often takes more than 10 tries to successfully open the menu
Comment by Boris Gjenero (dreamlayers) - Friday, 03 April 2009, 05:10 GMT
This is very easy to reproduce in the file browser on my 5G 30GB iPod. It happens almost half the time.

What I see is a problem in button-clickwheel.c. Interrupts are occurring, but (status & 0x800000ff) != 0x8000001a. I found this by commenting out the backlight_on() statements in button.c and button-clickwheel.c and strategically adding new backlight_on() statements.
Comment by Boris Gjenero (dreamlayers) - Wednesday, 08 April 2009, 01:29 GMT
Here's a patch which seems to fix the problem on my 5G 30GB iPod. It should also be test be tested on 4G and Nano iPods.

To reproduce the problem with SVN: In the file browser, turn hold hold on and then off. Press the centre (select) button without touching the wheel. About half the time, the first few presses are ignored.
With this patch, I am unable to reproduce the problem.

BTW. When this problem happens, values read from 0x7000c140 seem like garbage with many 0x55, 0xAA, 0x00 and 0xFF bytes.
Comment by Yoshihisa Uchida (Uchida) - Wednesday, 08 April 2009, 12:43 GMT
For iPod 5G (60GB), I confirmed the firmware that applyed the patch worked well.

But iPod Photo does not work.
iPod Photo did not work though the my patch in  FS#10098  was applyed.

For iPod Photo:
HOLD on
0x7000c100: 600a1f00
0x7000c104: 41000000
0x7000c140: 00000000

HOLD off
0x7000c100: 600a1f00
0x7000c104: 61001e00
0x7000c140: 55555555, aaaaaaaa, ffffffff (etc)
Comment by Boris Gjenero (dreamlayers) - Wednesday, 08 April 2009, 14:21 GMT
Does this patch fix the problem on iPod Photo?

I don't like putting udelay(2000) in an interrupt handler. Any comments on that?
Comment by Yoshihisa Uchida (Uchida) - Thursday, 09 April 2009, 12:12 GMT
When the new patch was used, iPod Photo and iPod 5G worked fine. thanks!!
Comment by Boris Gjenero (dreamlayers) - Friday, 10 April 2009, 03:59 GMT
I had some problems with ipod_4g_button_int-variant2.patch on my 5G iPod. Sometimes the clickwheel or buttons didn't respond until I pressed a different button or scrolled in the opposite direction. Here's an updated patch which doesn't seem to have those problems.
Comment by Yoshihisa Uchida (Uchida) - Friday, 10 April 2009, 12:42 GMT
iPod Photo works fine when new patch applied.

But for iPod 5G, the following problem found.

The HOLD switch is turned on, and the screen fades out.
After it waits for a while, the HOLD switch is turned off.
Then, the HOLD icon is sometimes displayed on the screen.

For original Rockbox firmware (r20674), r20674 + ipod_4g_button_int-variant2.patch such the problem did not occur.
Comment by Boris Gjenero (dreamlayers) - Friday, 10 April 2009, 15:46 GMT
When the HOLD icon is displayed after the hold switch is turned off, do buttons and the wheel work? If they work, I think this is due to an issue with  FS#9890  (5G iPod LCD sleep): if lcd_update() is called while the LCD is being initialized, that update will be ignored. The fix is in bcm_lcd_wakeup_improved.patch there. Alternatively, you can disable LCD sleep via LCD options and see if the problem still occurs.
Comment by Yoshihisa Uchida (Uchida) - Saturday, 11 April 2009, 12:52 GMT
When iPod 5G worked fine by using
r20684+ipod_4g_button_int-variant2_v2.patch+ bcm_lcd_wakeup_improved.patch, the display is normal.
Both iPod Photo and iPod5G works fine.
thanks!!

P.S.
bcm_lcd_wakeup_improved.patch cannot be applyed to the source of the latest version. You should update it according to the source of the latest version.

Comment by Torne Wuff (torne) - Friday, 22 May 2009, 12:09 GMT
I had the same problem with the hold icon, but the fix for  FS#9890  has corrected it.

Is this awaiting more testing? What players does it still need to be tested on? It definitely fixes my 5.5G :)
Comment by Boris Gjenero (dreamlayers) - Friday, 22 May 2009, 14:25 GMT
I don't think anyone has tested this on Nano or Mini 1G.

I'm also wondering if it is okay to have udelay(2000) in an interrupt handler. I am hoping it is okay because it doesn't run often. It is only in the code path which is executed when this problem occurs, not in the normal code path which successfully reports key and wheel events.
Comment by Jonathan Gordon (jdgordon) - Thursday, 23 July 2009, 01:21 GMT
very simple fix.. linuxstb pointed out that the ipodlinux code reenables the opto when hold is disabled.. so added that and it seems to work :)
Comment by Torne Wuff (torne) - Friday, 24 July 2009, 09:38 GMT
The trivial patch posted by jdgordon also fixes the issue for my 5.5G, as far as i can tell (I did remove the other patch first).
Comment by Trent McPheron (TwilightInZero) - Tuesday, 28 July 2009, 22:48 GMT
I can also confirm that the new one-change patch works for me on my 5G iPod.
Comment by Torne Wuff (torne) - Wednesday, 24 February 2010, 12:22 GMT
It looks like the fix which was committed hasn't actually fixed the problem for Mini 2G and possibly other models, see http://forums.rockbox.org/index.php?topic=23997
Comment by Andrew Engelbrecht (sudoman) - Tuesday, 28 September 2010, 17:23 GMT
I also have this problem on my 5.5G ipod with rb 3.5. The ipod remains unresponsive until about 6 clicks of a button or scrolling is performed. If scrolling is the first action performed, then there is a ~0.5-1 second delay.

I don't have my 3G ipod with me right now, but I do recall a similar issue with that one as well. I couldn't rewind a track in the WPS after releasing hold unless I waited a couple of seconds before holding the rewind button. If I was too speedy and pressed the button right away, and then continued to hold down the button, then released for only a short period of time, a second or third, or fourth attempt like this would fail. I also remember occasionally not being able to scroll until tapping the center button first, but that may not have been associated with the hold switch.
Comment by Andrew Engelbrecht (sudoman) - Tuesday, 28 September 2010, 17:30 GMT
oops! I meant to say that I'm using rb 3.6 on both the 5.5G and 3G ipods.
Comment by Andrew Engelbrecht (sudoman) - Monday, 04 October 2010, 18:24 GMT
I tried the current build (r28207) and am still having this problem. If it helps, my 5.5G is hw rev. 0x000B0011. I think that the issue I described about the 3G ipod above is different in nature from this bug.
Comment by Andrew Engelbrecht (sudoman) - Monday, 04 October 2010, 21:41 GMT
using ipod_4g_button_int-variant2-v2.patch on rockbox 3.6 fixed the issue for my 5.5G ipod. I manually copied in the code, because the patch was originally for an older version of rb.
Comment by Torne Wuff (torne) - Tuesday, 05 October 2010, 09:39 GMT
I don't know that we want to commit that patch, unfortunately; it sleeps in an interrupt handler which is a bad idea...

It's odd that only one person would report having the problem...
Comment by Andrew Engelbrecht (sudoman) - Tuesday, 05 October 2010, 20:03 GMT
Who knows why I was having this problem. I bought this ipod from someone on amazon. It looks like it's been opened, so maybe it's been refurbished. *shrug*

I'm not the only one who found a variant of "ipod_4g_button_int-variant2-v2.patch" useful. mg0rb did as well. His post is here in the forums: http://forums.rockbox.org/index.php?topic=23997.0
Comment by Andrew Engelbrecht (sudoman) - Wednesday, 06 October 2010, 16:47 GMT
should I try a version of the ipod_4g_button_int-variant2-v2.patch without udelay?
Comment by Torne Wuff (torne) - Wednesday, 06 October 2010, 16:56 GMT
You could, but the udelay is probably what's making it work properly.

We know that that patch helped the button problem, what I meant is that you are the only person having that problem on ipodvideo; several people have reported it's not fixed on mini and it's expected that the other patch will work there, but you are the only person with any *other* model having an issue. The video is the most common ipod for rockbox and a lot of the developers have one, so it's rare that only one person reports a problem on it; some of the other models are rarely used and it's more likely there :)
Comment by Hendrik Hoeth (hoeth) - Friday, 19 November 2010, 14:06 GMT
I believe I observe a variant of this bug with Rockbox 3.7 on an ipod nano 2g. Keys stay locked unless I press select first.
Comment by Maxime (crowd345) - Sunday, 23 January 2011, 15:24 GMT
I would like to confess that this bug is still present with new RB 3.7.1 at my Ipod nano 1gb 1 gen.

100% times after HOLD button is used buttons (prev, next, play/pause, select) didn't respond for 2-6 clicks and after it works just fine.
If after unlock scrolling is used then all buttons respond normally. I can reproduce it any menu, directory list or WPS.

"I believe I observe a variant of this bug with Rockbox 3.7 on an ipod nano 2g. Keys stay locked unless I press select first."
This definitely didn't work for me.

I'm using Ubuntu and fail to install proper software to compile source code with ipodfix.diff.
.sh script getting stocked while installing GCC. Anyway if this possible i would like to ask some advanced rockbox user to send me proper version RB with this patch (no? ok :). Or wait couple weeks and i'll try to get it work at my PC.

P.S. Anyway i feel such a relieve not using iTunes. Thank you for all that work!
Comment by Kyle Kamperschroer (Phalangees) - Saturday, 07 May 2011, 03:33 GMT
I'm not sure if anyone is still watching this, but I was unable to reproduce this bug on both iPod Nano 1g and Sansa e200 simulator builds of r29827-110507.
Comment by Torne Wuff (torne) - Saturday, 07 May 2011, 12:51 GMT
You wouldn't be able to reproduce this on simulator builds; the problem is with the device driver that talks to the clickwheel, which doesn't exist on the sim.
Comment by Maxime (crowd345) - Saturday, 07 May 2011, 18:55 GMT
I uploaded 3.8.1 stable release today to my Ipod Nano 1g to test it and problem is still here. But good news is that I'm so used to it now so it's starts looking like feature :)

P.S. I installed GCC in January (take a look at my last post. Thx again Torne!) but it looks like .diff files that placed at this topic can't be automagically applied to source..
Comment by Slikk (Slikk) - Wednesday, 17 August 2011, 16:09 GMT
I am also seeing this issue on an iPod 5G (iPod Video 30GB). After hold is turned off, next/previous/menu/select/play don't respond for 5-6 presses. Using the scroll wheel or pressing any button multiple times will fix it. I have tried with Rockbox 3.9 and r30324 - no difference.
Comment by Maxime (crowd345) - Sunday, 16 October 2011, 15:13 GMT
With my Ipod nano 1st generation i tried version 3.9.1 today and the bug is still here.
Also compiled source code from revision 21912 with Jonathan's Gordon "ipodfix.diff" (thank you Jonathan!) but for me nothing actually changed.
Comment by Andrew Engelbrecht (sudoman) - Sunday, 16 October 2011, 16:50 GMT
This is still a problem with my ipod 5.5G. The ipod_4g_button_int-variant2-v2.patch worked for all the releases I've tried, except for 3.9.1.
Maxime, the ipodfix.diff is already incorporated in the code.
Comment by Tiago Medeiros (madcat1990) - Thursday, 13 June 2013, 20:14 GMT
Still a problem with my mini2G with latest dev build

Loading...