LCD Refresh Issue During Initial Battery Charging (During The Boot time)

by Kal » Tue, 14 Dec 2010 02:13:39 GMT

Sponsored Links
 I am trying to display the carrier logo animation along with battery
charging animation. During this animation, i am also providing the
facility of key events, which can allow the battery charging to an
acceptable level, by turning off the backlight and LCD.

Whenever we press the power button (Short Key Press) , i am turning
off the both LCD and the backlight. The turning off the LCD is done by
setting the "mem" string value to /sys/power/state device file.

 Again when we press back either the power key or any other keys, we
are turning on the LCD as well as backlight. The turning on the LCD is
done by setting the "on" string value to /sys/power/state device file.

 Linux power management uses the power management concept called
"Early Suspend" and "Late Resume". We don't have any issue with "Early
Suspend", but we have issue with "Late Resume".

Once we receive the Keypad event, we start drawing the animation
again. By the time we get the animation on the screen, the battery
backlight image has been drawn and LCD is still not completely
initialized (this is my understanding).  This is causing some junk
pixels shown on the screen.

I am trying to find better ways of turning off the LCD and turning on
again, which will take minimal time. I found the following patch,
which they were trying to minimize the wakeup time.

But i am not sure, whether this patch is already in the main line
kernel or not. If not any other better approaches for this.

Best Regards,
Srinivas Kalbhavi


Re: LCD Refresh Issue During Initial Battery Charging (During The Boot time)

by Kal » Tue, 14 Dec 2010 04:01:53 GMT

 Instead of LCD refresh, i would say it is LCD display update issue.
Usually LCD refresh term used for refreshing the internal GRAM of LCD

Best Regards,
Srinivas Kalbhavi


Sponsored Links

Other Threads

1. Home screen customization WRT certification


If I replace the generic Home screen with a custom-built one such as and ship it on the device we are building,
what alterations or omissions would make the device fail the upcoming
Android Certification test?

Thanks in advance,


2. libhardware_legacy and flashlight.c

I was trying to fill in the flashlight.c HAL layer for a port and
tried to follow the way that the it loaded (ie but that does not work since it looks like the
android_os_Hardware.cpp statically links to the
get_flashlight_enabled, enable_camera_flash functions. I saw one of
the older posts in this group stating that libhardware_legacy would be
ideally empty, I was wondering what the plans for the flashlight
interface were and should those who are porting it should be trying to
create dynamically loaded modules or should they just be modifying the
existing flashlight.c under libhardware_legacy?

3. Performance: pre-instantiate activities on app launch? Good practice or not?

4. Some question about OrientationListener and the way of sensor( sensorlistener, sensormanager..... ) init

5. App Idea: Very interesting, unique, and information efficient text-entry method -- (no keyboard(not even on screen KB))

6. Paid upgrades discussion

7. hi,anybody know the OMTP Application Security Framework and android compliance