Rockbox

Tasklist

FS#5296 - Disable WPS rendering when backlight is off

Attached to Project: Rockbox
Opened by Anonymous Submitter - Friday, 05 May 2006, 21:23 GMT
Last edited by Marc Guay (Marc_Guay) - Wednesday, 09 April 2008, 00:13 GMT
Task Type Feature Requests
Category Themes
Status Closed
Assigned To No-one
Operating System iPod 5G
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Having the WPS to turn off after a set time with playback and no user interference should increase battery life, with a keypress activating the WPS or directly completing an action
This task depends upon

Closed by  Bj√∂rn Stenberg (zagor)
Wednesday, 09 April 2008, 00:13 GMT
Reason for closing:  Duplicate
Additional comments about closing:  Closing all feature requests.
Comment by Mike Holden (mikeholden) - Saturday, 06 May 2006, 09:25 GMT
For targets such as the iRiver H300 series, where the display is totally invisible when the backlight goes off, all "animation" in the WPS should be halted when the backlight goes off. This would include scrolling, alternating lines and peak meter. However relatively static data such as track information etc should be kept up to date, so that the screen is correct when the user presses a key to activate the backlight again.
Comment by Mark Bright (Redbreva) - Wednesday, 10 May 2006, 07:50 GMT
If i understand the comments made on IRC correctly, the LCD screen being updated takes *almost* no power, it's the backlight that eats power. So switching on animations etc would have almost no impact on battery life
Comment by Linus Nielsen Feltzing (linusnielsen) - Wednesday, 10 May 2006, 08:02 GMT
While updating the LCD draws very little power, it still steals CPU time from the codec. So avoiding screen updates could still save some battery, since the codec wouldn't have to boost the CPU as often.
Comment by Michael Sevakis (MikeS) - Wednesday, 09 May 2007, 01:47 GMT
Yes, there is a measureable boost benifit on x5 to not rendering to the lcd device itself...so we just put the chip in display off (sometimes standby mode too) during backlight outage...why not? Having the app doing the drawing to lcd_frambuffer deciding not to draw if the display is off is likely the best way to go with this kind of "short circuit" and not add it to the driver layer. I know latter wasn't suggested here but it's just my thoughts on what to do - if anyone gives a rat's @$$! :P

Loading...