Soft-key backlights do not respect auto-brightness and do not time-out

[jeffsf]

Soft-key backlights do not time-out

If a user has auto-brightness on, the soft-key brightness does not seem to follow the ROM or user settings

[Fluidification]

I can confirm

[jeffsf]

Looks like the Android world is doing reasonable things, if you consider the logic in that world reasonable.

Looking now at liblights/lights.c which seems to suggest that

root@android:/sys/class/misc/melfas_touchkey # echo 1 > brightness
root@android:/sys/class/misc/melfas_touchkey # echo 2 > brightness

is all you can do. At least "2" turns off the lights!

[jeffsf]

Debugging suggested that the routines to set brightness levels in liblights/liblights.c were not being called.
Removing /system/lib/hw/*.goldfish.so seems to have resolved the issue (though the debug messages are still not being seen).

What is known so far:

• The driver responds to # echo [1|2] > /sys/class/misc/melfas_touchkey/brightness where 1 -- on, 2 -- off
• in liblights/lights.c the backlights for the touchkeys are controlled using that sysfs entry and writing on?1:2
• The JNI com_android_server-LightsService.cpp finds backlight, buttons, and notification during init_native()
• The Android LightsService calls setBrightness(0) repeatedly (as expected) when auto-brightness is enabled and the button brightness is set to 0 for that light level
• setBrightness() calls setLightLocked() in Java, as expected
• setLightLocked() calls setLightNative() in Java -- only if the light needs to be changed, based on Java notion of state
• setLightNative() is in the JNI
• setLightNative() should call the set_light method on the light struct registered by the JNI's init_native()

PowerManager seems only to be controlling the screen brightness and not the touchkeys as only SCREEN_BRIGHT_BIT is set.

At least one issue is likely in the way that setLightLocked() works as it compares the requested level to its notion of the current level. Only if they are different does it try to change the level. If BLN (or other processes) are changing the backlight level independently of the Java framework, then this optimization results in the level not being sent when it should be. Hacking the check out changes the behavior, but does not resolve the entire issue.

Chasing down autoBrightnessButtonKeyboard setting as well, so PowerManager manages the keyboard/button brightness properly as well.

[jeffsf]

I've been able to get the auto-brightness to drive the touchkeys by removing the check on if (color != mColor || mode != mMode || onMS != mOnMS || offMS != mOffMS)

Looks like the issues are a result of:

• The button lights are turned on when the driver resumes, but Android doesn't know they are on
  • This can be "fixed" by removing the #if defined(CONFIG_S5PC110_VIBRANTPLUS_BOARD) section in cypress_touchkey_early_resume()
  • Might need to tell Android to turn them off as well on resume, to keep things in sync
• The button lights seem to turn on when a button is pressed, but not through the driver, from what I have seen
  • This probably can be resolved by starting a timer on every button event and having Android turn them on too
  • When the timer expires, if in manual brightness mode, turn them off

Edit -- The more I think about this, the more I believe that this should be "fixed" in liblights, either by adding a key-event listener to the input chain, or with a new pseudo-device that can report the "touchpad backlight on" change to liblights directly.

[fbis251]

When Erik released his proton kernel we got a backlights fix along with it. I'll create a patch from his code so we can port it over to our kernel later this week.

[maxfierke]

Yeah, we should cherry-pick some other stuff from proton like zRam. Don't cherry-pick any CPU governors, though.

[jeffsf]

I quickly scanned the changes and it looks like part of it is creating a kernel work item to turn them off. That is the "hacky" part of the KoD that bothered me and needed to be addressed at some point.

I haven't looked in detail at the changes are they are pretty extensive.

Amusingly, I've noticed that the backlights for the touchkeys turn off for the key when it is touched when the phone is in "charging" mode (pre-boot). Wish I could see that code!

[maxfierke]

Yeah, I might take a crack later this week to try and implement the aries solution, which I don't think creates a separate work item.

[fbis251]

As a temporary fix we now have these two commits:
teamacid/android_kernel_galaxys4gmtd@2d17fd7
teamacid/android_kernel_galaxys4gmtd@21b4aa7