Rockbox

  • Status New   Reopened
  • Percent Complete
    0%
  • Task Type Bugs
  • Category User Interface
  • Assigned To No-one
  • Operating System All players
  • 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 rasher - 2009-06-21
Last edited by kugel. - 2011-10-25

FS#10362 - Flickering backlight when removing hold with backlight fading

After releasing hold after several minutes of playback with hold enabled, the backlight flickers on and off, if the following settings are enabled:

Backlight on hold: off
Backlight fade in: on
Backlight fade out: on
Caption backlight: on

My theory is that fade-in/out events from the caption backlight somehow get queued up, and happen once hold is released.

Happened as recently as today, with r21438. Reports in IRC said it appeared somewhere between 3.0 and 3.1.

dz commented on 2009-07-06 00:55

indeed, caption backlight on/off events (regardless of fade settings) are stacking up in backlight_queue while the backlight is forced off by the hold switch by setting timeout to -1. I can’t quite manage to wrap my head around this code right now in order to fix it, though.

Why do you get this idea? I’m fairly sure I have seen this without caption backlight also (because I never have caption backlight on).

Strange similar prob with plugins like Doom (on a Fuze v1). The turnaround I’ve find is to turning “Backlight on hold” to “on”. (But it’s very ennoying to have the Backlight ON when you are in “Hold”.

Good luck for debug devs! ;)

That’s a different bug I think.

Ok, I create a new thread. ;)

there is a post in the mailinglist about this

i think it is since the fading for units without hardwarefading . I noticed it myself with the h300 but also saw it at my e200 (which I have not that long).

the last post in the mailing list sounds exactly like what I would think after seeing it myself. The longer you have the backlight off with hold the longer it flickers after releasing hold. Don’t know if that is possible.

This is caused by multiple SYS_TIMEOUT events being queued while in hold mode (one will be queued for each caption backlight or button press).

This one-line patch appears to fix it (which I’ll commit if there are no complaints)

Looks ok, but maybe rather like this?

if (queue_is_empty(&backlight_queue)

  queue_post();

Just an idea, it may or may not work better. Nice catch anyway!

I just went with the same way backlight_on() works. I’ll try both and see which is best.

EDIT: That works too and looks neater. I’ll go with kugel’s suggestion.

Either this was never fixed in the first place, or it’s been re-introduced, because it just happened to me again.

did you try the posted patch?

edit: hmm, ok, that change is in svn… perhaps duplicate it in the buttonlight_off() (fixing the obvious value to make sense thou)

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing