Rockbox

It seems the udelay interferes with audio, just get rid of it...

this significantly slows down my sansa when playing audio

e200_lcd2.patch does not affect my e250 in any way in terms of performance (it was quite sluggish before). The first patch does slow the system down when in the low power state.

Synced to SVN and fixed a bug where it would revert to default brightness when brightness was set to below 3. Also reduced code size.

Synced to SVN.

Chrisjs, who maintains a cutom build for Sansa e200 series, reported a problem with compiling this patch.
Any idea what might be the reason?

I am aware of the cause of it not working - It was out of sync and I didn't look through the code carefully enough, and mistakingly skipped a few hunks

Sync'd to SVN

This is a different way of donig the same thing. atm its not configurable and doesnt disable the lcd when its fading out (dont know why, uncommenting the 2 // comment lines will cause the sansa to crash

final version. this seems to work fine, even if the lcd sleep option is set to always.
does this need to be configurable? I dont think so.

Big problem here: you cannot call the i2c driver from a tick task. It calls mutex functions and yields. Interrupts can only use queue_post and call code specifically intended for that context.

I also saw some traffic on IRC about this and there seemed to be confusion about lcd_sleep/enable? lcd_enable(false) only shuts down visible display operations, not the chip itself. lcd_sleep_does the full move to standby. lcd_enable(true) of course brings it back from any level of power down. Those functions yield and aren't really multithread safe (yet).

here is another try which uses the backlight thread to do it all properly and thread-safely....
it doesnt work though :p
I'm hoping another pair of eyes can figure it out.
currently it only dims once :(

Sync please, I think recent SVN changes due to the c200 port broke this patch.

Synced it myself.

this patch no longer compiles against the current source

Pretty hard to sync, I'll have a look another day, when I've got time.

Anyway, I did talk to the devs, we need to follow jdgordons approach (for thread-safety, proper coding etc), and we need to make it configurable in order to have a chance to get this committed. I hope someone will help us to do so.

Can't someone resync please?

Resynced against r16053M-080111. Works fine on my e260 so far.
What exactly do we need to get this committed? Maybe the fade should be done in _backlight_on() and _backlight_off() instead of introducing __backlight_dim()? That way it would be compatible to the HAVE_BACKLIGHT_PWM_FADING stuff and backlight.c could be left unchanged. At least, further resyncs would be easier then.
Any suggestions?

We need to do exactly what JdGorden began. Thread-safety. Your suggestion doesn't sound too bad. However, PWM fading isn't proper. The way it acutally works, by settings the backlight brighness down in a intervall is much better, since it's more accurate. I also think it looks better.

Thanx for your work on resyncing this patch Martin. Works fine on my e280

Kugel, of course no PWM on the Sansa. I wasn't aware, that jdgordon did something completely different. Simply picked the last patch.

Anyway, I now managed to get jdgordon's approach running, too. It does the fading in the backlight_thread() itself instead of a ticktask, which was considered to be bad. It works quite well, however, I don't like it very much. While fading, the backlight_thread() feeds up itself with tons of BACKLIGHT_FADE_* events. Was it supposed to work this way, or should we rather use a timer to feed the queue?

Thanks a lot for your work, Martin.

I did a little rework, trying to gain the best of the 2 different solutions above.

Fading is now controlled by the new variable backlight_fade_state. It is set to 1 or 2 in _backlight_on() or _backlight_off(), indicating that either a fade-up or fade-down is desired. If so, backlight_tick() starts sending BACKLIGHT_FADE events to the backlight_thread() at a rate of HZ/25. Depending on the value of backlight_fade_state, the backlight_thread() then calls either __backlight_fade_up() or __backlight_fade_down() of the target. When fading is fished, backlight_fade_state is set back to 0, and backlight_tick() stops sending fade events.

Also fixed a bug when brightness was set to 1.

It's been tested quite intensely. If further work is needed to get it committed, someone may tell me, please.

Synchronised against 17138.

Fixed a bug where the screen sometimes turned white in mpegplayer.

The patch works well, how about committing (generally, not necessarily before 3.0)?