Rockbox Technical Forums
Support and General Use => Hardware => Topic started by: mg0rb on February 22, 2010, 12:06:38 AM
-
Hello, everybody,
I have ipod mini 2ND gen 6G with rockbox 3.5. I see a problem similar to FS#5230 (Keypad HOLD doesn't let go until scrolling is used) , i.e. after the player goes off hold buttons on scroll wheel remain unresponsive until you scroll or press a button several times (usually 6 or 7). This issue persists also in 3.4 and current builds.
With OF everything is OK.
Looks like patches mentioned in http://www.rockbox.org/tracker/task/5230 were removed in favor of the latest one (ipodfix.diff) and it does not help with ipod mini.
Does anybody see the same problem ?
Thank you
-
applying ipod_4g_button_int-variant2.patch from FS#5230 solved this issue for me. thanks.
-
I have reopened FS#5230 for further investigation.
-
I have reopened FS#5230 for further investigation.
I'm having this problem with with rb 3.6 on my ipod 5.5G. I've posted details in the tracker.
-
applying ipod_4g_button_int-variant2.patch from FS#5230 solved this issue for me. thanks.
the patch ipod_4g_button_int-variant2-v2.patch worked for me my 5.5G ipod. : )
Edit: I used a newer patch than mg0rb.
-
I'm having the same problem as the OP, except with an ipod 5G (ipodvideo 30gb). Tried rockbox 3.9 and the latest build, no difference. Unfortunately I'm not much of a developer so compiling from source with some of the older patches is probably out of the question, and apparently they use udelay which is bad for some reason anyways?
-
For what it's worth, the issue still exists on the latest version of Rockbox using a fourth-generation iPod.
ipod_4g_button_int-variant2-v2.patch from FS#5230 (https://www.rockbox.org/tracker/5230?getfile=19171) seems to have solved it for me as well.
-
Can I ask why this patch was never accepted? The official Rockbox version feels basically broken on devices like the (B&W) fourth-generation iPod and other affected devices unless you never touch the HOLD slider. It's not an issue for me personally, because I'm compiling my own version with the patch applied (which doesn't appear to have given me any problems in a month of usage), but it's not a good experience for regular users. I stopped using Rockbox at one point in the past just because of this issue (before i knew how to fix it).
-
I can't say for sure but the FS attached to it sure is all over the place.
Not to mention that patch no longer matches the current file and it looks like the click
wheel might have already been fixed can you attach 'your' patch to this thread?
I don't have this device to test so I can't do too much with it but someone else may..
-
I can't say for sure but the FS attached to it sure is all over the place.
Not to mention that patch no longer matches the current file and it looks like the click
wheel might have already been fixed can you attach 'your' patch to this thread?
I don't have this device to test so I can't do too much with it but someone else may..
So, here's the same patch I linked to before, but with updated line numbers so it applies to the latest dev version hosted on GitHub (credit continues to go to Boris Gjenero (https://www.rockbox.org/tracker/task/5230#comment29637)).
I can say with some certainty about Rockbox (either 3.14 or dev) running on the iPod 4G (with grayscale LCD) that
– without the patch, the buttons (almost always) continue to exhibit the faulty behavior described in FS#5230 (https://www.rockbox.org/tracker/task/5230), even today
- applying this patch will completely fix the issue on this model
- I could not detect any (obvious) negative side effects in a month of fairly heavy usage
I think, at the very least, the patch should probably be included for this very model (using a preprocessor directive?). Although it sounds like more models are affected and would benefit from the patch.
-
By the way, a udelay of 1000 instead of 2000, i.e. a 1 millisecond delay, seems to suffice in my experience to get rid of the bug (only tested on iPod 4Gs).
I know Torne Wuff mentions sleeping in an interrupt handler as a bad idea (https://www.rockbox.org/tracker/task/5230#comment37177) in the comments to FS#5230 (https://www.rockbox.org/tracker/task/5230), but as far as I can tell, udelay isn't technically like sleeping but instead busy waits and so is appropriate in this context? It is also already used in the same file (https://github.com/Rockbox/rockbox/blob/100f4338deea5239423a0b8974784939d520385c/firmware/target/arm/ipod/button-clickwheel.c#L309), albeit with a shorter time period... (in the comments it says that in the ipodlinux source it used to delay for 250 microseconds instead of the 50 that are used now). Wouldn't the same objection apply to that line then, or am I missing something?
-
By sleeping in interrupt handler he meant busylooping. udelay(2000) is 2 ms of not doing any useful stuff. I can easily understand the objections for this patch. From the other hand https://www.rockbox.org/tracker/task/5230#comment30395 (https://www.rockbox.org/tracker/task/5230#comment30395) says udelay is not in hot codepath. ifdefing is an option but ugly one.
-
By sleeping in interrupt handler he meant busylooping. udelay(2000) is 2 ms of not doing any useful stuff. I can easily understand the objections for this patch. From the other hand https://www.rockbox.org/tracker/task/5230#comment30395 (https://www.rockbox.org/tracker/task/5230#comment30395) says udelay is not in hot codepath. ifdefing is an option but ugly one.
I would understand the objection if this didn't fix a long-standing, annoying and obvious bug (admittedly on devices used by fewer and fewer people, probably). By using ifdef to target only the actually affected devices, it could be assured that there's no chance of this (extremely small and localized) patch making anything worse on devices other than the ones suffering from the problem – although it seems like the patch may never be in the codepath for unaffected devices anyway. On the affected ones, it seems to me the tradeoff would be very much worth it to get rid of the problem of disabling HOLD and then (more often than not) having to repeatedly press a button (or scroll) before any input action is recognized. Since the patch only affects the scenario in which the device already behaves in an extremely unsatisfactory way, I'm not sure how the unnoticeable delay is making anything perceptibly worse, unless there is some deeper underlying (side-)effect I'm not aware of.
From personal experience, I'd say the experience between the official build and the patched one is night and day, and I, myself, would never want to use an unpatched version on my iPod 4G ever again (except for testing purposes).
To me, the question is whether the patch is bad enough that it's preferable to leave the existing bug in place instead? From my perspective as a user, this is easily answered. It's the choice between a system that (viewed as a black box) seems to work exactly as intended and one that seems partly broken.
-
By sleeping in interrupt handler he meant busylooping. udelay(2000) is 2 ms of not doing any useful stuff. I can easily understand the objections for this patch. From the other hand https://www.rockbox.org/tracker/task/5230#comment30395 (https://www.rockbox.org/tracker/task/5230#comment30395) says udelay is not in hot codepath. ifdefing is an option but ugly one.
Not familiar with the iPods, but according to the wiki, the lowest byte on the clickwheel is 0x1a when unlocked, and assuming interrupts aren't getting generated when the device is locked (i hope??), it should be pretty safe. You'd only trigger the wait when you're in some weird state not documented on the wiki, which I guess is whatever the delay is supposed to correct.
https://www.rockbox.org/wiki/PortalPlayer502x#I2C_Controller
-
I also still have this problem on my ipod 5.5 running RB 3.14.
This is a 13 year old bug!! :p
-
I also still have this problem on my ipod 5.5 running RB 3.14.
This is a 13 year old bug!! :p
Yeah – bit of a shame that the official version has this bug. I haven't experienced any negative side effects applying the aforementioned patch on my iPod 4G though, after a year of regular usage. Solves the issue completely for me. :)